快捷導(dǎo)航

MySQL多線程復(fù)制遇到Error_code: 1872的解決方案

更新時(shí)間：2016年09月27日 09:02:36 作者：InsideMySQL

本文給大家分享的是在使用mysql主從復(fù)制的時(shí)候遇到Error_code: 1872錯(cuò)誤的解決方法，非常的簡(jiǎn)單，有需要的小伙伴可以參考下

上周在生產(chǎn)環(huán)境上遇到一個(gè)問(wèn)題，不敢獨(dú)享，拿出來(lái)給小伙伴們做個(gè)簡(jiǎn)單的分享。

起因：由于IDC機(jī)房斷電（估計(jì)又是哪里被挖掘機(jī)碰了下吧），導(dǎo)致所有服務(wù)器重啟，影響到了其中的MySQL數(shù)據(jù)庫(kù)。來(lái)看下這時(shí)數(shù)據(jù)庫(kù)遇到的問(wèn)題：

數(shù)據(jù)庫(kù)版本：MySQL 5.7.10

問(wèn)題表現(xiàn)

：從機(jī)復(fù)制報(bào)如下錯(cuò)誤：Slave SQL for channel ”: Slave failed to initialize relay log info structure from the repository, Error_code: 1872

用了Inside君的MySQL標(biāo)準(zhǔn)配置文件模板，怎么沒(méi)有實(shí)現(xiàn)crash safe呢？其實(shí),這主要是因?yàn)槎嗑€程復(fù)制（MTS）所引起。不知MySQL 5.7，即使MySQL 5.6也同樣會(huì)遇到問(wèn)題。

在MTS場(chǎng)景下，可能會(huì)出現(xiàn)以下兩個(gè)問(wèn)題：

gap事務(wù)：后執(zhí)行的事務(wù)先回放（apply）了
Exec_Master_Log_Pos位置不準(zhǔn)確：可能存在已經(jīng)事務(wù)已經(jīng)提交，但是位置還沒(méi)更新（單線程復(fù)制不存在此問(wèn)題）
gap事務(wù)比較好理解，因?yàn)椴徽撌腔赿atabase級(jí)別的MTS，還是基于logical_clock的MTS，都可能存在下面的這種場(chǎng)景：

由于MTS的原因，后面的事務(wù)可能比前面的事務(wù)早執(zhí)行，如上圖終可能事務(wù)tx2和tx4都已經(jīng)提交了，但是事務(wù)tx1和tx3還未提交。這時(shí)就稱為存在gap事務(wù)。在基于logical_clock的MTS場(chǎng)景下，用戶可以通過(guò)配置參數(shù)slave_preserve_commit_order=1 來(lái)保證提交的順序性。

另一方面，這時(shí)Exec_Master_Log_Pos也是不準(zhǔn)確的，當(dāng)發(fā)生crash時(shí)，master info中依然記錄的是tx1事務(wù)開(kāi)始執(zhí)行的位置（見(jiàn)上圖右邊的部分）。切記，即使將參數(shù)slave_preserve_commit_order設(shè)置為1，MTS場(chǎng)景下依然不能保證Exec_Master_Log_Pos是準(zhǔn)確的，其稱之為 gap-free low-watermark 。因?yàn)镸TS場(chǎng)景下對(duì)于表slave_realy_info_log的更新并不是事務(wù)的（這個(gè)需要好好體會(huì)下）。

然而，MTS場(chǎng)景下引入了新的事務(wù)表slave_worker_info，用以表示發(fā)生宕機(jī)時(shí)每個(gè)線程更新到的位置，其與Worker線程的回放是事務(wù)的。因此，MySQL在恢復(fù)的時(shí)候可以通過(guò)通過(guò)Exec_Master_Log_Pos與表slave_worker_info的列Master_log_pos做對(duì)比，判斷是否需要回放當(dāng)前事務(wù)。

在MySQL 5.7.13版本之前，當(dāng)發(fā)生宕機(jī)后需要手動(dòng)執(zhí)行如下操作，若直接執(zhí)行CHANGE MASTER TO操作，則可能會(huì)觸發(fā)上述1872錯(cuò)誤：

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
START SLAVE SQL_THREAD;

由于服務(wù)器上的MySQL版本為5.7.10，而DBA試圖通過(guò)命令CHANGE MASTER TO來(lái)修復(fù)復(fù)制問(wèn)題，因此導(dǎo)致了上述問(wèn)題。而在MySQL 5.7.13版本后，上述問(wèn)題將有MySQL自動(dòng)修復(fù)。簡(jiǎn)單來(lái)說(shuō)，即使發(fā)生了宕機(jī)，也能準(zhǔn)確并自動(dòng)地恢復(fù)復(fù)制的運(yùn)行狀態(tài)。

不過(guò)，當(dāng)Inside升級(jí)到MySQL 5.7.15過(guò)程時(shí)，又遇到了一個(gè)不大不小的坑，這個(gè)就留著等下回分享吧。

您可能感興趣的文章: