mysql日常这点事儿（8）之备份恢复基本原则（1）

    经常会有人问，如何去备份海量数据呢？如何去做到每小时去备份TB级的数据呢？偶尔听到一些朋友说道，某次，还在做上一小时的mysqldump，这小时的任务又来了，怎么处理。我想，这里涉及到了一个海量备份的基本思路--仅备份改变的数据！这个很重要。

    从数据恢复的角度来说，对冷备份的恢复步骤是最简单的，简单的mv-cp，OK了。但实际上大多数线上业务，都会要求7*24不down机。如何解决呢？常见的方案：

      再配一台slave，专门用来备份。好了这时候，问题来了，如何备份呢？stop slave -》flush table with read lock -》mysqldump all database-》搞定。这个可能是大多数人做的方法。少量数据，备份与恢复都没啥问题。

    新的问题来了，海量数据如何处理呢？再进一步的备份方案，接着上面的，开始增量备份，打开binlog，备份binlog。增量出来了。数据备份量真的很少了。备份也很快了。

    下一个问题来了，如何处理高频率的备份呢？由高频率备份造成的恢复压力如何处理？我们都知道，增量备份的备份速度块，恢复速度慢，需要挨个应用备份的增量。解决思路：stop slave-》stop mysqld-》cp 数据文件、表定义。

    下一个问题，why我们需要备份这么多数据呢？myisam不存在太大的问题，你用哪个就备份哪个，INNODB呢？默认是共享表空间，你只能都备份了。处理下？在建库的时候就设定，file-per-table。OK，我们也能对innodb做改过哪个备份哪个的冷备份了。

    下一个问题，在电信计费数据库里，很常见的做法就是分开历史表，现状表，历史库，现状库，我们也可以把这个借鉴到mysql里面，由此，备份数据量，明显就减小了，备份速度也就能很快上来。

    再次强调下备份思路，仅备份改变的玩意，尽快将不改变的东西放到历史库里面去，减小备份压力。