如何进行MySQL主从GTID复制修复

如何进行MySQL主从GTID复制修复，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。

GTID是5.6新增特性，减少DBA运维的工作。在以前一主两从架构下当主库M1发生故障我们需要选择一个从库S1作为新的主库，但是S2要重新change master 到新主库上 这时master_log_file和master_log_pos我们怎么获取到呢？在没有GTID时 MHA架构帮我们解决了这个问题，在有了GTID情况下，我们只需要在S2上面重新change master下设置MASTER_AUTO_POSITION = 1即可。 本文介绍下在GTID复制下遇到了错误如何解决。

场景描述

当我们使用GTID复制时，不能像传统复制一样跳过事务，只能注册一个空的事务骗过MySQL。具体操作步骤如下:

查看当前备份的GTID执行情况

           Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462

Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459,

e28420fb-f0be-11e5-af62-0050562edd64:1-81209

Auto_Position: 0

Retrieved_Gtid_Set 代表已经接受到的GTID集合 

Executed_Gtid_Set 代码已经执行的GTID集合

针对上面GTID执行情况 我们可以看到:

Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462

Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459

接收到了71462 执行到了71459就报错了。

手工注册事务

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 12:59:41]>stop slave;

Query OK, 0 rows affected (0.00 sec)

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:04:57]>set gtid_next=dd2a02a3-f0be-11e5-af62-0050563a97cc:71460;

Query OK, 0 rows affected (0.00 sec)

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:23]>begin;

Query OK, 0 rows affected (0.00 sec)

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:29]>commit;

Query OK, 0 rows affected (0.02 sec)

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:31]>SET GTID_NEXT=AUTOMATIC;

Query OK, 0 rows affected (0.00 sec)

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:36]>start slave;

Query OK, 0 rows affected (0.00 sec)

这里需要注意的是

set gtid_next=dd2a02a3-f0be-11e5-af62-0050563a97cc:71460; 这个值是

Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-71459  71459这个GTID+1

并且 uuid一定是Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-71462 接收到这里显示的uuid

再次查看show slave status\G 已经恢复正常

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 13:05:39]>show slave status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

Master_Host: 10.10.30.101

                  Master_User: repl

                  Master_Port: 3306

                Connect_Retry: 10

              Master_Log_File: mysql-bin.000003

Read_Master_Log_Pos: 28275288

               Relay_Log_File: mysql-relay-bin.000012

                Relay_Log_Pos: 21794

Relay_Master_Log_File: mysql-bin.000003

             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: 28275288

              Relay_Log_Space: 302335

              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: 101

                  Master_UUID: dd2a02a3-f0be-11e5-af62-0050563a97cc

             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 the slave I/O thread to update it

           Master_Retry_Count: 86400

                  Master_Bind:

      Last_IO_Error_Timestamp:

Last_SQL_Error_Timestamp:

               Master_SSL_Crl:

           Master_SSL_Crlpath:

Retrieved_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:70261-72005

            Executed_Gtid_Set: dd2a02a3-f0be-11e5-af62-0050563a97cc:1-72005,

e28420fb-f0be-11e5-af62-0050562edd64:1-81209

                Auto_Position: 0

看完上述内容，你们掌握如何进行MySQL主从GTID复制修复的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注行业资讯频道，感谢各位的阅读！