xtrabackup备份原理

物理备份(Xtrabackup)  

转载于:https://www.cnblogs.com/chinaops/p/9381649.html

相对于逻辑备份利用查询提取数据中的所有记录,物理备份更直接,拷贝数据库文件和日志来完成备份,因此速度会更快。当然,无论是开源的Mydumper还是官方最新的备份工具(5.7.11的mysqlpump)都支持了多线程备份,所以速度差异可能会进一步缩小,至少从目前生产环境来看,物理备份使用还是比较多的。由于Xtrabackup支持备份innodb表,实际生产环境中我们使用的工具是innobackupex,它是对xtrabackup的一层封装。innobackupex 脚本用来备份非 InnoDB 表,同时会调用 xtrabackup 命令来备份 InnoDB 表,innobackupex的基本流程如下: 
1.开启redo日志拷贝线程,从最新的检查点开始顺序拷贝redo日志; 
2.开启ibd文件拷贝线程,拷贝innodb表的数据 
3.ibd文件拷贝结束,通知调用FTWRL,获取一致性位点 
4.备份非innodb表(系统表)和frm文件 
5.由于此时没有新事务提交,等待redo日志拷贝完成 
6.最新的redo日志拷贝完成后,相当于此时的innodb表和非innodb表数据都是最新的 
7.获取binlog位点,此时数据库的状态是一致的。 
8.释放锁,备份结束。

完整备份过程如图:: 
xtrabackup备份原理

Xtrabackup的改进

无论是mysqldump,还是innobackupex备份工具,为了获取一致性位点,都强依赖于FTWRL。这个锁杀伤力非常大,因为持有锁的这段时间,整个数据库实质上不能对外提供写服务的。此外,由于FTWRL需要关闭表,如有大查询,会导致FTWRL等待,进而导致DML堵塞的时间变长。即使是备库,也有SQL线程在复制来源于主库的更新,上全局锁时,会导致主备库延迟。从前面的分析来看,FTWRL这把锁持有的时间主要与非innodb表的数据量有关,如果非innodb表数据量很大,备份很慢,那么持有锁的时间就会很长。即使全部是innodb表,也会因为有mysql库系统表存在,导致会锁一定的时间。 
为了解决这个问题,Percona公司对Mysql的Server层做了改进,引入了BACKUP LOCK。 
具体而言,通过”LOCK TABLES FOR BACKUP”命令来备份非innodb表数据;通过”LOCK BINLOG FOR BACKUP”来获取一致性位点,尽量减少因为数据库备份带来的服务受损。我们看看采用这两个锁与FTWRL的区别:

LOCK TABLES FOR BACKUP

作用:备份数据 
1.禁止非innodb表更新 
2.禁止所有表的ddl 
优化点: 
1.不会被大查询堵塞(关闭表) 
2.不会堵塞innodb表的读取和更新,这点非常重要,对于业务表全部是innodb的情况,则备份过程中DML完全不受损 
UNLOCK TABLES

LOCK BINLOG FOR BACKUP

作用:获取一致性位点。 
1.禁止对位点更新的操作 
优化点: 
1.允许DDl和更新,直到写binlog为止。 
UNLOCK BINLOG

准备和恢复数据阶段

过程如图: 
首先应用xtrabackup日志提交事务应用到InnoDB,然后回滚未提交事务。 
xtrabackup备份原理

增量备份过程

对于增量备份只对InnoDB,MyISAM和其它引擎仍然是完整备份的方式,增量备份主要是处理InnoDB中有变更的页(页的LSN).LSN信息在xtrabackup_checkpoints中。 
xtrabackup备份原理

增量应用

xtrabackup备份原理

恢复过程

xtrabackup备份原理

流备份过程图

xtrabackup备份原理

InnoDB表空间的结构

xtrabackup备份原理

参考文章: 
1.MySQL备份原理详解 
http://www.cnblogs.com/cchust/p/5452557.html

上一篇:linux high availability articles


下一篇:flink-conf.yaml