共计 1821 个字符，预计需要花费 5 分钟才能阅读完成。
对于较大的数据库，我们一般都是使用 innobackup 进行备份，备份的及恢复的速度更快。
试验环境：
CentOS6.8 x86_64
MySQL5.6.34 社区 rpm 版
xtrabackup 版本：percona-xtrabackup-24-2.4.5-1.el6.x86_64.rpm
主库：node0 192.168.2.10（需要安装 xtrabackup 和 lz4）
从库：node1 192.168.2.11（需要安装 xtrabackup 和 lz4）
5.6 下 GTID 复制必须配的参数（主库和从库都要加上这 3 行参数）：
gtid-mode=ON
enforce_gtid_consistency = ON
log_slave_updates=ON
step1、在从库创建备份文件的存放目录：
mkdir /tmp/db_restore
step2、在主库执行备份（最好开个 screen 操作，防止网络中断的问题），直接导出到从库机器上：
## 注意这里我们还需要提前在 2 台机器上安装 lz4 压缩工具，因为我们的脚本会调用 lz4 压缩和解压备份文件
innobackupex –user=root \
–password=123456 \
–parallel=4 \
–socket=/tmp/mysql.sock \
–no-timestamp \
–stream=xbstream . |\
lz4 -B4 |\
ssh node1 \
“cat – | lz4 -d -B7 | xbstream -x -C /tmp/db_restore”
step3、在从库 node1 上看下 主库的 gtid 位置
cd /tmp/db_restore
cat xtrabackup_binlog_info 内容如下：
mysql.000008 1949 013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72
为了便于理解，我们去主库查看下对应时间段的 binlog，截图如下：
补充：xtrabackup_binlog_info 内容解读：
mysql.000008 表示主库的 binlog 文件名，1949 是尚未执行的 binlog position（就是说我们使用传统 change master 模式的时候 MASTER_LOG_FILE=’master2-bin.001′,MASTER_LOG_POS=1949）。
013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72 指的是已经执行完的 GTID 编号（就是说我们 change master 的时候需要先执行 set global gtid_purged=’013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72′; 来 purge 掉这些 GTID）。
step4、在从库上将上一步获取到的这些 gtid purge 掉，因为这些实际上已经执行过了。
set global gtid_purged=’013bfb27-2edd-11e7-89c7-000c296a2c0d:1-72′;
如果提示 ERROR 1840 (HY000): @@GLOBAL.GTID_PURGED can only be set when @@GLOBAL.GTID_EXECUTED is empty. 则需要执行下 reset master;
step5、配置并启动复制：
CHANGE MASTER TO MASTER_HOST=’192.168.2.10′,
MASTER_USER=’rpl’,
MASTER_PASSWORD=’rpl’,
MASTER_PORT=3306,
MASTER_AUTO_POSITION=1;
start slave;
show slave status\G
然后可以在主库的 test 库下尝试创建几个表，验证下复制是否正常。
待确认的问题：
对于某些版本的 innobackup，备份出的 xtrabackup_binlog_info 里面只有 mysql.000008 1949，而不带 GTID 编号。那么我们执行 purge 的时候就要根据 binlog pos 1949 这个位置到主库的 binlog 去找到它上一个的 gtid 编号（例如上图的就是 013bfb27-2edd-11e7-89c7-000c296a2c0d:72）。或者使用传统模式的复制，不用 GTID 复制即可。
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2017-05/143441.htm
