2. 程式人生 > >MySQL 5.7並行複製中並行的真正含義

MySQL 5.7並行複製中並行的真正含義

阿新 • • 發佈：2018-12-30

 

MySQL 5.7並行複製中並行的真正含義

 

版權宣告：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/joy0921/article/details/80130768

MySQL 5.7並行複製初理解

我們知道MySQL 5.7並行複製引入了兩個值last_committed和sequence_number。last_committed表示事務提交的時候，上次事務提交的編號，在主庫上同時提交的事務設定成相同的last_committed。如果事務具有相同的last_committed，表示這些事務都在一組內，可以進行並行的回放。這個機制也是Commit-Parent-Based SchemeWL#6314

中的實現方式。不過之後，官方對這種模式做了改進，所以最新的並行回放機制和WL#6314有了不同，詳情見Lock-Based SchemeWL#7165。

下面介紹一下舊模式Commit-Parent-Based SchemeWL#6314和新模式Lock-Based SchemeWL#7165的不同之處，以及改進的地方。

Commit-Parent-Based Scheme WL#6314

Commit-Parent-Based Scheme簡介

  • 在master上，有一個全域性計數器（global counter）。在每一次儲存引擎提交之前，計數器值就會增加。
  • 在master上，在事務進入prepare階段之前，全域性計數器的當前值會被儲存在事務中。這個值稱為此事務的commit-parent
    。
  • 在master上，commit-parent會在事務的開頭被儲存在binlog中。
  • 在slave上，如果兩個事務有同一個commit-parent，他們就可以並行被執行。

此commit-parent就是我們在binlog中看到的last_committed。如果commit-parent相同，即last_committed相同，則被視為同一組，可以並行回放。

Commit-Parent-Based Scheme的問題

一句話：Commit-Parent-Based Scheme會降低複製的並行程度。

圖片描述

解釋一下圖：

  • 水平虛線表示事務按時間順序往後走。

  • P表示事務在進入prepare階段之前讀到的commit-parent值的那個時間點。可以簡單的視為加鎖時間點。

  • C表示事務增加了全域性計數器（global counter）的值的那個時間點。可以簡單的視為釋放鎖的時間點

  • P對應的commit-parent（last_commited）是取自所有已經執行完的事務的最大的C對應的sequence_number。舉例來說：

    • Trx4的P對應的commit-parent（last_commited）取自所有已經執行完的事務的最大的C對應的sequence_number，也就是Trx1的C對應的sequence_number。因為這個時候Trx1已經執行完，但是Trx2還未執行完。
    • Trx5的P對應的commit-parent（last_commited）取自所有已經執行完的事務的最大的C對應的sequence_number，也就是Trx2的C對應的sequence_number；Trx6的P對應的commit-parent（last_commited）取自所有已經執行完的事務的最大的C對應的sequence_number，也就是Trx2的C對應的sequence_number。所以Trx5和Trx6具有相同的commit-parent（last_commited），在進行回放的時候，Trx5和Trx6可以並行回放。

由圖可見，Trx5 和 Trx6可以併發執行，因為他們的commit-parent是相同的，都是由Trx2設定的。但是，Trx4和Trx5不能併發執行, Trx6和Trx7也不能併發執行。

我們可以注意到，在同一時段，Trx4和Trx5、Trx6和Trx7分別持有他們各自的鎖，事務互不衝突。所以，如果在slave上併發執行，也是不會有問題的。

根據以上例子，可以得知：

  • Trx4、Trx5和Trx6在同一時間持有各自的鎖，但Trx4無法併發執行。
  • Trx6和Trx7在同一時間持有各自的鎖，但Trx7無法併發執行。

但是，實際上，Trx4是可以和Trx5、Trx6並行執行，Trx6可以和Trx7並行執行。

如果能實現這個，那麼並行複製的效果會更好。所以官方對並行複製的機制做了改進，提出了一種新的並行複製的方式：Lock-Based Scheme。

Lock-Based Scheme WL#7165

實現：如果兩個事務在同一時間持有各自的鎖，就可以併發執行。

Lock-Based Scheme簡介

