關鍵詞：mysql復制故障處理
【1】手工處理的gtid_next（SQL線程報錯）
例如：主鍵沖突，表、數據庫不存在，row模式下的數據不存在等。
【1.1】模擬故障：GTID模式下的重復創建用戶
【1.1.1】先在從庫上創建一個用戶，再去主庫上創建一個用戶
-- 從202：
create user 'test'@'%' identified by '123456';
grant all privileges on *.* to 'test'@'%';
flush privileges;
-- 主202：
create user 'test'@'%' identified by '123456';
grant all privileges on *.* to 'test'@'%';
flush privileges;
use test;
create table test3(id int);
insert into test3 values(1);
commit;
【1.1.2】核驗同步
發現不同步
在從庫202執行：
show slave status\G -- 查看狀態
發現錯誤：
這里顯示的GTID，指的是，需要執行這個GTID事務失敗了，也就是說，真正出問題的是該GTID上面那個事務。
【1.1.3】核驗錯誤信息
根據圖上的文件名和位置在主庫上查看執行的信息是什么；
果然是創建用戶報錯了。
從這個圖，根據位置信息和GTID，應該就可以應征上面標紅說的。
查看更詳細的信息；在從庫上運行
select * from performance_schema.replication_applier_status_by_worker\G
Read_Master_Log_Pos: 2174
Exec_Master_Log_Pos: 1112
記得，這個錯誤號，就是我們報錯的那個，要對應否則可能是其他時間出現的錯誤信息；
【1.1.4】解決，跳過、屏蔽這個沖突事務
在從庫上：直接指定，下一個執行的事務，為錯誤信息上顯示的事務（因為這里顯示的GTID，是說執行到這個點出錯，這個GTID所在的事務沒有執行）
（1）由於在這個GTID必須是連續的，正常情況同一個服務器產生的GTID是不會存在空缺的。
所以不能簡單的skip掉一個事務，只能通過注入空事物的方法替換掉一個實際操作事務。
（2）注入空事物的方法：
stop slave;
set @@session.gtid_next='de853101-b165-11e9-900a-000c291f4171:8';
begin;commit;
set @@session.gtid_next='automatic'; -- 不改回來，很多報錯
start slave;
如果 set @@session.gtid_next='automatic';這時候，報錯如下。
那么意思是還沒重做完，等一下再操作即可。
mysql> set @@session.gtid_next='de853101-b165-11e9-900a-000c291f4171:18';
ERROR 1766 (HY000): The system variable gtid_next cannot be set when there is an ongoing transaction.
【1.1.5】核驗
show slave status\G -- 查看進程狀態與錯誤信息 是否OK
use test;show tables; -- 查看數據是否同步過來，OK了啊
【1.1.6】如果是主庫的最后一條事務報錯，怎么辦？
【2】非GTID模式下跳過錯誤事務
1.跳過指定數量的事務：（建議如果已經出現了錯誤，使用這種辦法） mysql>slave stop; mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; #跳過一個事務 mysql>slave start;
【3】5.7增強半同步從庫宕機如何重新連入主庫？
增強半同步從庫宕機如何重新連入主庫？（或者直接重新備份還原）
1. 此2個參數rpl_semi_sync_master_enabled 和rpl_semi_sync_slave_enabled 不要直接寫入到my.cnf配置文件開啟。 2.在slave庫上先 stop slave io_thread ;set global rpl_semi_sync_slave_enabled=0 關閉此參數。 然后start slave io_thread 或者start slave 開啟異步復制，讓slave庫追趕上master庫。 3.然后在slave庫 set global rpl_semi_sync_slave_enabled=1 ；stop slave io_thread;start slave io_thread;
【4】Slave failed to initialize relay log
mysql> start slave; ERROR 1872 (HY000): Slave failed to initialize relay log info structure from the repository 解決： reset slave;
【5】Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - master server_id is 0'
mysql -uroot -predhat -e "show slave status\G;" Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Misconfigured master - master server_id is 0' 解決： 修改server_id，id沖突
【6】UUID錯誤，刪除data下的auto.cnf
The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication to work.
或者修改這個文件內的UUID也可以
【7】主從節點GTID開啟不一致
mysql -uroot -predhat -e "show slave status\G;" The replication receiver thread cannot start because the master has GTID_MODE = ON and this server has GTID_MODE = OFF 解決： 主從節點GTID開啟不一致
【8】跳過主庫已經忽略的GTID事務
錯誤1236 Got fatal error 1236 from master when reading data from binary log:
'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.'
錯誤1236 Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.' 解決： 1，不需要重新搭建主從的方式，對於主從復制報錯，出現問題，雖然重新搭建主從是萬能法，但盡量嘗試其它方式，因為對於大數據量數據庫，重新搭建主從需要耗費很長時間。 在主庫上執行 mysql>show global variables like '%gtid_purged%'; 或 show global variables like '%gtid%'\G 查看主庫的gtid_purged的value值。 在從庫上也執行該命令，查看gtid_purged值是否和主庫相同，如果小於主庫的值如下。 2，在從庫上執行 mysql>stop slave; mysql>set @@global.gtid_purged='主庫查詢到的value值'； #'set @@global.gtid_purged='a95d8cb2-3ff7-11e9-8bfa-000c299b47f8:16-23'; mysql>begin;commit; mysql>set gtid_next='automatic'; mysql>start slave; 查看一下主從狀態。 mysql>show slave status\G; 這時的主從狀態，SQL線程和IO線程都是yes了。
一般兩種情況會出現以上現象 1.在主庫上手動執行清除二進制日志文件 2.主庫重啟，重新同步時 二、解決方法： 1.在主庫上執行以下命令，查詢gtid_purged，記錄下改值 mysql> show global variables like '%gtid%'\G wKiom1hTZpKCU8WoAABPgzDyrTQ054.png 2.在從庫上執行以下命令，查詢已經執行過的gtid即gtid_executed，記錄下主庫的值，本機的不需要 wKioL1hTZp-DQZMvAAAspE0SKJ8150.png 3.在從庫上執行以下命令停止同步線程及重置同步相關信息 mysql> stop slave; mysql> reset slave; mysql> reset master; 4.在從庫上設置gtid_purged 該值有兩個來源，一是在主庫上查詢的gtid_purged，二是在從庫上查詢的已經執行過的gtid_executed值（本機的就不需要，主庫上gtid） 注意：一定記得加上從庫上已經執行過的gtid，若只設置了主庫上的gtid_purged，此時從庫會重新拉取主庫上所有的二進制日志文件，同步過程會出現其他錯誤，導致同步無法進行 mysql> set @@global.gtid_purged='4fa9ab33-3077-11e6-8ee6-fcaa14d0751b:1-18240458,6e41a42e-8529-11e6-b72e-fcaa14d07546:1-56604052:56604054-56605629:56605631-56871196,9850e381-b601-11e6-8e46-fcaa14d07546:1-3126210,c5cdcae2-9cb0-11e6-909c-fcaa14d0751b:1-1189,10a59961-c02d-11e6-a2de-fcaa14d07546:1-13381418'; 注意：設置gtid_purged值時，gtid_executed值必須為空否則報錯，該值清空的方法就是reset master命令 執行完，再次查看相關信息
相關文章：