【3.2】【mysql基本实验】mysql GTID复制（基于空数据的配置）
概述：本质上和传统异步复制没什么区别，就是加了GTID参数。
且可以用传统的方式来配置主从，也可以用GTID的方式来自动配置主从。
这里使用GTID的方式来自动适配主从。
需要mysql5.6.5以上
目录
一、基于GTID的异步复制（一主一从）
【1】环境
【2】my.cnf 参数配置（主从都配）
【3】在主库创建复制用户
【4】在从库上运行主从配置
【5】核验
【5.1】show slave status\G 查看是否有误
【5.2】核验之前创建的用户是否有同步过来
【5.3】在主库创建测试数据库与测试表查看同步情况
【5.4】show global variables like '%gtid%' ; 查看GTID信息
一、基于GTID的异步复制（一主一从）
【1】环境
操作系统：CentOS linux 7.5
数据库版本：5.7.26
数据库架构：主从复制，主库用于生产，从库用于数据容灾和主库备机，采用默认传统的异步复制。
主库IP：192.168.135.158 端口：3306
从库IP：192.168.135.159 端口：3306
【2】my.cnf 参数配置（主从都配）
#replication_new log_bin=/mysql/log/3306/mysql-bin #开启binlog log_bin_index=/mysql/log/3306/mysql-bin.index binlog_format=row binlog_rows_query_log_events=on max_binlog_size=2048 bind-address=0.0.0.0 server_id=2013306 #注意，这里从库的server_id和主库一定要不一样 expire_logs_days=7 #超过7天的binlog清理 innodb_support_xa=1 binlog_cache_size=1M log_bin_trust_function_creators=1 #同步存储过程、函数、触发器 innodb_flush_log_at_trx_commit=1 sync_binlog=1 transaction-isolation=read-committed #slave replication relay_log=/mysql/log/3306/relaylog/mysql-relay.log log-slave-updates=1 read_only=1 slave-parallel-type=LOGICAL_CLOCK slave-parallel-workers=4 master_info_repository=table #master_info 会记录到 mysql.slave_master_info relay_log_info_repository=table #relay_log 会记录到，mysql.slave_relay_log_info relay_log_recovery=1 slave_skip_errors=ddl_exist_errors slave_preserve_commit_order=1 #增加的GTID参数 gtid_mode=on enforce_gtid_consistency=1 #on：当发现语句/事务不支持GTID时，返回错误信息 log-slave-updates=1 binlog_gtid_simple-recovery=1 #5.7.6以下默认为off，5.7.6以上默认为on
【3】在主库创建复制用户
这里也会记录到binlog，开启主从同步后会一并复制过去，以便我们做主从且换
create user 'rpl'@'192.168.135.%' identified by '123456'; grant replication slave on *.* to 'rpl'@'192.168.135.%'; flush privileges; select user,host from mysql.user;
【4】在从库上运行主从配置
stop slave;
change master to master_host='192.168.135.158', master_port=3306, master_user='rpl', master_password='123456', master_auto_position=1;
start slave;
如果是多主一从
对于需要多主一从情况(假设另一主库为157，账号为rpl)： B mysql> CHANGE MASTER TO MASTER_HOST='192.168.135.157', MASTER_USER='rpl', MASTER_PASSWORD='123456', master_auto_position=1 for CHANNEL 'm1'; CHANGE MASTER TO MASTER_HOST='192.168.1.158', MASTER_USER='rpl', MASTER_PASSWORD='123456', master_auto_position=1 for CHANNEL 'm2';
【5】核验
【5.1】show slave status\G 查看是否有误
OK。两个线程启动了，Error字样的字段也没有任何问题。
【5.2】核验之前创建的用户是否有同步过来
OK，没有问题。
【5.3】在主库创建测试数据库与测试表查看同步情况
#创建test2库，以及test2.test1表 create database test2; create table test2.test1(id int); insert into test2.test1 values(1);
commit; select * from test2.test1;
从库查看
select * from test2.test1;
OK 核验完成。
【5.4】show global variables like '%gtid%' ; 查看GTID信息
可以查看是否开启，图中框出来的是最新事务的GTID，可以在主从上对照查看事务是否同步。
二、一主多从
步骤与一主一从一样，我们这里主要讲一主多从的主从切换
【1】环境
操作系统：CentOS linux 7.5
数据库版本：5.7.26
数据库架构：主从复制，主库用于生产，从库用于数据容灾和主库备机，采用默认传统的异步复制。
主库IP：192.168.135.158 端口：3306
从库IP：192.168.135.159 端口：3306
从库IP：192.168.135.160 端口：3306
【2】配置新从库192.168.135.160
【2.1】修改 my.cnf（具体参考上面一主一从）
【2.2】停止从库 =》运行change master to =》开启从库
【2.3】验证状态；show slave status\G
【3】主从切换，把158=>159
158 主库必须是停业务，或者宕机状态。且从库已经同步完现有数据。否则会数据不一致。
【3.1】在159、160操作，查看数据同步情况
stop slave io_thread;
（1）show global variables like '%gtid_executed%' ; 查看gtid值是否一样？
（2）show slave status\G
从库根据这个字段与主库的 show global variables like '%gtid_executed%' ; 对应
上面的那个字段，Retrieved_Gtid_Set 这个字段，当主库数据比从库多，之后再开启主从，这里记录了最后一个的恢复同步的GTID事务（或者说是回复到的点）
（3）确保IO线程已经没有事务在跑，状态如下
【3.2】主从切换 158-》159 具体操作
-- 原从1，现主，159：
stop slave;
-- 原从2，现从，160： 当159和158有相同的复制账户及端口时，可以只改master_host即可，我们这里my.cnf与账户都是一样的，所以只需要改master_host。否则就要和最初配置一样，5个都要改
stop slave;
change master to
master_host='192.168.135.159';
-- ,master_user='rpl'
-- ,master_password='123456'
-- ,master_port=3306
-- ,master_auto_position=1;
start slave;
-- 原主，现从，158：
stop slave;
change master to
master_host='192.168.135.159',
master_user='rpl',
master_password='123456',
master_port=3306,
master_auto_position=1;
start slave;
【3.3】核验
使用 【一】中的【5】方法核验
参考：
GTID详解：https://blog.csdn.net/wmq880204/article/details/53160078
GTID详解：https://blog.csdn.net/thundermeng/article/details/50401150
