xtrabackup备份原理及注意事项

物理备份(Xtrabackup)

相对于逻辑备份利用查询提取数据中的所有记录,物理备份更直接,拷贝数据库文件和日志来完成备份,因此速度会更快。当然,无论是开源的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的改进

无论是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,然后回滚未提交事务。
这里写图片描述

增量备份过程

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

增量应用

这里写图片描述

恢复过程

这里写图片描述

流备份过程图

这里写图片描述

InnoDB表空间的结构

这里写图片描述

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

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值