共计 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 如何并行复制”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
