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引數。
前一陣子機房網路升級,但是考慮到一般網路故障恢復之後,只需要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引數。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29012686/viewspace-1182638/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- MySQL Slave異常關機的處理 (pt-slave-restart)MySqlREST
- MySQL異常處理MySql
- 異常處理機制
- 異常處理機制(二)之異常處理與捕獲
- java異常的處理機制Java
- Java 的異常處理機制Java
- vmware虛擬機器異常關閉處理虛擬機
- MySQL定義異常和異常處理詳解MySql
- Java異常處理機制Java
- MySQL遊標和異常處理MySql
- SpringMVC異常的處理機制SpringMVC
- Java 中的異常處理機制Java
- Struts的異常處理機制 (轉)
- 異常篇——異常處理
- 異常-throws的方式處理異常
- 當機導致slave異常分析
- 08.異常處理機制
- C++異常處理機制C++
- Python異常處理機制Python
- 異常處理
- C#中的異常處理機制C#
- MySQL儲存過程的異常處理方法MySql儲存過程
- log列印及異常處理相關
- goang 錯誤&異常處理機制Go
- Asp.Net 異常處理機制ASP.NET
- 解析Oracle developer 異常處理機制OracleDeveloper
- 異常處理與異常函式函式
- JavaScript 異常處理JavaScript
- ThinkPHP 異常處理PHP
- React 異常處理React
- 08、異常處理
- Java 異常處理Java
- JAVA 異常處理Java
- JAVA異常處理Java
- Abp 異常處理
- oracle異常處理Oracle
- PowerShell 異常處理
- plsql異常處理SQL