简介:

Percona XtraBackup包含两个主要的工具即:xtrabackupinnobackupex

xtrabackup:只能备份类InnoDB事务引擎的表(目前有InnoDB,XtraDB),不支持备份非事务引擎的表。

innobackupex:封装了xtrabackupperl脚本,支持在全局读锁下的非事务表备份,支持无全局读锁下的事务表。

在数据文件超过10G左右时,逻辑备份的select * from table的方式会严重影响系统效率,挤出部分热数据,这时候可以考虑使用Percona公司开源的Percona XtraBackup工具进行偏向于物理备份的方式,生成线上一致性热备份。

安装:

推荐安装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的时候,会遇到主从复制信息的描述文件在tar包中被截断的问题。转用xbstream流传输后没有问题。另外,如果使用GTID,不考虑获取binlog filepos的话,tar或者xbstream都可以接受。

2.不推荐使用增备的原因:

1.增备恢复步骤繁琐(需要在最后一个增备之前,只应用redo,最后一个才应用全部xtrabackup_log,拷回也麻烦)

2.与全备加binlogserver相比,不能恢复增备之间任意时间点的数据。

3.总的来看,innobackupex仍是物理备份为主,辅以逻辑备份完成数据一致性的备份方式。