MySQL并行復制配置與調優的操作

本篇文章給大家主要講的是關于MySQL并行復制配置與調優的操作的內容，感興趣的話就一起來看看這篇文章吧，相信看完MySQL并行復制配置與調優的操作對大家多少有點參考價值吧。

并行復制產生的背景：
因為I/O thread和SQL thread是單線程工作的，而Master是可以多線程寫入的，所以主從難免造成延遲
基于此，在5.6，5.7，8.0版本都在SQL線程上實現了多線程，來提升slave的并發度

為什么不是I/O多線程？
I/O沒必要多線程，因為I/O線程并不是瓶頸啊 （沒怎么理解）

并行復制的目的：
讓Slave SQL線程盡可能以多線程工作，解決復制延遲的問題

并行復制實現的前提：
能夠進行并行復制，關鍵在于多事務之間是否有鎖沖突

MySQL5.6基于schema的并行復制：
應用場景：
比較適用于一個庫中有多個schema的場景

并行復制的原理：
MySQL5.6開啟并行復制功能后，SQL線程變成coordinator線程，由其判斷是否可以并發執行，這意味著一個worker線程可以處理一個數據庫的連續事務，而不用等待其它數據庫完成
如果可以并行執行，選擇worker線程執行二進制日志
如果不可以并行執行，如：DDL或者跨schema操作，則等待所有的worker線程執行完成之后再執行當前日志

摘自網上的一張圖片，供參考理解：

基于schema的并行復制帶來的問題：
因為MySQL5.6并行復制只是基于schema，但對于單庫多表的復制場景是無法實現的，甚至性能可能還達不到原來的單線程復制，而在實際工作中單庫多表比多庫多表的場景更為常見。
MySQL5.6基于schema級別的并發復制可以解決業務表放在不同的DATABASE下同步延遲的問題，但是在實際生產中大部分表還是放在同一個庫中的，這種情況即使設置slave_parallel_workers大于0，也無法進行并發。在高并發的情況下，依然會造成主從復制延遲

MySQL5.6并行復制開啟：（前提是配置好主從復制環境）

mysql> stop slave;

Query OK, 0 rows affected (0.03 sec)

mysql> set global slave_parallel_workers=8;

Query OK, 0 rows affected (0.05 sec)

mysql> start slave;

Query OK, 0 rows affected, 1 warning (0.07 sec)

MySQL5.6并行復制原理圖：

并行復制參數說明：

slave_parallel_workers:
Number of applier threads for executing replication transactions in parallel. A value of 0 disables slave multithreading. Not supported by MySQL Cluster

MySQL5.7并行復制原理：
基于組復制（group commit）實現

如何知道事務是否在同一組中？
在MySQL 5.7版本中，其設計方式是將組提交的信息存放在GTID中。那么如果用戶沒有開啟GTID功能，即：將參數gtid_mode設置為OFF呢？
MySQL 5.7引入了稱之為Anonymous_Gtid（ANONYMOUS_GTID_LOG_EVENT）的二進制日志event類型，組提交信息存放在 Anonymous_Gtid 中。

當開啟GTID時，每一個操作語句（DML/DDL）執行前就會添加一個GTID事件，記錄當前全局事務ID；同時在MySQL 5.7版本中，組提交信息也存放在GTID事件中，有兩個關鍵字段last_committed，sequence_number就是用來標識組提交信息的。在InnoDB中有一個全局計數器（global counter），在每一次存儲引擎提交之前，計數器值就會增加。在事務進入prepare階段之前，全局計數器的當前值會被儲存在事務中，這個值稱為此事務的commit-parent（也就是last_committed）。last_committed表示事務提交的時候，上次事務提交的編號，如果事務具有相同的last_committed，表示這些事務都在一組內，可以進行并行的回放。而sequence_number是順序增長的，每個事務對應一個序列號。

這意味著在MySQL 5.7版本中即使不開啟GTID，每個事務開始前也是會存在一個Anonymous_Gtid，而這個Anonymous_Gtid事件中就存在著組提交的信息。反之，如果開啟了GTID后，就不會存在這個Anonymous_Gtid了，從而組提交信息就記錄在非匿名GTID事件中。

MySQL如何將這些事務進行分組的？
一個組提交的事務都是可以并行回放，因為這些事務都已進入到事務的prepare階段，則說明事務之間沒有任何沖突（否則就不可能提交）

MySQL5.7并行復制簡介：
1）MySQL 5.7才可稱為真正的并行復制，這其中最為主要的原因就是slave云服務器的回放與master是一致的，即master云服務器上是怎么并行執行的，那么slave上就怎樣進行并行回放。不再有庫的并行復制限制，對于二進制日志格式也無特殊的要求（基于庫的并行復制也沒有要求）
2）MySQL5.7并行復制支持表級
3）Enhanced Multi-threaded Slaves（MTS）

MySQL5.7并行復制參數：
SHOW VARIABLES LIKE 'slave_parallel_%'
Variable_name       Value
slave_parallel_type DATABASE （變量slave-parallel-type可以有兩個值：DATABASE 默認值，基于庫的并行復制方式；LOGICAL_CLOCK：基于組提交的并行復制方式（基于表））
slave_parallel_workers      0

MySQL 5.7并行復制配置與調優：
# slave
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
slave_preserve_commit_order=1
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON

MySQL5.7在線開啟并行復制（多線程復制）：
參考視頻：https://www.imooc.com/video/10921

在Slave云服務器上停止所有鏈路的復制

stop slave
set global slave-parallel-type=LOGICAL_CLOCK
set global slave-parallel-workers=16
start slave
show processlist（看到16個SQL線程）

MySQL5.7應用事務順序和realy log記錄事務順序不一樣的問題：
MySQL 5.7后的MTS可以實現更小粒度的并行復制，但需要將slave_parallel_type設置為LOGICAL_CLOCK，但僅僅設置為LOGICAL_CLOCK也會存在問題，因為此時在slave上應用事務的順序是無序的，和relay log中記錄的事務順序不一樣，這樣數據一致性是無法保證的，為了保證事務是按照relay log中記錄的順序來回放，就需要開啟參數slave_preserve_commit_order

以上關于MySQL并行復制配置與調優的操作詳細內容，對大家有幫助嗎？如果想要了解更多相關，可以繼續關注我們的行業資訊板塊。