9.11、mysql增量备份和增量恢复介绍

1、增量备份：

增量数据是从上次全量备份之后，更新的新数据，对于mysql来说，binlog日志就是mysql的增量数据；

（1）按天进行备份：

周一00点全量备份	周二00点全量备份	......
01.sql.gz	02.sql.gz	......
周一增量备份	周二增量备份	......
mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.index	mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.index	......

1）优点：恢复时间短，维护成本低；

2）缺点：占用空间多，占用系统资源多，经常锁表影响用户的体验；

（2）按周进行备份：

周六00全量备份
01.sql.gz	01.sql.gz	01.sql.gz
周一增量备份	周二增量备份	周三增量备份
mysql-bin.000001 mysql-bin.000002 mysql-bin.000003 mysql-bin.index	mysql-bin.000004 mysql-bin.000005 mysql-bin.000006 mysql-bin.index	mysql-bin.000007 mysql-bin.000008 mysql-bin.000009 mysql-bin.index

1）优点：节省备份时间，减小本分压力；

2）缺点：增量的binlog文件副本太多，还原会比较的麻烦；

（3）企业场景全量和增量的频率是怎么做的：

1）中小公司，全量一般是一天一次，业务流量低谷时执行全被，备份时会锁表；

2）大公司周备，每周六00点一次全量备份，下周日到周六前都是增量；

3）如何增量：

使用rsync+inotify(rsync+sersync)把所有的binlog备份到远程服务器上；

（4）企业的备份什么时候会派上用场：

1）迁移或者升级数据库时；

2）增加从从库的时候；

3）人为的ddl，dml语句,主从库都没有办法了，因为所有的库都会还行，此时需要备份；

4）跨机房灾备，需要备份到异地；

（5）小结：

我们在生产工作中一般常用一主多从数据库架构，常见的备份方案是在某一个不对外服务的从库上

开启binlog，然后实施定时全备和实时增量备份，保存的周期大于备份的周期；

2、增量恢复：

利用二进制日志和全备进行的恢复过程，被称为增量恢复：

（1）主库或者从库宕机(硬件损坏)是否需要增量恢复：

不需要增量恢复；

主库宕机，只需要把其中一个同步最快的从库切换为主库即可；

从库宕机，直接不用就好了；

（2）人为操作数据库sql语句破坏主库是否需要增量恢复：

需要增量恢复；

在数据库主库内部命令行误操作，会导致所有的数据库(包括主从库)数据的丢失。

列如：在主库执行了'drop database test;'这样的删除语句，这时所有的从库也

会执行这哥'drop database test;'语句，从而导致所有数据库上的test库数据丢失。

（3）只有一个主库是否需要进行增量恢复：

如果公司只有一个主库的情况，首先应该做定一天一次的全量备份及时时的增量

备份。

（4）小结：

1）一般由人为或程序逻辑的方式在数据库执行的sql语句等误操作，才需要增量恢复，因为

此时所有的从库也执行了误操作语句；

2）增量恢复的条件是：存在一份全备加上全备之后的时刻到出现问题的所有增量binlog文件备份；

3）恢复时建议对外停止更新；

4）恢复全量备份，然后把增量日志中有问题的sql语句删除，恢复到数据库；

5）增量恢复的核心思想：

流程制度控制，如果不做，就会面临数据和服务出现故障；

业务需求容忍度，可量化的目标，根据需求选择停库或锁表或者容忍丢失部分数据；

3、备份注意：

备份保存的周期要大于备份的周期；