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、备份注意:
备份保存的周期要大于备份的周期;