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、备份注意:

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

相关推荐