共計 3693 個字符，預計需要花費 10 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關 Mysql5.7 如何并行復制，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
啟用 MySQL 并行復制
MySQL 5.7 的并行復制建立在組提交的基礎上，所有在主庫上能夠完成 Prepared 的語句表示沒有數據沖突，就可以在 Slave 節點并行復制。
關于 MySQL 5.7 的組提交，我們要看下以下的參數：
(test) show global variables like %group_commit%
- ;
+-----------------------------------------+-------+
| Variable_name | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay | 0 |
| binlog_group_commit_sync_no_delay_count | 0 |
+-----------------------------------------+-------+要開啟 MySQL 5.7 并行復制需要以下二步，首先在主庫設置 binlog_group_commit_sync_delay 的值大于 0。
set global binlog_group_commit_sync_no_delay_count=20;
set global binlog_group_commit_sync_delay =10;這里簡要說明下 binlog_group_commit_sync_delay 和 binlog_group_commit_sync_no_delay_count 參數的作用。
binlog_group_commit_sync_delay
全局動態變量，單位微妙，默認 0，范圍：0～1000000（1 秒）。
表示 binlog 提交后等待延遲多少時間再同步到磁盤，默認 0，不延遲。當設置為 0 以上的時候，就允許多個事務的日志同時一起提交，也就是我們說的組提交。組提交是并行復制的基礎，我們設置這個值的大于 0 就代表打開了組提交的功能。
binlog_group_commit_sync_no_delay_count
全局動態變量，單位個數，默認 0，范圍：0～1000000。
表示等待延遲提交的最大事務數，如果上面參數的時間沒到，但事務數到了，則直接同步到磁盤。若 binlog_group_commit_sync_delay 沒有開啟，則該參數也不會開啟。
其次要在 Slave 主機上設置如下幾個參數：
# 過多的線程會增加線程間同步的開銷，建議 4 - 8 個 Slave 線程。slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=4或者直接在線啟用也是可以的：
mysql stop slave;
Query OK, 0 rows affected (0.07 sec)
mysql set global slave_parallel_type= LOGICAL_CLOCK
Query OK, 0 rows affected (0.00 sec)
mysql set global slave_parallel_workers=4;
Query OK, 0 rows affected (0.00 sec)
mysql start slave;
Query OK, 0 rows affected (0.06 sec)
mysql show variables like slave_parallel_%
+------------------------+---------------+
| Variable_name | Value |
+------------------------+---------------+
| slave_parallel_type | LOGICAL_CLOCK |
| slave_parallel_workers | 4 |
+------------------------+---------------+
2 rows in set (0.00 sec)檢查 Worker 線程的狀態
當前的 Slave 的 SQL 線程為 Coordinator（協調器），執行 Relay log 日志的線程為 Worker(當前的 SQL 線程不僅起到協調器的作用，同時也可以重放 Relay log 中主庫提交的事務)。
我們上面設置的線程數是 4，從庫就能看到 4 個 Coordinator（協調器）進程。
并行復制配置與調優
開啟 MTS 功能后，務必將參數 master-info-repository 設置為 TABLE，這樣性能可以有 50%~80% 的提升。這是因為并行復制開啟后對于 master.info 這個文件的更新將會大幅提升，資源的競爭也會變大。
在 MySQL 5.7 中，推薦將 master-info-repository 和 relay-log-info-repository 設置為 TABLE，來減小這部分的開銷。
master-info-repository = table
relay-log-info-repository = table
relay-log-recovery = ON并行復制監控
復制的監控依舊可以通過 SHOW SLAVE STATUS\G，但是 MySQL 5.7 在 performance_schema 架構下多了以下這些元數據表，用戶可以更細力度的進行監控：
mysql use performance_schema;
mysql show tables like replication%
+---------------------------------------------+
| Tables_in_performance_schema (replication%) |
+---------------------------------------------+
| replication_applier_configuration |
| replication_applier_status |
| replication_applier_status_by_coordinator |
| replication_applier_status_by_worker |
| replication_connection_configuration |
| replication_connection_status |
| replication_group_member_stats |
| replication_group_members |
+---------------------------------------------+
8 rows in set (0.00 sec)
想辦法統計出來每個同步線程使用的比率。統計方法如下:
1、將線上從機相關統計打開（出于性能考慮默認是關閉的），打開方法可以如下如下 SQL：UPDATE performance_schema.setup_consumers SET ENABLED = YES WHERE NAME LIKE events_transactions%
UPDATE performance_schema.setup_instruments SET ENABLED = YES , TIMED = YES WHERE NAME = transaction
2、創建一個查看各個同步線程使用量的視圖，代碼如下：USE test;
CREATE VIEW rep_thread_count AS SELECT a.THREAD_ID AS THREAD_ID,a.COUNT_STAR AS COUNT_STAR FROM performance_schema.events_transactions_summary_by_thread_by_event_name a WHERE a.THREAD_ID in (SELECT b.THREAD_ID FROM performance_schema.replication_applier_status_by_worker b);
3、一段時間后，統計各個同步線程的使用比率，SQL 如下:
SELECT SUM(COUNT_STAR) FROM rep_thread_count INTO @total;
SELECT 100*(COUNT_STAR/@total) AS thread_usage FROM rep_thread_count;關于“Mysql5.7 如何并行復制”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
