MySQL 5.7并行复制实践(2)

我们可以看到最后两个事务的 last_committed 是相同的,这意味着这两个事务是作为一个组提交的,两个事务在 Perpare 阶段获取相同的 last_committed 而且相互不影响,最终是会作为一个组进行提交.这就是所谓的组提交.组提交的事务是可以在从机进行并行回放的.

上述的 last_committed 和 sequence_number 代表的就是所谓的 LOGICAL_CLOCK.

配置MySQL并行复制

环境准备

这里一共使用了二台机器,MySQL 版本都为 5.7.18.

安装MySQL

MySQL 安装比较简单,在 「MySQL 5.7多源复制实践」一文中我们也讲了,这里就不在重复讲了.如果你还不会安装,可以先参考此文安装好 MySQL .

启用MySQL并行复制

MySQL 5.7的并行复制建立在组提交的基础上,所有在主库上能够完成 Prepared 的语句表示没有数据冲突,就可以在 Slave 节点并行复制.

关于 MySQL 5.7 的组提交,我们要看下以下的参数：

mysql> show global variables like '%group_commit%';
+-----------------------------------------+-------+
| Variable_name ? ? ? ? ? ? ? ? ? ? ? ? ? | Value |
+-----------------------------------------+-------+
| binlog_group_commit_sync_delay ? ? ? ? ?| 0 ? ? |
| binlog_group_commit_sync_no_delay_count | 0 ? ? |
+-----------------------------------------+-------+
2 rows in set (0.00 sec)

要开启 MySQL 5.7 并行复制需要以下二步,首先在主库设置 binlog_group_commit_sync_delay 的值大于0 .

mysql> 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 就代表打开了组提交的功能.

binlog_group_commit_sync_no_delay_count

全局动态变量,单位个数,范围：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)

文章来自微信公众号：运维之美

（编辑：ASP站长网）