共計(jì) 2325 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

如何理解 mysql5. 中的并行復(fù)制，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

一、前言
    在 5.5 以及 5.5 版本之前，復(fù)制流程圖如下：

    流程：
    ① 主庫 dump thread 發(fā)現(xiàn) binlog 有更新，則向 slave 的 IO thread 推送相應(yīng)的 binlog events
    ② slave 的 IO thread 在接收到 master 新產(chǎn)生的 events 之后，寫入到自己的 relay log 中。
    ③ slave 的 SQL thread 開始應(yīng)用 relay log，執(zhí)行相應(yīng)的更新語句

    弊端：
    ① master 在多個(gè)連接 并發(fā)的寫入的情況下，slave 僅僅只有一個(gè) sql thread 進(jìn)行更新，會(huì)嚴(yán)重的造成主從延遲

二、并發(fā)復(fù)制
    官方稱之為 enhanced multi-threaded slave（簡稱 MTS），在官方 mysql5.6 版本出現(xiàn)之前，阿里就有人實(shí)現(xiàn)過 slave 的并發(fā)復(fù)制的功能，按照粒度分為 database，table  ，row 的。這里我們主要講官方版本。
    1 mysql5.6 基于 database 的并行復(fù)制
    通過 slave_parallel_workers=n 來設(shè)置并發(fā)復(fù)制的 worker 線程數(shù)量
    流程：
    ①  主庫 dump thread 發(fā)現(xiàn) binlog 有更新，則向 slave 的 IO thread 推送相應(yīng)的 binlog events
    ② slave 的 IO thread 在接收到 master 新產(chǎn)生的 events 之后，寫入到自己的 relay log 中。
        ③ slave 的 coordinator thread 根據(jù) binlog events 的 database 進(jìn)行 hash 調(diào)度分配給 worker thread
    ④ worker 線程 執(zhí)行相應(yīng)的 更新語句，互不影響

    分析：
    ① 實(shí)現(xiàn)了對 database 的并行復(fù)制，在多庫更新的情況下 slave 的寫入提升明顯，但若是 master 主要在某個(gè) database 更新的話則此并行復(fù)制比較雞肋

    2 mysql5.7 基于 database/logical_clock 的并行復(fù)制
    新添參數(shù) slave_parallel_type=DATABSE/LOGICAL_CLOCK 設(shè)定并行復(fù)制的方式，其中 database 跟 5.6 一樣，我們這里討論下為 LOGICAL_CLOCK 的模式

    原理：  通過 在 master 提交分為兩個(gè)階段 prepare 和 commit , 同時(shí) prepare 的 事物標(biāo)記相同的 last_commited(為當(dāng)前最近一次提交事務(wù)的 seq num) 。commit 的時(shí)候給相應(yīng)的事務(wù)標(biāo)記 sequence num(依次遞增)來實(shí)現(xiàn)，這些組提交的信息記錄在 GTID 中。
    流程：
    ①  主庫 dump thread 發(fā)現(xiàn) binlog 有更新，則向 slave 的 IO thread 推送相應(yīng)的 binlog events
    ② slave 的 IO thread 在接收到 master 新產(chǎn)生的 events 之后，寫入到自己的 relay log 中。
        ③ slave 的  coordinator thread 把  binlog events  中相同的  last_commited 的進(jìn)行分配給 worker thread
    ④ worker 線程 執(zhí)行相應(yīng)的 更新語句，互不影響  , 對于每個(gè)事務(wù)，其中 seq=n 的執(zhí)行完畢之后，last_commited=n 的便可以執(zhí)行了。

    這里 已經(jīng)幾乎跟 master 的 并發(fā)操作一樣了，所以對于 slave 來說這種基于 組提交的 并發(fā)復(fù)制已經(jīng)達(dá)到了 master 的并發(fā)度

    舉例：
 
 
    第一個(gè)數(shù)字為 last_commited , 第二個(gè)數(shù)字為 seq num

    slave 上執(zhí)行的順序?yàn)? 

     ① trx1 trx2 trx3
    ② trx4
    ③ trx5 trx6
    ④ trx7
    其中，trx1 執(zhí)行完畢 便可以執(zhí)行 trx4 ;trx2 執(zhí)行完畢 便可以執(zhí)行 trx5 trx6; trx5 執(zhí)行完畢 便可以執(zhí)行 trx7.

PS：對于是否開啟 GTID 進(jìn)行了一番測試(針對從庫設(shè)置  slave_parallel_type= LOGICAL_CLOCK 的情況)
1 5.6 — 5.6
  基于 database 的并行復(fù)制 沒有問題

2 5.7 — 5.7
     ① 開啟 GTID 的情況下，將組提交的  last_commited 和 seq num 等信息記錄到 GTID 中；
     ② 未開啟 GTID 的情況下 mysql5.7 會(huì) 在每次提交 events 之前 set gtid_next= annonymous，因此會(huì)產(chǎn)生一個(gè) annonymous_gtid , 然后將組提交的  last_commited 和 seq num 等信息記錄下來，可以實(shí)現(xiàn)并行復(fù)制。

3 5.6 — 5.7
  ① 未開啟 GTID 的情況下，mysql5.6 作為 master 并不會(huì) 進(jìn)行  set gtid_mode= annonymous 操作，故而不會(huì)有 last_commited 和 seq num，mysql5.7 slave 的并行復(fù)制設(shè)置失效 (實(shí)際單線程執(zhí)行更新語句)，不會(huì)報(bào)錯(cuò)。
     ② 開啟 GTID 的情況下，倘若 master 沒有并發(fā)事務(wù)，并行復(fù)制設(shè)置失效(實(shí)際單線程執(zhí)行更新語句)，則復(fù)制不報(bào)錯(cuò)；若有并發(fā)事務(wù)，則復(fù)制直接出錯(cuò)，內(nèi)容如下圖(意思是 5.6 的格式的 events 到了 5.7 這里在設(shè)置 logical_clock 的情況下無法識(shí)別)
 
以上 在  slave_parallel_type=DATABASE 的情況下沒有問題。
綜上，不要在 5.6— 5.7 的同步中開啟 logical_clock 模式的并行復(fù)制

看完上述內(nèi)容，你們掌握如何理解 mysql5. 中的并行復(fù)制的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道，感謝各位的閱讀！