問題描述：發現主庫操作數據從庫沒有變動問題，可能原因是從庫重啟導致的無法同步問題。 排查思路： 1、查看主從複製狀態 發現從庫的IO和SQL進程都是no(正常狀態應該是yes) 註意：mysql replication中slave機器上有兩個關鍵進程，死一個都不行，一個是slave_sql_runn ...
問題描述：發現主庫操作數據從庫沒有變動問題，可能原因是從庫重啟導致的無法同步問題。
排查思路：
1、查看主從複製狀態
發現從庫的IO和SQL進程都是no(正常狀態應該是yes)
註意：mysql replication中slave機器上有兩個關鍵進程，死一個都不行，一個是slave_sql_running,一個是slave_io_running，一個負責與主機的IO通信，一個負責自己的slave mysql進程。
2、解決辦法如下：
>stop slave; ##停止同步
> SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; ##設置counter為1,啟動同步
>show slave status\G; ##查看同步狀態
3、發現SQL進程還是No
提示信息顯示如下：
Last_Errno: 1396
Last_Error: Coordinator stopped because there were error(s) in the worker(s). The most recent failure being: Worker 1 failed executing transaction 'fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9' at master log mybinlog.000001, end_log_pos 1966. See error log and/or performance_schema.replication_applier_status_by_worker table for more details about this failure or others, if any.
4、根據上面的提示，查詢到的異常數據出現在opp_starck表中
#select * from performance_schema.replication_applier_status_by_worker\G; 確定事務發生在表opp_strack上，定位在表上，再去排查是哪張表
可以參考：https://blog.csdn.net/memory6364/article/details/86152717
5、主從數據恢復一致後需要在slave上跳過報錯的事務，在從庫中執行
使用GTID跳過錯誤的方法：找到錯誤的GTID跳過（通過exec_master_log_pos去binlog里找GTID，或者則通過監控表replication_applier_status_by_worker找到GTID，也可以通過excured_gtid_set算GTID），這裡使用監控來找到錯誤的GTID。找到GTID之後，跳過錯誤的步驟：
>stop slave; #停止同步
>set @@session.gtid_next='fab1fc64-d0f2-11ec-a2a6-000c2950bca1:9'; #跳過錯誤的GTID
>begin; #提交一個空事務，因為設置gtid_next後，gtid的生命周期就開始了，必須通過顯性的提交一個事務來結束，否則報錯：ERROR
>commit
>set @@session.gtid_next=automatic; #設置回自動模式
>start slave; #啟動同步
>show slave status\G; #再次確認狀態
6、如下圖主從複製恢復正常
GTID：是對於一個已提交事務的唯一編號，並且是一個全局(主從複製)唯一的編號。
GTID核心參數
重要參數：
gtid-mode=on --啟用gtid類型，否則就是普通的複製架構
enforce-gtid-consistency=true --強制GTID的一致性
log-slave-updates=1 --slave更新是否記入日誌
