从实现原理来看,mysqldump、 mydumper、mysqlpump、 MySQL Shell可归为一类,本质上都是通过SELECT * FROM TABLE的方式备份数据,只不过在此基础上,通过全局读锁 + REPEATABLE READ事务隔离级别,实现了数据库的一致性备份。
SELECT ... INTO OUTFILE 充其量只是一个命令,算不上工具,更不用说数据库的一致性备份。
从导出的内容来看,mysqldump、mydumper、mysqlpump 会以INSERT语句的形式保存备份结果,如,
INSERT INTO `t1` VALUES (1,\'aaa\'),(2,\'bbb\'),(3,\'ccc\');而 MySQL Shell和SELECT ... INTO OUTFILE 是以CSV格式的形式保存备份结果,如,
1 aaa2 bbb
3 ccc
在恢复,各个工具对应的恢复工具也不一样。具体来说,
mysqldump、mysqlpump对应的恢复工具是mysql客户端,所以是单线程恢复。
mydumper对应的恢复工具是myloader,支持多线程恢复。
util.dumpInstance()对应的恢复工具是util.loadDump(),该工具实际调用的是LOAD DATA LOCAL INFILE命令,支持多线程恢复。
SELECT ... INTO OUTFILE对应的恢复命令是LOAD DATA。
mysqlbackup VS mysqldump下面是MySQL官方提供的一组数据,对比了mysqlbackup和mysqldump备份恢复时间。
第一张图比较的是备份时间,mysqldump是mysqlbackup的49倍。
第二张图比较的是恢复时间,mysqldump是mysqlbackup的80倍。
借此,我们也能看到逻辑备份工具相对于物理备份工具在备份、还原速度上的差距。
不过可惜的是,这里没有测试mydumper。
毕竟,针对数据量较大的实例,如果一定要使用逻辑备份,大家一般倾向于使用mydumper,而不是mysqldump。
如何检测备份的有效性
为什么要检测备份的有效性,原因主要有两个:
验证整个备份环节的可靠性。
包括备份参数是否完备,备份集是否有效,备份介质是否损坏等。
通过检查备份的有效性,搭建一套完整的自动化恢复体系。
很多时候,影响数据库恢复时间的并不是备份集太老,而是手动恢复过程中,因为命令、环境、流程的不熟悉,所带来的额外耗时。
如何检测备份的有效性,常用的方法有三个:
基于备份恢复实例,看实例能否起来。并在此基础上,进行随机查询。
这种检测方法最简单。
一般来说,实例能起来,且随机查询也没问题,就意味着这个备份集是可用的。
但备份集可用,并不意味着这个备份集能满足我们的需求,譬如常见的,搭建从库。
而且一些常见的问题,如备份中断、参数没指定准确,也无法通过这种方式检测出来。
在1的基础上,建立复制。
如果从库在追主库的过程中,没有报错,大概率意味着主从数据是一致的。当然,也只是大概率,并不是100%。
在2的基础上,利用pt-table-checksum检查主从数据的一致性。
如果检查结果没问题,则意味着主从数据是一致的,也就间接证明了备份的有效性。
但因为pt-table-checksum在运行的过程中,会在chunk级别对表加S锁,对更新频繁的业务,还是有一定的影响。
一般来说,线上使用方法2足矣。
方法3,因为要检查主从数据的一致性,耗时相对较久,如果要检测的备份集很多,反而会影响检测的效率。
RTO 和 RPO
衡量一个数据中心的容灾能力时,有两个常用的指标:
RTO:Recovery Time Objective,恢复时间目标。
指的是灾难发生后,必须在这个时间内恢复数据。