首先，定義了一個稱為lock interval的概念，含義：一個事務持有鎖的時間間隔。

  • 當儲存引擎提交，第一把鎖釋放，lock interval結束。
  • 當最後一把鎖獲取，lock interval開始。假定：最後一把鎖獲取是在binlog_prepare階段。

假設有兩個事務：Trx1、Trx2。Trx1先於Trx2。那麼，當且僅當Trx1、Trx2的lock interval有重疊，則可以並行執行。換言之，當且僅當Trx1結束自己的lock interval要早於Trx2開始自己的lock interval，則不能並行執行。

圖片描述

L表示lock interval的開始點 
C表示lock interval的結束

對於C（lock interval的結束點），MySQL會給每個事務分配一個邏輯時間戳（logical timestamp），命名為：transaction.sequence_number。此外，MySQL會獲取全域性變數global.max_committed_transaction，含義：所有已經結束lock interval的事務的最大的sequence_number。

對於L（lock interval的開始點），MySQL會把global.max_committed_timestamp分配給一個變數，並取名叫transaction.last_committed。

transaction.sequence_number和transaction.last_committed這兩個時間戳都會存放在binlog中。

根據以上分析，我們可以得出在slave上執行事務的條件：

如果所有正在執行的事務的最小的sequence_number大於一個事務的transaction.last_committed，那麼這個事務就可以併發執行。

換言之：slave的work執行緒不能開始執行一個事務，直到這個事務的last_committed值小於所有其他正在執行事務的sequence_number。

根據以上分析，回過頭來看前面的那幅圖：

圖片描述

可以看到Trx3、Trx4、Trx5、Trx6四個事務可以併發執行。因為Trx3的sequence_number大於Trx4、Trx5、Trx6的last_committed，所以可以併發執行。

當Trx3、Trx4、Trx5執行完成之後，Trx6和Trx7可以併發執行。因為Trx6的sequence_number大於Trx7的last_committed，即兩者的lock interval存在重疊。Trx5和Trx7不能併發執行，因為：Trx5的sequence_number小於Trx7的last_committed，即兩者的lock interval不存在重疊。

綜上所述，可以有三種方法來判斷slave上事務是否可以並行執行：

  • 假設有兩個事務：Trx1、Trx2。Trx1先於Trx2。那麼，當且僅當Trx1、Trx2的lock interval有重疊，則可以並行執行。
  • 如果所有正在執行的事務的最小的sequence_number大於一個事務的transaction.last_committed，那麼這個事務就可以併發執行。
  • slave 的work執行緒不能開始執行一個事務，直到這個事務的last_committed值小於所有其他正在執行事務的sequence_number。

由上分析，新模式Lock-Based Scheme機制的併發度比舊模式Commit-Parent-Based Scheme的併發度要好。 
下面舉一個例子，詳細描述基於Lock-Based Scheme並行複製的整個過程。

Lock-Based Scheme例子

圖片描述

對於第一個事務，last_committed=0,sequence_number=1。第一個work執行緒會接手這個事務並開始工作。

第二個事務，last_committed=1, sequence_number=2。直到第一個事務完成，這個事務才能開始。因為last_committed=1不小於正在執行執行事務的sequence_number=1。所以這兩個事務只能序列。

第三個事務，last_committed=2, sequence_number=3。和之前情況一樣，只有等到sequence_number=2的事務完成才能開始。

第四個事務，last_committed=3 sequence_number=4。同樣如此。

雖然前四個事務可能會被分配到不同的work執行緒，但實際上他們是序列的，就像單執行緒複製那樣。

當sequence_number=4的事務完成，last_committed=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

當sequence_number=7正在執行的時候，sequence_number=8和sequence_number=9這兩個也可以併發執行。

這三個事務的結束沒有前後順序的限制。因為這三個事務的lock interval有重疊，因此可以併發執行，所以事務之間並不會相互影響。

等到前面的事務均完成之後，下面這個事務才可以進行：

last_committed=9 sequence_number=10

Lock-Based Scheme往前的併發度計算

從上面的描述，可以發現，如果sequence_number - last_committed的差值越大，併發度會越高。如果差值為1，那麼這個事務必須等到前面的事務完成才能開始執行。如果差值為2，那麼這個事務可以和前面的一個事務併發執行。

和後面的事務是否能併發進行，這個當前事務是無法判斷的；當前事務只能與前面事務的sequence_number比較，得出自己是否可以併發執行。

