主从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复制下遇到了错误如何解决。

场景描述

使用show slave status\G 查看主备复制状态时 错误如下:

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 12:56:57]>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: 28074558 Relay_Log_File: mysql-relay-bin.000011 Relay_Log_Pos: 100311 Relay_Master_Log_File: mysql-bin.000003 Slave_IO_Running: Yes Slave_SQL_Running: No Replicate_Do_DB: Replicate_Ignore_DB: Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: Replicate_Wild_Ignore_Table: Last_Errno: 1007 Last_Error: Error 'Can't create database 'dhy2'; database exists' on query. Default database: 'dhy2'. Query: 'create database dhy2' Skip_Counter: 0 Exec_Master_Log_Pos: 28073671 Relay_Log_Space: 287925 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: NULLMaster_SSL_Verify_Server_Cert: No Last_IO_Errno: 0 Last_IO_Error: Last_SQL_Errno: 1007 Last_SQL_Error: Error 'Can't create database 'dhy2'; database exists' on query. Default database: 'dhy2'. Query: 'create database dhy2' 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: Master_Retry_Count: 86400 Master_Bind: Last_IO_Error_Timestamp: Last_SQL_Error_Timestamp: 160408 12:57:02 Master_SSL_Crl: Master_SSL_Crlpath: 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: 01 row in set (0.00 sec)

根据报错描述:

Last_SQL_Error: Error 'Can't create database 'dhy2'; database exists' on query. Default database: 'dhy2'. Query: 'create database dhy2' dhy2 这个数据库已经在备库存在

我们在备库上面show database 查看dhy2这个数据库确实是存在的:

[root@shadow1:/root 5.6.28-log_Instance1 root@localhost:test 12:57:04]>show databases;+--------------------+| Database |+--------------------+| information_schema || dhy2 || mysql || performance_schema || test |+--------------------+7 rows in set (0.00 sec)

修改过程

当我们使用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: 0Master_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