MySQL多線程復制碰到Error_code: 1872的處理計劃。本站提示廣大學習愛好者：（MySQL多線程復制碰到Error_code: 1872的處理計劃）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL多線程復制碰到Error_code: 1872的處理計劃正文
上周在臨盆情況上碰到一個成績，不敢獨享，拿出來給小同伴們做個簡略的分享。
原由 ：因為IDC機房斷電（估量又是哪裡被發掘機碰了下吧），招致一切辦事重視啟，影響到了個中的MySQL數據庫。來看下這時候數據庫碰到的成績：
數據庫版本 ：MySQL 5.7.10
成績表示
：從機復制報以下毛病：Slave SQL for channel ”: Slave failed to initialize relay log info structure from the repository, Error_code: 1872
用了Inside君的MySQL尺度設置裝備擺設文件模板，怎樣沒有完成crash safe呢？其實,這重要是由於多線程復制（MTS）所惹起。不知MySQL 5.7，即便MySQL 5.6也異樣會碰到成績。
在MTS場景下，能夠會湧現以下兩個成績：
gap事務：後履行的事務先回放（apply）了
Exec_Master_Log_Pos地位禁絕確：能夠存在曾經事務曾經提交，然則地位還沒更新（單線程復制不存在此成績）
gap事務比擬好懂得，由於豈論是基於database級其余MTS，照樣基於logical_clock的MTS，都能夠存鄙人面的這類場景：
因為MTS的緣由，前面的事務能夠比後面的事務早履行，如上圖終能夠事務tx2和tx4都曾經提交了，然則事務tx1和tx3還未提交。這時候就稱為存在gap事務。在基於logical_clock的MTS場景下，用戶可以經由過程設置裝備擺設 參數slave_preserve_commit_order=1 來包管提交的次序性。
另外一方面，這時候Exec_Master_Log_Pos也是禁絕確的，當產生crash時，master info中仍然記載的是tx1事務開端履行的地位（見上圖左邊的部門）。切記，即便將參數slave_preserve_commit_order設置為1，MTS場景下仍然不克不及包管Exec_Master_Log_Pos是精確的，其稱之為 gap-free low-watermark 。由於MTS場景下關於表slave_realy_info_log的更新其實不是事務的（這個須要好好領會下）。
但是，MTS場景下引入了新的事務表slave_worker_info，用以表現產生宕機時每一個線程更新到的地位，其與Worker線程的回放是事務的。是以，MySQL在恢復的時刻可以經由過程經由過程Exec_Master_Log_Pos與表slave_worker_info的列Master_log_pos做比較，斷定能否須要回放以後事務。
在MySQL 5.7.13版本之前，當產生宕機後須要手動履行以下操作，若直接履行CHANGE MASTER TO操作，則能夠會觸發上述1872毛病：
START SLAVE UNTIL SQL_AFTER_MTS_GAPS; START SLAVE SQL_THREAD;
因為辦事器上的MySQL版本為5.7.10，而DBA試圖經由過程敕令CHANGE MASTER TO來修復復制成績，是以招致了上述成績。而在MySQL 5.7.13版本後，上述成績將有MySQL主動修復。簡略來講，即便產生了宕機，也能精確並主動地恢復復制的運轉狀況。
不外，當Inside進級到MySQL 5.7.15進程時，又碰到了一個不年夜不小的坑，這個就留著等下回分享吧。
