简介:
? XtraBackup 包含两个主要的工具即: xtrabackup 和 innobackupex
? xtrabackup: 只能备份 InnoDB 和 XtraDB 两种事务引擎的表, 不支持备份非事务引擎的表
? innobackupex: 封装了 xtrabackup 的 perl 脚本, 支持在全局读锁下的非事务表备份, 支持无全局读锁下的事务表
安装:
? 推荐安装 percona 公司的源然后 yum 安装
yum - y install https: //www.percona.com/redir/downloads/percona-release/redhat/percona-release-0.1-4.noarch.rpm
yum - y install percona - xtrabackup - 24
innobackupex 备份流程:
? 1. 备份开始时先开启一个后台检测进程, 实时监测 redo 的变化, 一但发现 redo 中有新日志写入, 立刻将日志记入其的后台日志文件 (xtrabackup_log) 中,
? 2. 复制 InnoDB 表的数据文件, 系统表空间文件 ibdata1, 完成后进入下一步,
? 3. 执行全局读锁, 锁住所有的表 (事务, 非事务), 拷贝非事务表的文件 (.frm .MYI .MYD), 获取 binlog 位置, 解锁全部表
? 4. 停止 xtrabackup_log, 结束备份
阶段 | 解释 |
---|---|
生成 xtrabackup 日志文件 | 软件本身开启一个用来保存 redo 的日志 |
拷贝 InnoDB 相关文件 (.ibd 表数据文件,ibdata1 回滚空间) | |
FTWRL, 全局读锁 | 非事务表不支持用事务保证一致性,需要读锁 |
拷贝 innodb 表结构文件 frm,非事务表的全部文件 | |
获取 binlog 位置 | 以此位置作为备份的全局位置 |
释放全局读锁 | 备份初步结束 |
停止 xtrabackup 的日志工作。 | 备份结束 |
? 备份语句:
innobackupex--defaults - file = /etc/my.cnf--user = bak--password = bak123--stream = xbstream. | gzip cat - >xtrabak.xb.gz
?
innobackupex 恢复流程:
? 启动 XtraBackup 软件包自带的 InnoDB 实例, 回放 xtrabackup 过程中收集的 xtrabackup_log:
? 根据 binlog, 回放 binlog 中已经登记, 但 redo 中未提交但已经 prepare 的事务
? 根据 binlog, 回滚 binlog 中未登记, 但 redo 中已经 prepare 的事务
? 将应用好的文件拷回要被恢复实例的数据目录, 赋予 mysql 用户的权限即可
# 解压
gunzip all.xb.gz -c|xbstream -x -C /data/full
# 应用 xtrabackup_log
innobackupex --apply-log --use-memory=1G /data/full
# 拷回预备恢复的文件, 也可以用手工拷贝代替
innobackupex --defaults-file=/etc/my.cnf --copy-back --rsync /data/full
# 将拷回的文件所有权赋给 mysql 用户
chown -R mysql.mysql /data/mysql/3306
# 启动数据库
mysqld --defaults-file=/etc/my.cnf
附:
1. 使用 xbstream 而不是 tar 的原因:
? 传统复制的情况下, 从从库备份, 需要获得从库的复制信息, 可以使用 --slave-info 参数, 这样复制信息会附加在备份文件包中, 但是用 tar 的时候总是会截断一部分复制信息的描述文件转用 xbstream 流传输后没有问题 / 另外, 如果使用 GTID, 不考虑获取 binlog file 和 pos 的话, tar 或者 xbstream 都可以接受
2. 不推荐使用增备的原因:
? 1. 增备恢复步骤繁琐 (需要在最后一个增备之前, 只应用 redo, 最后一个才应用全部 xtrabackup_log, 拷回也麻烦)
? 2. 与全备加 binlogserver 相比, 不能恢复增备之间任意时间点的数据
3. 总的来看, XtraBackup 仍是物理备份为主, 辅以逻辑备份完成数据一致性的备份方式
来源: http://www.bubuko.com/infodetail-2492875.html