跳過復制錯誤
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