如何理解 mysql5.中的并行復(fù)制

如何理解 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)?nbsp;

                ① 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ì)有l(wèi)ast_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的情況下無法識別)
        
以上 在 slave_parallel_type=DATABASE的情況下沒有問題。
綜上，不要在 5.6--->5.7的同步中開啟 logical_clock 模式的并行復(fù)制

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