作者：手机用户2502900175 | 来源：互联网 | 2024-10-25 11:28
本文深入探讨了MySQL5.6版本后引入的并行复制机制，详细解析了其工作原理及优化效果。通过具体实例，展示了如何在实际环境中配置和使用并行复制，以提高数据同步效率和系统性能。
目录
- 传统单线程复制说明
- 总结
- MySQL5.6基于库级别的并行复制
- MySQL8.0基于writeset的并行复制
- 引用资料：
传统单线程复制说明
众所周知，MySQL在5.6版本之前，主从复制的从节点上有两个线程，分别是I/O线程和SQL线程。
以上方式偶尔会造成延迟，那么可能造成主从节点延迟的情况有哪些?
1.主库执行大事务（如：大表结构变更操作）。
2.主库大批量变更（如：大量插入、更新、删除操作）。
3.ROW同步模式下，主库大表无主键频繁更新。
4.数据库参数配置不合理，从节点性能存在瓶颈（如：从节点事务日志设置过小，导致频繁刷盘）。
5.网络环境不稳定，从节点IO线程读取binlog存在延迟、重连情况。
6.主从硬件配置差异，从节点的硬件资源使用达到上限。(比如：主节点SSD盘，从节点SAS盘)
可以对以上延迟原因做个大致分类。
总结
分析以上原因可以看出要想降低主从延迟，除了改善硬件方面条件之外，另外就是需要DBA关注数据库设计和配置问题，最后就是需要提高从节点的并发处理能力，由单线程回放改为多线程并行回放是一个比较好的方法，关键点在于如何在多线程恢复的前提下解决数据冲突和故障恢复位置点的确认问题。
MySQL5.6基于库级别的并行复制
在实例中有多个数据库的情况下，可以开启多个线程，每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类 Coordinator 和 WorkThread。
Coordinator线程负责判断事务是否可以并行执行，如果可以并行就把事务分发给WorkThread线程执行，如果判断不能执行，如DDL，跨库操作等，就等待所有的worker线程执行完成之后，再由Coordinator执行。
slave-parallel-type=DATABASE
这种并行复制的模式,只有在实例中有多个DB且DB的事务都相对繁忙的情况下才会有较高的并行度，但是日常维护中其实单个实例的的事务处理相对集中在一个DB上。通过观察延迟可以发现基本上都是基于热点表出现延迟的情况占大多数。如果能够提供基于表的并行度是一个很好方法。
MySQL5.7基于组提交的并行复制
组提交说明
简单来说就是在双1的设置下，事务提交后即刷盘的操作改为多个事务合并成一组事务再进行统一刷盘，这样处理就降低了磁盘IO的压力。详细资料参考老叶茶馆关于组提交的说明推文https://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg
一组事务同时提交也就意味着组内事务不存在冲突，故组内的事务在从节点上就可以并发执行，问题在于如何区分事务是否在同一组中的，于是在binlog中出现了两个新的参数信息last_committed 和 sequence_number
解析binlog可以发现里面多了last_committed和sequence_number两个参数信息，其中last_committed存在重复的情况。
[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刷盘的事务量较少，于是导致从库回放的并行度并不高，甚至可能一组里面只有一个事务，这样从节点的多线程就基本用不到，可以通过设置下面两个参数，让主节点延迟提交。
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 强制按顺序提交。
设置保存在内存中的行哈希数的上限，用于缓存之前事务修改的行信息。一旦达到这个哈希数，就会清除历史记录。
| 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 |
该模式支持三种算法，默认采用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 并行复制内容请搜索编程笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程笔记！
京公网安备 11010802041100号