在线开启gtid与在线关闭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. 每个从库开启master_auto_position

       这个步骤需要特别注意，对比下从库的Retrieved_Gtid_Set与Executed_Gtid_Set的并集和主库的Executed_Gtid_Set。

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)

##############################################

如果报错，请按照下面执行：

stop slave;
reset slave;
reset master;

该值=从库接受到的gtid集合 Retrieved_Gtid_Set+主库产生Executed_Gtid_Set的但从库没有的，
# 从库的Retrieved_Gtid_Set往往和Executed_Gtid_Set的值是一样的。取两者的并集：Retrieved_Gtid_Set U Executed_Gtid_Set

SET @@GLOBAL.GTID_PURGED='12a62f29-e0dc-11e9-9d20-00163e00248a:1-22470,

947b2801-e0ed-11e9-aefb-00163e00248a:1

'; # 该内容需要根据自己的备份文件中获得

#####主库：

master@10.10.10.10((none)) > show master statusG;
*************************** 1. row ***************************
             File: mysql-bin.005702
         Position: 900958585
     Binlog_Do_DB: 
 Binlog_Ignore_DB: 
Executed_Gtid_Set: 12a62f29-e0dc-11e9-9d20-00163e00248a:1-22047,
947b2801-e0ed-11e9-aefb-00163e00248a:1
1 row in set (0.07 sec)

ERROR: 
No query specified

Mon May 11 16:00:51 2020





###########从库：

slave@10.10.10.11 ((none)) > show slave statusG;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.10.10.10
                  Master_User: mysqlsync
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File: mysql-bin.005703
          Read_Master_Log_Pos: 140353981
               Relay_Log_File: relay-bin.000004
                Relay_Log_Pos: 140354146
        Relay_Master_Log_File: mysql-bin.005703
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 140353981
              Relay_Log_Space: 140354422
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 171574486
                  Master_UUID: 12a62f29-e0dc-11e9-9d20-00163e00248a
             Master_Info_File: mysql.slave_master_info
                    SQL_Delay: 0
          SQL_Remaining_Delay: NULL
      Slave_SQL_Running_State: Slave has read all relay log; waiting for more updates
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_SQL_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 12a62f29-e0dc-11e9-9d20-00163e00248a:21547-22470
            Executed_Gtid_Set: 12a62f29-e0dc-11e9-9d20-00163e00248a:1-22470,
947b2801-e0ed-11e9-aefb-00163e00248a:1
                Auto_Position: 1
         Replicate_Rewrite_DB: 
                 Channel_Name: 
           Master_TLS_Version: 
1 row in set (0.07 sec)

ERROR: 
No query specified

 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中至少一项。