前面我们介绍了Xtrabackup 2.4版本的介绍,这个专题说8.0版本
大体上差不多,不过8.0版本移除了innobackupex命令且只能备份8.0版本的MySQL
详情请看如下链接
此次实验的环境如下
MySQL 8.0.19
Redhat 7.4
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数据
而MySQL从8.0才开始支持backup lock特性,通过LOCK INSTANCE FOR BACKUP和 LOCK TABLES FOR BACKUP 命令来实现,可以做到备份时不锁表。
最后大体上xtrabackup的步骤如下:
InnoDB拷贝完之后执行LOCK TABLES FOR BACKUP 命令加备份锁,这时可以做DML操作和DDL操作,是通过performance_schema.log_status这个表来实现协调
之后拷贝非InnoDB数据文件,如MyISAM等
这样就保证了备份完成后innodb和非innodb的数据是一致的
使用 xtrabackup --copy-back 或 xtrabackup --move-back将备份的文件还原到一个目录
相当于Oracle的restore
默认情况下, 它会读取my.cnf文件中的datadir, innodb_data_home_dir, innodb_data_file_path, innodb_log_group_home_dir变量并检查目录是否存在
还原文件的顺序如下:
之后是恢复数据,相当与oracle的recover,即使用redo log做恢复以使数据达到一致状态
本专题所有内容翻译子Percona XtraBackup的官方文档
可通过如下链接下载