【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複製下遇到了錯誤如何解決。
場景描述
使用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: NULL
Master_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: 0
1 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: 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
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28218939/viewspace-2137231/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- MySQL主從複製之GTID複製MySql
- MySQL GTID複製錯誤修復演示MySql
- Mysql 基於GTID主從複製MySql
- MySQL GTID複製中斷修復過程MySql
- mysql GTID主從複製故障後不停機恢復同步流程MySql
- MySQL 5.7基於GTID的主從複製MySql
- MySQL 5.7 基於GTID搭建主從複製MySql
- Mysql 8.4.0 結合 Docker 搭建GTID主從複製，以及傳統主從複製MySqlDocker
- MySQL8.0輕鬆搞定GTID主從複製MySql
- MySQL8.0輕鬆搞定GTID主主複製MySql
- MySQL主從複製之GTID模式詳細介紹鞴嬈MySql模式
- mysql5.7主從複製，主主複製MySql
- mysql複製--主從複製配置MySql
- MySQL主從複製MySql
- MySQL 8 複製（四）——GTID與複製MySql
- MySQL 8 複製（五）——配置GTID複製MySql
- MySQL 5.7傳統複製到GTID線上切換（一主一從）MySql
- MySQL主從複製原理MySql
- MySQL的主從複製MySql
- mysql--主從複製MySql
- mysql 8.4 主從複製MySql
- mysql主從複製搭建MySql
- MySQL主從複製之半同步複製MySql
- MySQL主從複製之非同步複製MySql非同步
- Linux下MySQL主從複製(GTID)+讀寫分離(ProxySQL)-實施筆記LinuxMySql筆記
- MySQL++：Liunx - MySQL 主從複製MySql
- MySQL（13）---MYSQL主從複製原理MySql
- mysql主從複製(一):一主多從MySql
- windows 下mysql主從複製WindowsMySql
- mysql實現主從複製MySql
- mysql主從延遲複製MySql
- MySQL 主從複製實操MySql
- MYSQL主從複製配置（整理）MySql
- MySQL主從複製歷程MySql
- MySQL-18.主從複製MySql
- Windows Mysql主從複製部署WindowsMySql
- Mysql 傳統主從複製MySql
- MySQL8.0主從複製MySql
- Windows 環境下，MySQL 的主從複製和主主複製WindowsMySql