往期专题请查看www.zhaibibei.cn
这是一个坚持Oracle,Python,MySQL原创内容的公众号
XtraBackup工具详解 Part 1 xtrabackup介绍
XtraBackup工具详解 Part 2 xtrabackup安装
MySQL 5.7.25
Redhat 6.10
Percona XtraBackup 利用的是InnoDB的crash-recovery功能
他拷贝非一致状态的InnoDB数据文件,之后利用redo日志对数据文件做恢复以使数据文件一致
这是因为InnoDB维护了一个记录InnoDB数据更改的重做日志(redo log),也可以称为事务日志
恢复时,Percona XtraBackup检查数据文件和事务日志,之后做两个步骤:
将提交过的事务写到数据文件中
回滚未提交的事务
Percona XtraBackup 备份开始时,首先记录日志的序号(log sequence number
或者LSN)。之后拷贝数据文件,与此同时,Percona XtraBackup 启动一个后台进程监视重做日志,之后拷贝改变的部分
因为重做日志会被覆盖,所以Percona XtraBackup必须时刻监视着
Percona Server 5.6开始,Percona XtraBackup新增了backup lock特性,他相对与
FLUSH TABLES WITH READ LOCK来说更加的轻量级,使用它可以在不影响InnoDB表的DML操作下拷贝非InnoDB数据
backup lock 包括如下三个命令:
LOCK TABLES FOR BACKUP
LOCK BINLOG FOR BACKUP
UNLOCK BINLOG
最后大体上xtrabackup的步骤如下:
首先会记录LSN位置并拷贝InnoDB数据文件并持续跟踪LSN变化
InnoDB拷贝完之后执行执行LOCK TABLES FOR BACKUP命令阻止非InnoDB表的DML操作
之后拷贝非InnoDB数据文件,如MyISAM等
之后执行LOCK BINLOG FOR BACKUP命令阻止所有可能更改二进制日志位置或者GTID的操作
之后拷贝改变redo日志
最后释放二进制日志和表的锁(UNLOCK BINLOG)
这样就保证了备份完成后innodb和非innodb的数据是一致的
注意上述过程为Percona Server 5.6及以上,对于社区版的MySQL使用的是如下命令进行上锁
FLUSH NO_WRITE_TO_BINLOG TABLES
FLUSH TABLES WITH READ LOCK
这意味着当备份完innodb表后,非innodb的表会导致全局的读锁,即不允许DML操作
另外如果备份时有长时间未结束的语句或者系统繁忙时,FLUSH TABLES WITH READ LOCK会消耗很长时间,将导致数据库长时间无法DML操作
所以建议MySQL不要使用MyISAM引擎的表并在系统空闲时进行备份
使用 xtrabackup --copy-back 或 xtrabackup --move-back将备份的文件还原到一个目录
相当于Oracle的restore
默认情况下, 它会读取my.cnf文件中的datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir变量并检查目录是否存在
还原文件的顺序如下:
首先是MyISAM的表和索引以及其他非innodb的数据(如.frm, .MRG, .MYD, .MYI, .TRG, .TRN, .ARM, .ARZ, .CSM, .CSV, par and .opt 文件)
之后拷贝innodb的表和索引
最后是redo log
之后是恢复数据,相当与oracle的recover,即使用redo log做恢复以使数据达到一致状态
本专题所有内容翻译子Percona XtraBackup的官方文档
可通过如下链接下载
http://www.zhaibibei.cn/mysql/xtrabackup/tutorial1
联系客服