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

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

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

問題表現(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)配置文件模板，怎么沒有實(shí)現(xiàn)crash safe呢？其實(shí),這主要是因?yàn)槎嗑€程復(fù)制（MTS）所引起。不知MySQL 5.7，即使MySQL 5.6也同樣會遇到問題。

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

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

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

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

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

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

START SLAVE UNTIL SQL_AFTER_MTS_GAPS;
START SLAVE SQL_THREAD;

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

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

最新評論