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

70次阅读

共计 3407 个字符，预计需要花费 9 分钟才能阅读完成。

如何进行 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