对于较大的数据库，我们一般都是使用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复制即可。
