MySQL的GTID复制与传统复制的相互转换

主库：192.168.225.128：3307
从库1：192.168.225.129：3307

Gtid作为5.6版本以来的杀手级特性，却因为不支持拓扑结构内开关而饱受诟病。如果你需要从未开启GTID的环境升级到开启GTID，需要把这个复制结构里的实例shutdown后，再重启。相信这对于任何24小时服务的互联网应用都是不可接受的。

  https://blog.csdn.net/wanbin6470398/article/details/83068044#15__88 

 master_auto_position=0 表示禁用master_auto_position

SET @@global.enforce_gtid_consistency=warn;

 SET @@global.enforce_gtid_consistency=ON;
 
 SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
 
 SET @@GLOBAL.GTID_MODE = ON_PERMISSIVE;
 
 SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
   
 SELECT MASTER_POS_WAIT('mysql-bin6.000006', 154);
 
 SET @@GLOBAL.GTID_MODE = ON;
 
 STOP SLAVE;
 
 CHANGE MASTER TO master_auto_position=1;
 
 START SLAVE;

从5.7.6开始，终于支持在线动态设置gtid_mode和enforce_gtid_consistency了。在介绍如何通过动态设置GTID MODE来开启主备复制结构的GTID之前，我们先介绍几组概念。

匿名事务：对于一个匿名事务，在主库上是不带GTID的，其传递到备库执行也不应该产生GTID。

GTID_MODE：

OFF	彻底关闭GTID，如果关闭状态的备库接受到带GTID的事务，则复制中断
OFF_PERMISSIVE	可以认为是关闭GTID前的过渡阶段，主库在设置成该值后不再生成GTID，备库在接受到带GTID 和不带GTID的事务都可以容忍 主库在关闭GTID时，执行事务会产生一个Anonymous_Gtid事件，会在备库执行： SET @@SESSION.GTID_NEXT= ‘ANONYMOUS’ 备库在执行匿名事务时，就不会去尝试生成本地GTID了
ON_PERMISSIVE	可以认为是打开GTID前的过渡阶段，主库在设置成该值后会产生GTID，同时备库依然容忍带GTID和不带GTID的事务
ON	完全打开GTID，如果打开状态的备库接受到不带GTID的事务，则复制中断

主从复制传统复制已配置完毕

一、前提：

1.要求所有的mysql版本5.7.6或更高的版本。
2.目前拓扑结构中所有的mysql的gtid_mode的值为off状态。
3.如下的操作步骤都是有序的，不要跳跃着进行。

补充一下全局系统变量GTID_MODE变量值说明：

OFF       新事务是非GTID,  Slave只接受不带GTID的事务，传送来GTID的事务会报错
OFF_PERMISSIVE 新事务是非GTID,  Slave即接受不带GTID的事务也接受带GTID的事务
ON_PERMISSIVE    新事务是GTID,  Slave即接受不带GTID的事务也接受带GTID的事务
ON                   新事务是GTID,  Slave只接受带GTID的事务

需要注意的是，这几个值的改变是有顺序的，即

off<--->OFF_PERMISSIVE<--->ON_PERMISSIVE<--->ON

不能跳跃执行，会报错。

二、传统复制切换为GTID复制

前提：测试步骤中S1默认都是打开log-bin选项的，
操作步骤

1. 在M、S实例上，将ENFORCE_GTID_CONSISTENCY设置为warning，哪台先执行不影响结果

M：mysql> set @@global.enforce_gtid_consistency=warn;
S：mysql> set @@global.enforce_gtid_consistency=warn;

注意：执行完这条语句后，如果出现GTID不兼容的语句用法，在错误日志会记录相关信息，那么需要调整应该程序避免不兼容的写法，直到完全没有产生不兼容的语句，可以通过应该程序去排查所有的sql，也可以设置后观察错误日志一段时间，这一步非常重要。

2. 在M、S上，设置ENFORCE_GTID_CONSISTENCY为ON,哪台先执行不影响结果

M：mysql> set @@global.enforce_gtid_consistency=on;
S：mysql> set @@global.enforce_gtid_consistency=on;

