mysql主從複製跳過複製錯誤【轉】

跳過複製錯誤

mysql由於binlog機制問題，有些時候會出現從庫重放sql執行失敗的狀況，特別是舊的STATEMENT模式最容易出現這種狀況（由於函數和存儲過程等緣由），這也是爲何強調使用mixed和row模式的緣由。另外就是一些外部XA事務，由於XA事務日誌不在mysql中，有時候會出現回滾失敗的狀況，致使主從報錯。

出現這些情況那該怎麼辦好呢？若是是重作，雖然是能夠，可是若是庫很是大，那耗時就不是一兩小時那麼容易，若是是作了生產讀寫分離的，就很差交代了。這個時候咱們能夠選擇手動修改數據，而後跳過這個複製錯誤，而後這個主從複製就會從新運行了。

繼續講述兩種模式，先說的是GTID模式，他能夠有兩種方式跳過。第一種是用得比較多的，注入空事務跳過：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

#找到衝突的GTID號. mysql>show slave status\G      。      。      。 Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451      。      。      。 #中止複製 mysql>stop slave; #而後執行設置一個事務GTID來跳過，就是要跳過這個事務的意思 mysql>SET gtid_next =  '09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451' ; #注入空事務 mysql>BEGIN;COMMIT; #把GTID設置回自動模式 mysql>SET gtid_next =  'AUTOMATIC' ; #從新開啓複製 mysql>START SLAVE; #這就能夠跳過一個事務了,原理在於經過執行一個空事務代替master傳遞過來的衝突事務. #固然跳過了，並不表明這個數據就不修改了，仍是要你手動去修改一下，這樣就一切迴歸正常了 mysql>update tables  set  。。。。。。。

第二種，直接跳過這個GTID，改作後面的

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

#找到衝突的GTID號. mysql>show slave status\G      。      。      。 Executed_Gtid_Set: 09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648451      。      。      。 #中止複製 mysql>stop slave; #直接設置上面的GTID值+1 mysql>SET @@GLOBAL.GTID_PURGED= '09cb91bf-2669-11e7-8b70-00163e0835ff:1-83648452' ; #從新開啓複製 mysql>START SLAVE; #固然跳過了，並不表明這個數據就不修改了，仍是要你手動去修改一下，這樣就一切迴歸正常了 mysql>update tables  set  。。。。。。。

而後就說傳統模式了，相對來講，更簡單一些

1 2 3 4 5 6 7 8

#中止複製 mysql>slave stop; #設定跳過一個事務 mysql>SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1 #從新開啓複製 mysql>slave start #這樣就正常了，可是，固然仍是要把數據修改上去 mysql>update tables  set  。。。。。。。

其實還有一個禁忌設定方式，能夠跳過一些複製報錯，由於不建議，只是拿出來講說能夠這麼幹

1 2 3 4 5 6 7

#修改配置文件 vim  /etc/my .cnf [mysqld] #跳過指定error no類型的錯誤 #slave-skip-errors=1062,1053,1146 #跳過全部錯誤 #slave-skip-errors=all

轉自

mysql主從複製跳過複製錯誤-ping_note-51CTO博客

http://blog.51cto.com/arthur376/1969935