01 問(wèn)題描述

      在生產(chǎn)環(huán)境中，我們經(jīng)常會(huì)遇見(jiàn)MySQL主從復(fù)制斷開(kāi)的情況，在遇到主從復(fù)制斷開(kāi)是，通常情況，解決問(wèn)題的步驟如下：

1、從庫(kù)上show slave status查看復(fù)制斷開(kāi)的直觀原因，并記錄當(dāng)前的復(fù)制位點(diǎn)

2、查看error log，分析更詳細(xì)的復(fù)制斷開(kāi)原因

3、修復(fù)主從復(fù)制關(guān)系

4、如果復(fù)制關(guān)系無(wú)法修復(fù)，則需要重新搭建從庫(kù)

02 解決問(wèn)題的方法

      主從復(fù)制關(guān)系斷裂，有各種各樣的原因。有些時(shí)候，我們沒(méi)有時(shí)間去客觀分析原因，因?yàn)閼?yīng)用程序處于無(wú)法使用狀態(tài)，需要立即恢復(fù)，這種情況下，我們對(duì)復(fù)制斷裂問(wèn)題和服務(wù)可用性之間必須做一個(gè)權(quán)衡，然后再進(jìn)行相應(yīng)的處理。

常見(jiàn)的解決主從復(fù)制斷裂的方法有以下幾種：

1、找到其他從庫(kù)，快速替換

   這種方法，需要你的應(yīng)用具有至少一主兩從的架構(gòu)，其中一個(gè)從庫(kù)發(fā)生問(wèn)題，可以將另外一個(gè)從庫(kù)快速上線，從而恢復(fù)應(yīng)用訪問(wèn)，后續(xù)再來(lái)排查出現(xiàn)故障的從庫(kù)的具體問(wèn)題原因。

2、跳過(guò)復(fù)制失敗的錯(cuò)誤

    有些情況下，我們可以判斷主從復(fù)制斷裂的原因，例如主庫(kù)上比從庫(kù)上多一個(gè)數(shù)據(jù)庫(kù)db_1,那么當(dāng)我們?cè)谥鲙?kù)上執(zhí)行drop database db_1的時(shí)候，從庫(kù)的復(fù)制一定會(huì)斷開(kāi)。這種情況下，我們可以通過(guò)跳過(guò)一個(gè)事務(wù)來(lái)解決。

方法一：(直接跳過(guò)當(dāng)前事務(wù))

    在GTID模式下，可以通過(guò)下面的命令來(lái)解決：

mysql> STOP SLAVE;
mysql> SET GTID_NEXT='xxxxxx:yyy'; ----- 設(shè)置需要跳過(guò)的gtid event
mysql> BEGIN;COMMIT;
mysql> SET GTID_NEXT='AUTOMATIC';
mysql> START SLAVE;

   在非GTID模式下，可以通過(guò)下面的命令來(lái)解決：

stop slave;
set sql_slave_skip_counter=1;
start slave;

方法二：(指定新位置)

    如果我們通過(guò)binlog分析，知道了下一個(gè)事務(wù)的具體點(diǎn)位，也可以指定下一個(gè)事務(wù)具體位置的方法來(lái)解決：

GTID模式下：

mysql>  STOP SLAVE;
mysql>  RESET MASTER;
mysql>  SET @@GLOBAL.GTID_PURGED ='xxxxxxx：yyyyyy'  ----- 表示這些gtid event已經(jīng)執(zhí)行過(guò)了
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工具

    如果我們跳過(guò)一個(gè)事務(wù)之后，還出現(xiàn)斷開(kāi)的場(chǎng)景(例如我們?cè)趶膸?kù)上刪除了100條數(shù)據(jù)，但是主庫(kù)要更新這100條數(shù)據(jù))，可以使用pt-slave-restart這個(gè)工具，它可以連續(xù)跳過(guò)斷開(kāi)的位置。

    它的使用方法如下：

pt-slave-restart -h 10.xxx.xxx.xxx -P port -u user -p password

   當(dāng)我們使用并行復(fù)制的時(shí)候，pt-slave-restart可能會(huì)出現(xiàn)報(bào)錯(cuò)，這個(gè)時(shí)候我們可以通過(guò)將并行復(fù)制修改為單線程復(fù)制，然后再使用pt-slave-restart工具，可以參考這篇文章：

pt-slave-restart工具

方法四：設(shè)置參數(shù)slave_exec_mode

     這個(gè)參數(shù)可以修改主從復(fù)制過(guò)程中的從庫(kù)執(zhí)行模式，如果是strict嚴(yán)格模式，則所有的復(fù)制一旦報(bào)錯(cuò)就會(huì)停止，如果設(shè)置成idempotent冪等模式，則特定錯(cuò)誤號(hào)的錯(cuò)誤將會(huì)被跳過(guò)。命令如下：

set global slave_exec_mode = idempotent

具體可以參考之前的文章：

MySQL復(fù)制問(wèn)題的三個(gè)參數(shù)介紹

這篇文章中還有其他兩種跳過(guò)復(fù)制錯(cuò)誤的參數(shù)，分別是slave_skip_errors、sql_slave_skip_counter

3、利用備份重建從庫(kù)

   這種方法的使用場(chǎng)景不多，通常情況下，只有從庫(kù)已經(jīng)不可用或者無(wú)法從主庫(kù)同步的時(shí)候，才會(huì)考慮這種方法，例如主庫(kù)上執(zhí)行了reset master操作，導(dǎo)致所有的binlog被清理了，這樣從庫(kù)就無(wú)法獲取讀取正確的binlog，復(fù)制就會(huì)斷開(kāi)，這種情況下，重建從庫(kù)可能是唯一的辦法了。

以上就是MySQL主從復(fù)制斷開(kāi)的常用修復(fù)方法的詳細(xì)內(nèi)容，更多關(guān)于MySQL主從復(fù)制斷開(kāi)修復(fù)的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論