生產環境有一個MySQL的Master-Slave的複製。
前一陣子機房網路升級,但是考慮到一般網路故障恢復之後,只需要start slave即可
所以沒有做任何的處理。
但是第二天上班的時候，在Slave資料庫上輸入命令，start slave 不能重新啟動複製。

模擬環境如下

在Slave上啟動複製，報錯如下

複製過程出現主鍵重複了

最後，使用status檢視，發現MySQL被重啟過。
估計在割接過程中，莫名其妙的被人按了伺服器的重啟鍵吧。

但是MySQL複製針對這種情況，異常的脆弱，因為複製的資訊都寫在一個檔案裡，
考慮到效能的原因，這個寫入並不是同步的。
也就是說在斷電重啟的瞬間，複製的情況並沒有寫入到檔案中。
而再次啟動之後，讀取這個檔案中記錄的複製位置，肯定落後於實際執行的位置。
所以會發生主鍵重複的問題，因為這個記錄實際已經執行過了。

解決這個問題有三種方式
1.設定sql_slave_skip_counter跳過Master發來的事件,直到正常的位置

啟動之後，發現報錯資訊已經變了

他重複的主鍵已經從7940到了7946了，也就說透過一點一點的推進，是可以推進到正常的複製位置的。
但是工作量比較大，需要很有耐心和時間做這個事情。

2.設定slave_skip_errors
在my.cnf配置檔案中設定slave_skip_errors=1062，跳過所有主鍵重複的錯誤。
但是這個引數設定之後，需要重啟服務。對於生產系統來說，沒有實際意義。

3.設定slave_exec_mode
MySQL預設的slave執行方式是嚴格的。
類似主鍵重複的問題，會直接停止複製，等待人工介入。
slave_exec_mode是一個動態引數，如果設定為IDEMPOTENT可以自動忽略主鍵重複和沒有找到記錄的錯誤。
但是貌似只是在MySQL叢集環境有效
http://dev.mysql.com/doc/refman/5.6/en/replication-options-slave.html#sysvar_slave_exec_mode

異常斷電和關機除了可能導致主鍵重複的錯誤之外，還可能導致中繼日誌損壞

針對這個問題，首先，找到master binlog執行的位置

位置

然後重新連線Master伺服器,(需要先停止slave)

最後檢視複製情況，已經正常。

這次的經驗是，如果預計可能發生狀況，比如這次網路割接，
可以先停止slave的伺服器。因為我們的slave只是作為備份的一種方式，而不是用於讀寫分離。
或者乾脆設定slave_skip_errors引數。

MySQL Slave異常關機的處理

相關文章