我們可以通過以下命令粗略檢視併發度：

mysqlbinlog mysql-bin.000124 | grep -o 'last_committed.*' | sed 's/=/ /g' | awk '{print $4-$2}' | sort -g | uniq -c
854 1
1846 2
2573 3
3145 4
3628 5
4076 6
4591 7
5192 8
5741 9
6371 10
7024 11
7646 12
8299 13
8976 14
9592 15
10274 16
10871 17
11392 18
11832 19
12245 20
12316 21
12405 22
11958 23
12951 24
160 25
 1 50
 1 66
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28

差值為1的有854個，只是表示這854個事務的sequence_number - last_committed=1，必須等到所有前面的事務完成之後才能開始；但，並不表示不能和後面的事務併發執行。比如，上面的那個例子：

last_committed=4 sequence_number=5 
last_committed=4 sequence_number=6 
last_committed=4 sequence_number=7

sequence_number=5的這個事務只是表明必須等到前面事務完成，此事務才能開始執行；但它可以和後面的另兩個事務併發執行。

我們也可以通過以下的方式來優化並行複製的work數：

https://www.percona.com/blog/2016/02/10/estimating-potential-for-mysql-5-7-parallel-replication/

引申：slave_preserve_commit_order引數

這個引數設定為yes是為了確保，在slave上事務的提交順序與relay log中一致。

但是經過測試，這個引數在MySQL 5.7.18中設定之後，也無法保證slave上事務提交的順序與relay log一致。

在MySQL 5.7.19設定後，slave上事務的提交順序與relay log中一致。

For multi-threaded 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 multi-threading 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.

參考

作者：韓傑 
來源：沃趣科技（woqutech）

 

相關推薦

MySQL 5.7並行複製中並行的真正含義

  MySQL 5.7並行複製中並行的真正含義   版權宣告：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/joy0921/article/details/80130768 MySQL 5.7並行複製初理解 我們知道M

MySQL5.7並行複製中並行的真正含義

MySQL5.7並行複製中並行的真正含義 MySQL5.7並行複製初理解 Commit-Parent-Based Scheme WL#6314 Commit-Parent-Based Scheme簡介 Commit-Parent-Based Sche

MySQL 5.7 源碼中的目錄結構

ibm conf cmake scrip tree 配置 main.c ext client MySQl Server的源碼可以直接去Github瀏覽。 這裏我們選擇5.7版本的：https://github.com/mysql/mysql-server/tree/5.7

mysql 5.7高版本中group by問題解決辦法

select max(user_id) as user_id,`create_time` from silence where user_id in (1, 2, 3, 4) group by user_id desc; 我使用如上語句進行查詢的時候，竟然報錯了。 Expressi

mysql 5.7 主從複製

mysql主從複製  首先這個密碼就搞得我很頭大  yum安裝的rpm包 系統自動完成初始化 預設密碼強度是strong 這個設定是真的坑 規則很嚴格 反正我試了各種辦法都不能滿足密碼要求  只能先用服務啟動時日誌裡給的初始密碼先登進去 然後修改規則 再執行mysql_s

MySQL 5.7並行複製實踐

MySQL 5.7並行複製原理 MySQL 從 5.6 開始引入了多庫並行主從複製，但是其並行只是基於 Schema 的，也就是基於庫的。如果使用者的 MySQL 資料庫例項中存在多個 Schema，對於從機複製的速度的確可以有比較大的幫助。MySQL 5.6 並行複製的架構如下所示： 在上圖的紅

MYSQL 5.7 並行複製實現原理與調優

MySQL 5.7並行複製時代 眾所周知，MySQL的複製延遲是一直被詬病的問題之一，然而在Inside君之前的兩篇部落格中（1，2）中都已經提到了MySQL 5.7版本已經支援“真正”的並行複製功能，官方稱為為enhanced multi-thread

MySQL 5.7 並行復制

參與 clas 沖突 地方 recover 下單 rec PE ade 一、緣由： 　　某天看到主從復制延時的告警有點頻繁，就想著是不是徹底可以解決一下。 　　一般主從復制，有三個線程參與，都是單線程：Binlog Dump（主） ----->IO Thread

