《Mysql必讀MySQL多線程復(fù)制遇到Error_code: 1872的解決方案》要點(diǎn)：
本文介紹了Mysql必讀MySQL多線程復(fù)制遇到Error_code: 1872的解決方案，希望對您有用。如果有疑問，可以聯(lián)系我們。

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

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

數(shù)據(jù)庫版本 ：MySQL 5.7.10MYSQL實(shí)例

問題表現(xiàn)MYSQL實(shí)例

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

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

在MTS場景下,可能會(huì)出現(xiàn)以下兩個(gè)問題：MYSQL實(shí)例

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,都可能存在下面的這種場景：MYSQL實(shí)例

MYSQL實(shí)例

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

另一方面,這時(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è)需要好好體會(huì)下).MYSQL實(shí)例

然而,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實(shí)例

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

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).MYSQL實(shí)例

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

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/2269.html