传统单线程复制阐明

家喻户晓，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://mp.weixin.qq.com/s/rcPkrutiLc93aTblEZ7sFg

一组事务同时提交也就意味着组内事务不存在抵触，故组内的事务在从节点上就能够并发执行，问题在于如何辨别事务是否在同一组中的，于是在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_committedGTID last_committed=0 sequence_number=1GTID last_committed=0 sequence_number=2GTID last_committed=2 sequence_number=3GTID last_committed=2 sequence_number=4GTID last_committed=2 sequence_number=5GTID last_committed=2 sequence_number=6GTID last_committed=6 sequence_number=7GTID last_committed=6 sequence_number=8
  • 数据库配置
slave-parallel-type=LOGICAL_CLOCK
  • 计划有余点
基于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 Variablebinlog_transaction_dependency_tracking
ScopeGlobal
DynamicYes
SET_VAR Hint AppliesNo
TypeEnumeration
Default ValueCOMMIT_ORDER
Valid ValuesCOMMIT_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 Variablebinlog_transaction_dependency_history_size
ScopeGlobal
DynamicYes
SET_VAR Hint AppliesNo
TypeInteger
Default Value25000
Minimum Value1
Minimum Value1000000
  • transaction_write_set_extraction
该模式反对三种算法，默认采纳XXHASH64，当从节点配置writeset复制的时候，该配置不能配置为OFF。该参数曾经在MySQL 8.0.26中被弃用，后续将会进行删除。
Command-Line Format--transaction-write-set-extraction[=value]
Deprecated8.0.26
System Variablebinlog_transaction_dependency_history_size
ScopeGlobal, Session
DynamicYes
SET_VAR Hint AppliesNo
TypeEnumeration
Default ValueXXHASH64
Valid ValuesOFF
MURMUR32
XXHASH64

数据库配置

slave_parallel_type = LOGICAL_CLOCKslave_parallel_workers = 8binlog_transaction_dependency_tracking = WRITESETslave_preserve_commit_order = 1

援用材料：

  • 阿里内核月报：
    http://mysql.taobao.org/monthly/2018/06/04/
  • 官网文档：
    https://dev.mysql.com/doc/refman/8.0/en/replication-options-binary-log.html

Enjoy GreatSQL :)

# 文章举荐：

GreatSQL季报（2021.12.26）

https://mp.weixin.qq.com/s/FZ...

技术分享|sysbench 压测工具用法浅析

https://mp.weixin.qq.com/s/m1...

故障剖析 | linux 磁盘io利用率高，剖析的正确姿态

https://mp.weixin.qq.com/s/7c...

技术分享|闪回在MySQL中的实现和改良

https://mp.weixin.qq.com/s/6j...

万答#20，索引下推如何进行数据过滤

https://mp.weixin.qq.com/s/pt...

对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr...

GitHub:

https://github.com/GreatSQL/G...

Bilibili：

https://space.bilibili.com/13...

微信&QQ群：

可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！