MySQL主從復制斷開的常用修復方法
01 問題描述
在生產環境中，我們經常會遇見MySQL主從復制斷開的情況，在遇到主從復制斷開是，通常情況，解決問題的步驟如下：
1、從庫上show slave status查看復制斷開的直觀原因，並記錄當前的復制位點
2、查看error log，分析更詳細的復制斷開原因
3、修復主從復制關系
4、如果復制關系無法修復，則需要重新搭建從庫
02 解決問題的方法
主從復制關系斷裂，有各種各樣的原因。有些時候，我們沒有時間去客觀分析原因，因為應用程序處於無法使用狀態，需要立即恢復，這種情況下，我們對復制斷裂問題和服務可用性之間必須做一個權衡，然後再進行相應的處理。
常見的解決主從復制斷裂的方法有以下幾種：
1、找到其他從庫，快速替換
這種方法，需要你的應用具有至少一主兩從的架構，其中一個從庫發生問題，可以將另外一個從庫快速上線，從而恢復應用訪問，後續再來排查出現故障的從庫的具體問題原因。
2、跳過復制失敗的錯誤
有些情況下，我們可以判斷主從復制斷裂的原因，例如主庫上比從庫上多一個數據庫db_1,那麼當我們在主庫上執行drop database db_1的時候，從庫的復制一定會斷開。這種情況下，我們可以通過跳過一個事務來解決。
方法一：(直接跳過當前事務)
在GTID模式下，可以通過下面的命令來解決：
mysql> STOP SLAVE; mysql> SET GTID_NEXT='xxxxxx:yyy'; ----- 設置需要跳過的gtid event mysql> BEGIN;COMMIT; mysql> SET GTID_NEXT='AUTOMATIC'; mysql> START SLAVE;
在非GTID模式下，可以通過下面的命令來解決：
stop slave; set sql_slave_skip_counter=1; start slave;
方法二：(指定新位置)
如果我們通過binlog分析，知道瞭下一個事務的具體點位，也可以指定下一個事務具體位置的方法來解決：
GTID模式下：
mysql> STOP SLAVE; mysql> RESET MASTER; mysql> SET @@GLOBAL.GTID_PURGED ='xxxxxxx：yyyyyy' ----- 表示這些gtid event已經執行過瞭 mysql> START SLAVE;
註意，GTID_PURGED 必須是 GLOBAL，上面的命令也可以寫成set global gtid_purged=’xxx:yyy’
非GTID模式下：
stop slave; change master to master_log_file='mysql-bin.001360',master_log_pos=676383371; start slave;
方法三：pt-slave-restart工具
如果我們跳過一個事務之後，還出現斷開的場景(例如我們在從庫上刪除瞭100條數據，但是主庫要更新這100條數據)，可以使用pt-slave-restart這個工具，它可以連續跳過斷開的位置。
它的使用方法如下：
pt-slave-restart -h 10.xxx.xxx.xxx -P port -u user -p password
當我們使用並行復制的時候，pt-slave-restart可能會出現報錯，這個時候我們可以通過將並行復制修改為單線程復制，然後再使用pt-slave-restart工具，可以參考這篇文章：
pt-slave-restart工具
方法四：設置參數slave_exec_mode
這個參數可以修改主從復制過程中的從庫執行模式，如果是strict嚴格模式，則所有的復制一旦報錯就會停止，如果設置成idempotent冪等模式，則特定錯誤號的錯誤將會被跳過。命令如下：
set global slave_exec_mode = idempotent
具體可以參考之前的文章：
MySQL復制問題的三個參數介紹
這篇文章中還有其他兩種跳過復制錯誤的參數，分別是slave_skip_errors、sql_slave_skip_counter
3、利用備份重建從庫
這種方法的使用場景不多，通常情況下，隻有從庫已經不可用或者無法從主庫同步的時候，才會考慮這種方法，例如主庫上執行瞭reset master操作，導致所有的binlog被清理瞭，這樣從庫就無法獲取讀取正確的binlog，復制就會斷開，這種情況下，重建從庫可能是唯一的辦法瞭。
以上就是MySQL主從復制斷開的常用修復方法的詳細內容，更多關於MySQL主從復制斷開修復的資料請關註WalkonNet其它相關文章！
推薦閱讀：
- None Found