3. 在M、S实例上，设置GTID_MODE为off_permissiv;哪台先执行不影响结果

M：mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;
S：mysql> SET @@GLOBAL.GTID_MODE = OFF_PERMISSIVE;

4. 在M、S实例上，设置GTID_MODE为on_permissiv;哪台先执行不影响结果

M: Mysql> SET @@GLOBAL.GTID_MODE = on_permissive;
S: Mysql> SET @@GLOBAL.GTID_MODE = on_permissive;

5. 在M、S上检查变量ONGOING_ANONYMOUS_TRANSACTION_COUNT，需要等到此变量为0

Mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';
Mysql> SHOW STATUS LIKE 'ONGOING_ANONYMOUS_TRANSACTION_COUNT';

6. 确保所有的匿名事务（非GTID事务）已经被完全复制到所有的server上。

M：show master status;
S：show slave statusG
或者或者slave直接用函数：
SELECT MASTER_POS_WAIT('mysql-binlog.000005',154);

返回结果大于等于0就说明匿名事务已经全部复制完成

 

7. 确认整个拓扑结构中已经没有匿名事务的存在，

如之前产生的所有匿名事务已经全部被执行完毕，甚至二进制日志中也不要有匿名事务，可以通过flush logs，并让mysql来自动清理旧的二进制日志文件。

8. 在每个mysql实例上，设置GTID_MODE为on

M: mysql> SET @@GLOBAL.GTID_MODE = ON;
S: mysql> SET @@GLOBAL.GTID_MODE = ON;

9. 在每个mysql实例的配置文件my.cnf上，

增加:   SHOW VARIABLES LIKE '%gtid%';

gtid_mode=ON
enforce_gtid_consistency=on

10. 完成

2.9 change master

root@localhost [(none)] 11:37:17>STOP slave;
Query OK, 0 rows affected (0.00 sec)

root@localhost [(none)] 11:37:24>change master to master_auto_position=1;
Query OK, 0 rows affected (0.00 sec)

root@localhost [(none)] 11:37:52>start slave;
Query OK, 0 rows affected (0.00 sec)
---------------------

 my.cnf 配置：

log_bin = mysql-bin
bin_log = /usr/local/mysql/log/mysql-bin
binlog_format = ROW 　　　　　 //建议row

log-slave-updates=true 　　　　 //在从服务器进入主服务器传入过来的修改日志所使用，在Mysql5.7之前主从架构上使用gtid模式的话，必须使用此选项，在Mysql5.7取消了，会增加系统负载。 
enforce-gtid-consistency=true   // 强制gtid一直性，用于保证启动gitd后事务的安全； 
gtid-mode=on //开启gtid模式 
master_info_repository=TABLE 
relay_log_info_repository=TABLE　//指定中继日志的存储方式，默认是文件，这样配置是使用了 两个表，是INNODB存储引擎，好处是当出现数据库崩溃时，利用INNODE事务引擎的特点，对这两个表进行恢复，以保证从服务器可以从正确位置恢复数据。

sync-master-info=1    　　　　   //同步master_info,任何事物提交以后都必须要把事务提交以后的二进制日志事件的位置对应的文件名称，记录到master_info中，下次启动自动读取，保证数据无丢失
slave-parallel-workers=2  　　　　 //设定从服务器的启动线程数，0表示不启动
binlog-checksum=CRC32          //主服务端在启动的时候要不要校验bin-log本身的校验码
master-verify-checksum=1        //都是在服务器出现故障情况下，读取对服务器有用的数据
slave-sql-verify-checksum=1 
binlog-rows-query-log_events=1       //启用后，可用于在二进制日志记录事件相关信息，可降低故障排除复杂度（并非强制启动）

 使用基于GTID的复制时（MASTER_AUTO_POSITION = 1），首先要开启gtid_mode（在my.cnf中设置gtid-mode = ON），MASTER_LOG_FILE 与 MASTER_LOG_POS也不能使用，否则会报错。
 使用GTID后想要恢复到老的基于文件的复制协议，在change master to时需要指定MASTER_AUTO_POSITION = 0以及MASTER_LOG_FILE 或 MASTER_LOG_POSITION中至少一项。