?大部分的錯誤，都是日志錯誤

日志本身的錯誤

主日志和中繼日志都可能出錯，可以使用mysqlbinlog來讀一下
mysqlbinlog mysql-bin.000007>/dev/null 　　　　 ##只顯示錯誤
mysqlbinlog server3-relay-bin.000004>/dev/null

跳過日志錯誤
有時候可能是日志的本身沒錯，但SQL解釋出錯，比如mysql主從數據的不一致，導致有的M上的操作在slave上執行不下去，從而終止了?replication。此時就可以手動跳過日志，但是有可能出現數據不一致的情況如果主日志出錯，可以才slave上執行,如果有多個錯誤可能要執行多次

傳統的復制下，可以執行下面的操作
stop slave；
set global sql_slave_skip_counter = 1; ##最好設定為1，每次只跳過一個錯誤，這樣有利于查看哪里發生了錯誤，對之后讓MS數據一致會有所幫助的
start slave;

但是mysql的GTIDs不支持上面的處理的方法，因為上面的處理是基礎
position來進行的

中繼日志出錯

傳統的復制下，可以執行下面的操作

在slave上查看復制的狀態，根據日志跳過出錯的日志

STOP　SLAVE
CHANGE　MASTER　TO
MASTER＿LOG_FILE＝"replay_master_log_file"
MASTER＿LOG_POS="eexec_master_log_pos"
START　SLAVE
同樣上面的處理方案只能在傳統的復制下使用，但是GTIDs上不能使用
STOP　SLAVE
SET　GTID＿NEXT＝＂uuid：next_id＂　##一般next_id當前出錯的next_id+1
BEGIN；
COMMIT；
SET　GTID＿NEXT＝＂ＡＵＴＯＭＡＴＩＣ＂；
START　SLAVE
＊只需要修改其中的一臺的slave，其他的就自動恢復

##這里我有點不可思議。。。

轉載于:https://www.cnblogs.com/wxl-dede/p/5070787.html

總結

以上是生活随笔為你收集整理的mysql replication错误常见处理的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。