xtrabackup备份原理及注意事项

最新推荐文章于 2024-07-15 10:20:21 发布

lijingkuan

最新推荐文章于 2024-07-15 10:20:21 发布

阅读量4.2k

点赞数 1

分类专栏： mysql 文章标签：数据库备份

本文链接：https://blog.csdn.net/lijingkuan/article/details/72803531

版权

mysql 专栏收录该内容

68 篇文章 0 订阅

订阅专栏

物理备份(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的区别：