1.备份计划
视库的大小来定,一般来说100G内的库,可以考虑使用mysqldump来做,因为mysqldump更加轻巧灵活,备份时间选在业务低峰期,可以每天进行都进行全量备份(mysqldump备份出来的文件比较小,压缩之后更小)。100G以上的库,可以考虑用xtranbackup来做,备份速度明显要比mysqldump要快。一般是选择一周一个全备,其余每天进行增量备份,备份时间为业务低峰期。
2.备份恢复时间
物理备份恢复快,逻辑备份恢复慢
这里跟机器,尤其是硬盘的速率有关系,以下列举几个仅供参考
20G的2分钟(mysqldump)
80G的30分钟(mysqldump)
111G的30分钟(mysqldump)
288G的3小时(xtra)
3T的4小时(xtra)
逻辑导入时间一般是备份时间的5倍以上
3.mysqldump和xtrabackup实现原理
mysqldump
mysqldump属于逻辑备份。加入--single-transaction选项可以进行一致性备份。后台进程会先设置session的事务隔离级别为RR(SETSESSIONTRANSACTIONISOLATIONLEVELREPEATABLEREAD),之后显式开启一个事务(STARTTRANSACTION/*!40100WITHCONSISTENTSNAPSHOT*/),这样就保证了该事务里读到的数据都是事务事务时候的快照。之后再把表的数据读取出来。如果加上--master-data=1的话,在刚开始的时候还会加一个数据库的读锁(FLUSHTABLESWITHREADLOCK),等开启事务后,再记录下数据库此时binlog的位置(showmasterstatus),马上解锁,再读取表的数据。等所有的数据都已经导完,就可以结束事务
Xtrabackup
xtrabackup属于物理备份,直接拷贝表空间文件,同时不断扫描产生的redo日志并保存下来。最后完成innodb的备份后,会做一个flush engine logs的操作(老版本在有bug,在5.6上不做此操作会丢数据),确保所有的redolog都已经落盘(涉及到事务的两阶段提交概念,因为xtrabackup并不拷贝binlog,所以必须保证所有的redo log都落盘,否则可能会丢最后一组提交事务的数据)。这个时间点就是innodb完成备份的时间点,数据文件虽然不是一致性的,但是有这段时间的redo就可以让数据文件达到一致性(恢复的时候做的事情)。然后还需要flushtableswithreadlock,把myisam等其他引擎的表给备份出来,备份完后解锁。这样就做到了完美的热备。