深入淺出講解MySQL的并行復制

一、并行復制的背景

創(chuàng)新互聯(lián)一直秉承“誠信做人，踏實做事”的原則，不欺瞞客戶，是我們最起碼的底線！ 以服務為基礎，以質(zhì)量求生存，以技術(shù)求發(fā)展，成交一個客戶多一個朋友！為您提供網(wǎng)站制作、做網(wǎng)站、成都網(wǎng)頁設計、小程序設計、成都網(wǎng)站開發(fā)、成都網(wǎng)站制作、成都軟件開發(fā)、app軟件開發(fā)是成都本地專業(yè)的網(wǎng)站建設和網(wǎng)站設計公司，等你一起來見證！

首先，為什么會有并行復制這個概念呢？

1. DBA都應該知道，MySQL的復制是基于binlog的。 

2. MySQL復制包括兩部分，IO線程 和 SQL線程。 

3. IO線程主要是用于拉取接收Master傳遞過來的binlog，并將其寫入到relay log 

4. SQL線程主要負責解析relay log，并應用到slave中 

5. 不管怎么說，IO和SQL線程都是單線程的，然后master卻是多線程的，所以難免會有延遲，為了解決這個問題，多線程應運而生了。 

6. IO多線程？  

 6.1 IO沒必要多線程，因為IO線程并不是瓶頸啊 

7. SQL多線程？

 7.1 沒錯，目前最新的5.6，5.7，8.0 都是在SQL線程上實現(xiàn)了多線程，來提升slave的并發(fā)度  

接下來，我們就來一窺MySQL在并行復制上的努力和成果吧

二、重點

是否能夠并行，關(guān)鍵在于多事務之間是否有鎖沖突，這是關(guān)鍵。 下面的并行復制原理就是在看如何讓避免鎖沖突

三、MySQL5.6 基于schema的并行復制

slave-parallel-type=DATABASE(不同庫的事務，沒有鎖沖突)

之前說過，并行復制的目的就是要讓slave盡可能的多線程跑起來，當然基于庫級別的多線程也是一種方式(不同庫的事務，沒有鎖沖突)

先說說優(yōu)點： 實現(xiàn)相對來說簡單，對用戶來說使用起來也簡單
再說說缺點： 由于是基于庫的，那么并行的粒度非常粗，現(xiàn)在很多公司的架構(gòu)是一庫一實例，針對這樣的架構(gòu)，5.6的并行復制無能為力。當然還有就是主從事務的先后順序，對于5.6也是個大問題

話不多說，來張圖好了

四、MySQL5.7 基于group commit的并行復制

slave-parallel-type=LOGICAL_CLOCK : Commit-Parent-Based模式(同一組的事務[last-commit相同]，沒有鎖沖突. 同一組，肯定沒有沖突，否則沒辦法成為同一組)
slave-parallel-type=LOGICAL_CLOCK : Lock-Based模式(即便不是同一組的事務，只要事務之間沒有鎖沖突[prepare階段]，就可以并發(fā)。 不在同一組，只要N個事務prepare階段可以重疊，說明沒有鎖沖突)

group commit，之前的文章有詳細描述，這里不多解釋。MySQL5.7在組提交的時候，還為每一組的事務打上了標記，現(xiàn)在想想就是為了方便進行MTS吧。

我們先看一組binlog

last_committed=0 sequence_number=1
last_committed=1 sequence_number=2
last_committed=2 sequence_number=3
last_committed=3 sequence_number=4
last_committed=4 sequence_number=5
last_committed=4 sequence_number=6
last_committed=4 sequence_number=7
last_committed=6 sequence_number=8
last_committed=6 sequence_number=9
last_committed=9 sequence_number=10

4.1 Commit-Parent-Based模式

4.2 Lock-Based模式

五、MySQL8.0 基于write-set的并行復制

基于主鍵的沖突檢測(binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION, 修改的row的主鍵或非空唯一鍵沒有沖突，即可并行)
5.7.22 也支持了 write-set 機制

事務依賴關(guān)系：binlog_transaction_depandency_tracking = COMMIT_ORDERE|WRITESET|WRITESET_SESSION

COMMIT_ORDERE: 繼續(xù)基于組提交方式
WRITESET: 基于寫集合決定事務依賴
WRITESET_SESSION: 基于寫集合，但是同一個session中的事務不會有相同的last_committed

事務檢測算法：transaction_write_set_extraction = OFF| XXHASH64 | MURMUR32

MySQL會有一個變量來存儲已經(jīng)提交的事務HASH值，所有已經(jīng)提交的事務所修改的主鍵（或唯一鍵）的值經(jīng)過hash后都會與那個變量的集合進行對比，來判斷改行是否與其沖突，并以此來確定依賴關(guān)系

這里說的變量，可以通過這個設置大?。?binlog_transaction_dependency_history_size

這樣的粒度，就到了 row級別了，此時并行的粒度更加精細，并行的速度會更快，某些情況下，說slave的并行度超越master也不為過(master是單線程的寫，slave也可以并行回放)

六、如何讓slave的并行復制和master的事務執(zhí)行的順序一致呢

5.7.19 之后，可以通過設置 slave_preserve_commit_order = 1

官方解釋： 

For multithreaded slaves, enabling this variable ensures that transactions are externalized on the slave in the same order as they appear in the slave's relay log.  
Setting this variable has no effect on slaves for which multithreading is not enabled.  
All replication threads (for all replication channels if you are using multiple replication channels) must be stopped before changing this variable.  
--log-bin and --log-slave-updates must be enabled on the slave.  
In addition --slave-parallel-type must be set to LOGICAL_CLOCK. 
Once a multithreaded slave has been started, transactions can begin to execute in parallel.  
With slave_preserve_commit_order enabled, the executing thread waits until all previous transactions are committed before committing.  
While the slave thread is waiting for other workers to commit their transactions it reports its status as Waiting for preceding transaction to commit.

大致實現(xiàn)原理就是：excecution階段可以并行執(zhí)行，binlog flush的時候，按順序進行。 引擎層提交的時候，根據(jù)binlog_order_commit也是排隊順序完成 

換句話說，如果設置了這個參數(shù)，master是怎么并行的，slave就怎么辦并行

總結(jié)

以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對創(chuàng)新互聯(lián)的支持。

網(wǎng)站欄目：深入淺出講解MySQL的并行復制
當前鏈接：http://bm7419.com/article48/jjehhp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、小程序開發(fā)、響應式網(wǎng)站、標簽優(yōu)化、網(wǎng)站收錄、品牌網(wǎng)站制作

廣告

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