MySQL的show profile簡介以及該功能在MySQL 5.7中performance_schema中的替代

資源 指標 context 繼續 過程 tar view update 語句 本文出處：http://www.cnblogs.com/wy123/p/6979499.html 　　show profile 命令用於跟蹤執行過的sql語句的資源消耗信息，可以幫

mysql-5.7中innodb_buffer_pool頁面淘汰算法

什麽 如果 數據結構 time 內存區域 標記 blocks 從數據 語句 一、 什麽是innodb_buffer_pool： 　　innodb_buffer_pool是一塊內存區域，innodb用它來緩存數據，索引，undo，change buffer ... ； 　　這

RedHat6.9中編制安裝zabbix-3.4.7，DB用percona mysql 5.7.20

zabbix percona mysql linux 監控 zabbix配置 軟件版本：Redhat6.9zabbix-3.4.7percona mysql-5.7.20 準備工作：關閉防火墻，或者添加相應端口。關閉selinux ———— （安裝如下zabbix依賴包）————####這

Centos7中編譯安裝MySQL(mysql-5.7)

bst create 實驗環境 ip地址 port daemon 虛擬機 處理器數量 ice MySQL 是一個真正的多線程、多用戶的SQL數據庫服務，憑借其高性能、高可靠和易於使用的性能，成為服務器領域中最受歡迎的開源數據庫系統。為了確保數據庫的功能的完性、可定制性，本篇

如何在RedHat 7.0系統中安裝mysql 5.7.22

分享圖片 comm libs ant 進不去 cal 之前 str 一行 如何在RedHat 7.0系統中安裝mysql 5.7.22 今天給大家介紹一下如何安裝mysql5.7，在安裝之前，首先要查看的是，你的系統中有沒有已經安裝過的情況。鍵入rpm -qa|grep

Linux中安裝MySql 5.7.21的詳細操作步驟

一：到mysql官網下載最新的mysql包 mysql-5.7.21-linux-glibc2.12-x86_64 官方下載地址：https://dev.mysql.com/downloads/mysql/ 下載地址：//www.jb51.net/softs/38849.html 二：在linux /u

從MySQL 5.5到5.7看複製的演進

概要：MySQL 5.5 支援單執行緒模式複製，MySQL 5.6 支援庫級別的並行複製，MySQL 5.7 支援事務級別並行複製。結合這個主線我們可以來分析一下MySQL以及社群發展的一個前因後果。 MySQL5.5，對於複製我們可以這樣理解：主庫有個 dump binlog thread 不

在 CentOS 1804 中 安裝 MySQL 5.7.20 （或任意MySQL版本）

相關連結： 在 CentOS 1804 中 使用 yum 安裝 MySQL 5.7 最新版 在 CentOS 1804 中 安裝 MySQL 5.7.20 （或任意MySQL版本） 在 CentOS 1804 中 修改 MySQL 密碼策略 在 CentOS 中 開啟 MySQL 的

在 CentOS 1804 中 使用 yum 安裝 MySQL 5.7 最新版

相關連結： 在 CentOS 1804 中 使用 yum 安裝 MySQL 5.7 最新版 在 CentOS 1804 中 安裝 MySQL 5.7.20 （或任意MySQL版本） 在 CentOS 1804 中 修改 MySQL 密碼策略 在 CentOS 中 開啟 MySQL 的

MySQL 5.7基於GTID複製的常見問題和修復步驟(一)

【問題一】 複製slave報錯1236，是較為常見的一種報錯 Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting using CHANGE MASTER TO

MySQL 5.7基於GTID複製的常見問題和修復步驟(二)

  【問題二】 有一個叢集（MySQL5.7.23）切換後複製slave報1236，其實是不小心在slave上執行了事務導致 Got fatal error 1236 from master when reading data from binary log: 'The slave is co

MySQL 5.7多源複製配置詳解

MySQL 5.7釋出後，在複製方面有了很大的改進和提升。比如開始支援多源複製(multi-source)以及真正的支援多執行緒複製了。多源複製可以使用基於二進位制日子的複製或者基於事務的複製。下面我們說一說如何配置基於二進位制日誌的多源複製。 什麼是多源複製？？？ 首先，我們要清楚幾種常見的複製模式：