如何理解mysql5.中的并行復制

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

專注于為中小企業(yè)提供做網(wǎng)站、網(wǎng)站制作服務,電腦端+手機端+微信端的三站合一,更高效的管理,為中小企業(yè)冷水灘免費做網(wǎng)站提供優(yōu)質的服務。我們立足成都，凝聚了一批互聯(lián)網(wǎng)行業(yè)人才，有力地推動了上千多家企業(yè)的穩(wěn)健成長，幫助中小企業(yè)通過網(wǎng)站建設實現(xiàn)規(guī)模擴充和轉變。

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

    

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

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

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

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

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

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

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

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

               slave 上執(zhí)行的順序為 

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


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

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

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

看完上述內(nèi)容，你們掌握如何理解 mysql5.中的并行復制的方法了嗎？如果還想學到更多技能或想了解更多相關內(nèi)容，歡迎關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

網(wǎng)站題目：如何理解mysql5.中的并行復制
鏈接分享：http://bm7419.com/article16/goejgg.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設、網(wǎng)站收錄、網(wǎng)站排名、響應式網(wǎng)站、全網(wǎng)營銷推廣、網(wǎng)站內(nèi)鏈

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)