1.主从均为新建库
IP架构
主：172.17.100.106：3306
从：172.17.100.107：3306
MySQL库搭建参考：MySQL5.7自动部署脚本
MySQL已经部署完毕，接下来配置基于GTID的主从
#配置主从互信
在GTID01端
echo '172.17.100.106 GTID01' >> /etc/hosts
echo '172.17.100.107 GTID02' >> /etc/hosts
在GTID02端
echo '172.17.100.106 GTID01' >> /etc/hosts
echo '172.17.100.107 GTID02' >> /etc/hosts
在GTID01端
ssh-keygen -P '' -f /root/.ssh/id_rsa -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub GTID02
在GTID02端
ssh-keygen -P '' -f /root/.ssh/id_rsa -t rsa
ssh-copy-id -i /root/.ssh/id_rsa.pub GTID01
防火墙里配置2个node的ip可以互访(我这里配置了整个段可以互访)
iptables -I INPUT -s 172.17.100.0/24 -j ACCEPT
service iptables save
在主从库上均创建账号rpel
对其执行授权
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'172.17.100.%'
将主库逻辑导出
mysqldump -S /tmp/mysql3306.sock -uroot -p密码 --master-data=2 --single-transaction -A > db_`date +%Y%m%d`.sql
将导出的sql导入到从库
mysql -uroot -p密码 < db_20180607.sql
因为这里是测试环境，两个库均没有数据，所以搭建比较随意
在从库上进行配置
change master to master_host='172.17.100.106',master_port=3306,master_user='repl',master_password='repl',master_auto_position=1;
在slave上show slave status ，确保是双yes证明搭建成功
2.主库为老库，从库为新库
#主库在空闲时间执行一次全库导出
（带参数--single-transaction --master-data=2锁表保障生成一致性快照）
mysqldump -uroot -p'password' --single-transaction --master-data=2 -A > all.sql
实际上在主从导出时，我们并不需要也不希望把主库的mysql库和information_schema库导出来，所以更推荐下面这条dump语句
mysql -e "show databases;" -uroot -p密码| grep -Ev "Database|information_schema|mysql|test" | xargs mysqldump -uroot -p密码 --databases --single-transaction --master-data=2 > all.sql
#从库执行导入
1.从库执行reset master然后导入，或者注释掉all.sql里面的第24行的“SET @@GLOBAL.GTID_PURGE...”导入
2.如果从库执行了reset master之后导入，则跳过此步；如果从库采用后面的方式完成数据导入，则需要在mysql命令行中单独执行"set global gtid_purged=xxxx"，xxxx的内容为all.sql中24行对应的值；通过这种方式来跳过已经导入从库的GTID值
3.执行change master语句
4.start slave
5.show slave status \G 查看是否执行成功
3.常见参数解读
主库IP：172.17.100.88
从库IP：172.17.100.103
主库是一个运行很久的老库；从库为新库，但是并没有把主库数据dump到从库，也就是说这2个库一开始就数据就不是一致的
上图中颜色相同的配对进行对比
Master_Log_File不等于Relay_Master_Log_File（主库当前的binlog文件号和已经读取的binlog文件号）
Read_Master_Log_Pos不等于Exec_Master_Log_Pos（已经读取到的主库log位置和已经执行复制的主库log位置）
Retrieved_Gtid_Set不等于Executed_Gtid_Set （Retrieved（取回），Executed（执行））
上面几个不等值证明存在复制延迟
粉紫框表明当前复制遇到的问题（1146）
毕竟没有做dump导出，所以很明显的不一致，需要跳过这部分
到主库上执行show master status \G 可以发现主库当前的GTID已经到了15881
从库上执行gtid_purged（首先要执行stop slave等一系列操作）
stop slave;
reset master;
set global gtid_purged='be830f17-0908-11e9-8501-f8bc12343e14:1-15881';
start slave;
状态成功变为双yes，不过Relay_Master_Log_File仍然不等于Master_Log_File，在下次进行同步之后，这里的值应该是一致的
对主从进行验证
主库drop一个test库，到从库上进行观察，发现从库出现了报错
可以看到Relay_Master_Log_File已经等于Master_Log_File，但gtid_set没有跟上来，slave sql_thread的状态是no
从报错可以看出提示是从库无法drop database
这是因为2个库不一致，主库本身存在test库，但从库不存在，因此无法同步主库的drop动作
对从库执行create database test;操作，再重启slave，可以发现恢复正常
一般来说从库是关闭写操作的，不过这里的实验并没有限制这个操作
绿框是读取的主库的GTID，而红框则是从库执行事务之后，生成的自己的GTID
相关参数
log_slave_updates
该参数置为0或者off时，主库写入的binlog更新不会被写到从库的binlog中，从库的binlog只会记录自己本地的操作
如果从库binlog想写入主库的操作，该参数需要设置为1或者on
