MySQL Replication中的并行复制示例详解
传统单线程复制说明
众所周知，MySQL在5.6版本之前，主从复制的从节点上有两个线程，分别是I/O线程和SQL线程。
I/O线程负责接收二进制日志的Event写入Relay Log。
SQL线程读取Relay Log并在数据库中进行回放。
以上方式偶尔会造成延迟，那么可能造成主从节点延迟的情况有哪些?
1.主库执行大事务（如：大表结构变更操作）。
2.主库大批量变更（如：大量插入、更新、删除操作）。
3.ROW同步模式下，主库大表无主键频繁更新。
4.数据库参数配置不合理，从节点性能存在瓶颈（如：从节点事务日志设置过小，导致频繁刷盘）。
5.网络环境不稳定，从节点IO线程读取binlog存在延迟、重连情况。
6.主从硬件配置差异，从节点的硬件资源使用达到上限。(比如：主节点SSD盘，从节点SAS盘)
可以对以上延迟原因做个大致分类。
1.硬件方面问题（包括磁盘IO、网络IO等）
2.配置方面问题。
3.数据库设计问题。
4.主库大批量变更，从节点SQL单线程处理不够及时。
总结
分析以上原因可以看出要想降低主从延迟，除了改善硬件方面条件之外，另外就是需要DBA关注数据库设计和配置问题，最后就是需要提高从节点的并发处理能力，由单线程回放改为多线程并行回放是一个比较好的方法，关键点在于如何在多线程恢复的前提下解决数据冲突和故障恢复位置点的确认问题。
MySQL5.6基于库级别的并行复制
在实例中有多个数据库的情况下，可以开启多个线程，每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类
Coordinator和WorkThread。
线程分工执行逻辑
Coordinator线程负责判断事务是否可以并行执行，如果可以并行就把事务分发给WorkThread线程执行，如果判断不能执行，如DDL，跨库操作等，就等待所有的worker线程执行完成之后，再由Coordinator执行。
关键配置信息
slave-parallel-type=DATABASE
方案不足点
这种并行复制的模式,只有在实例中有多个DB且DB的事务都相对繁忙的情况下才会有较高的并行度，但是日常维护中其实单个实例的的事务处理相对集中在一个DB上。通过观察延迟可以发现基本上都是基于热点表出现延迟的情况占大多数。如果能够提供基于表的并行度是一个很好方法。
MySQL5.7基于组提交的并行复制
组提交说明
简单来说就是在双1的设置下，事务提交后即刷盘的操作改为多个事务合并成一组事务再进行统一刷盘，这样处理就降低了磁盘IO的压力。详细资料参考关于组提交的说明推文 https://www.jb51.net/article/253739.htm
一组事务同时提交也就意味着组内事务不存在冲突，故组内的事务在从节点上就可以并发执行，问题在于如何区分事务是否在同一组中的，于是在binlog中出现了两个新的参数信息last_committed 和 sequence_number
如何判断事务在一个组内呢?
解析binlog可以发现里面多了
last_committed和sequence_number两个参数信息，其中last_committed存在重复的情况。
sequence_number# 这个值指的是事务提交的序号，单调递增。last_committed# 这个值有两层含义，1.相同值代表这些事务是在同一个组内，2.该值同时又是代表上一组事务的最大编号。
[root@mgr2 GreatSQL]# mysqlbinlog mysql-bin.0000002 | grep last_committed GTID last_committed=0 sequence_number=1 GTID last_committed=0 sequence_number=2 GTID last_committed=2 sequence_number=3 GTID last_committed=2 sequence_number=4 GTID last_committed=2 sequence_number=5 GTID last_committed=2 sequence_number=6 GTID last_committed=6 sequence_number=7 GTID last_committed=6 sequence_number=8
数据库配置
slave-parallel-type=LOGICAL_CLOCK
方案不足点
基于组提交的同步有个不足点，就是当主节点的事务繁忙度较低的时候，导致时间段内组提交fsync刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组里面只有一个事务，这样从节点的多线程就基本用不到，可以通过设置下面两个参数，让主节点延迟提交。
binlog_group_commit_sync_delay # 等待延迟提交的时间，binlog提交后等待一段时间再 fsync。让每个 group 的事务更多，人为提高并行度。
binlog_group_commit_sync_no_delay_count # 待提交的最大事务数，如果等待时间没到，而事务数达到了，就立即 fsync。达到期望的并行度后立即提交，尽量缩小等待延迟。
MySQL8.0基于writeset的并行复制
writeset 基于事务结果冲突进行判断事务是否可以进行并行回放的方法，他由
binlog-transaction-dependency-tracking参数进行控制，默认采用WRITESET方法。
关键参数查看
| Command-Line Format | --binlog-transaction-dependency-tracking=value |
|---|---|
| System Variable | binlog_transaction_dependency_tracking |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | COMMIT_ORDER |
| Valid Values | COMMIT_ORDER WRITESET WRITESET_SESSION |
参数配置项说明
COMMIT_ORDER# 使用 5.7 Group commit 的方式决定事务依赖。WRITESET# 使用写集合的方式决定事务依赖。WRITESET_SESSION# 使用写集合，但是同一个session中的事务不会有相同的last_committed。
writeset 是一个HASH类型的数组，里面记录着事务的更新信息，通过
transaction_write_set_extraction判断当前事务更新的记录与历史事务更新的记录是否存在冲突，判断过后再采取对应处理方法。writeset储存的最大存储值由binlog-transaction-dependency-history-size控制。
需要注意的是，当设置成
WRITESET或WRITESET_SESSION的时候，事务提交是无序状态的，可以通过设置slave_preserve_commit_order=1强制按顺序提交。
binlog_transaction_dependency_history_size
设置保存在内存中的行哈希数的上限，用于缓存之前事务修改的行信息。一旦达到这个哈希数，就会清除历史记录。
| Command-Line Format | --binlog-transaction-dependency-history-size=# |
|---|---|
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Integer |
| Default Value | 25000 |
| Minimum Value | 1 |
| Minimum Value | 1000000 |
transaction_write_set_extraction
该模式支持三种算法，默认采用XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。该参数已经在MySQL 8.0.26中被弃用，后续将会进行删除。
| Command-Line Format | --transaction-write-set-extraction[=value] |
|---|---|
| Deprecated | 8.0.26 |
| System Variable | binlog_transaction_dependency_history_size |
| Scope | Global, Session |
| Dynamic | Yes |
| SET_VAR Hint Applies | No |
| Type | Enumeration |
| Default Value | XXHASH64 |
| Valid Values | OFF MURMUR32 XXHASH64 |
数据库配置
slave_parallel_type = LOGICAL_CLOCK slave_parallel_workers = 8 binlog_transaction_dependency_tracking = WRITESET slave_preserve_commit_order = 1
引用资料：
到此这篇关于MySQL Replication之并行复制的文章就介绍到这了,更多相关MySQL 并行复制内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
这篇文章主要介绍了关于msyql事务隔离的相关资料，文中讲解非常细致，帮助大家更好的理解和学习mysql，感兴趣的朋友可以了解下2020-07-07
这篇文章主要介绍了MySQL数据库之数据表操作DDL数据定义语言，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下2022-08-08
这篇文章主要为大家详细介绍了Windows上mysql5.7.10安装配置方法图文教程，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2018-04-04
mysql数据库中limit子句可以被用于强制select语句返回指定的记录数,本文主要介绍了mysql数据库limit的四种用法小结,感兴趣的可以了解一下2023-10-10
本文主要给大家介绍Mysql数据库分库和分表方式(常用)，涉及到mysql数据库相关知识，对mysql数据库分库分表相关知识感兴趣的朋友一起学习吧2016-03-03
这篇文章主要介绍了MySQL如何删除表中的数据问题，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2022-11-11
慢查询日志用来记录在 MySQL 中执行时间超过指定时间的查询语句,本文就来介绍一下MySQL慢查询日志 的使用,感兴趣的可以了解一下2024-08-08
所谓多行子查询，是指执行查询语句获得的结果集中返回了多行数据的子查询，今天通过本文给大家分享Mysql多行子查询的使用及空值问题，感兴趣的朋友一起看看吧2022-01-01
这篇文章主要为大家分享了几个MySQL基础中的多表查询案例，文中的示例代码简洁易懂，对我们学习MySQL有一定的帮助，需要的小伙伴可以了解一下2022-10-10
有些新手朋友对MySQL定时器开启、调用不是很熟悉，本人整理测试一些，拿出来和大家分享一下，希望可以帮助你们2012-12-12
最新评论