MySQL Slave異常關機的處理

MySQL Slave異常關機的處理

生產環境有一個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參數。

 

--------------------------------------分割線 --------------------------------------

Ubuntu 14.04下安裝MySQL

《MySQL權威指南(原書第2版)》清晰中文掃描版 PDF

Ubuntu 14.04 LTS 安裝 LNMP Nginx\PHP5 (PHP-FPM)\MySQL

Ubuntu 14.04下搭建MySQL主從伺服器

Ubuntu 12.04 LTS 構建高可用分布式 MySQL 叢集

Ubuntu 12.04下原始碼安裝MySQL5.6以及Python-MySQLdb

--------------------------------------分割線 --------------------------------------

本文永久更新連結地址：