||
众所周知,MySQL在5.6版本之前,主从复制的从节点上有两个线程,分别是I/O线程和SQL线程。
以上方式偶尔会造成延迟,那么可能造成主从节点延迟的情况有哪些?
可以对以上延迟原因做个大致分类。
分析以上原因可以看出要想降低主从延迟,除了改善硬件方面条件之外,另外就是需要DBA关注数据库设计和配置问题,最后就是需要提高从节点的并发处理能力,由单线程回放改为多线程并行回放是一个比较好的方法,关键点在于如何在多线程恢复的前提下解决数据冲突和故障恢复位置点的确认问题。
在实例中有多个数据库的情况下,可以开启多个线程,每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类 Coordinator 和 WorkThread。
Coordinator
线程负责判断事务是否可以并行执行,如果可以并行就把事务分发给WorkThread
线程执行,如果判断不能执行,如DDL
,跨库操作
等,就等待所有的worker线程执行完成之后,再由Coordinator
执行。
slave-parallel-type=DATABASE
这种并行复制的模式,只有在实例中有多个DB且DB的事务都相对繁忙的情况下才会有较高的并行度,但是日常维护中其实单个实例的的事务处理相对集中在一个DB上。通过观察延迟可以发现基本上都是基于热点表出现延迟的情况占大多数。如果能够提供基于表的并行度是一个很好方法。
简单来说就是在双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_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
基于组提交的同步有个不足点,就是当主节点的事务繁忙度较低的时候,导致时间段内组提交fsync刷盘的事务量较少,于是导致从库回放的并行度并不高,甚至可能一组里面只有一个事务,这样从节点的多线程就基本用不到,可以通过设置下面两个参数,让主节点延迟提交。
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 |
writeset 是一个HASH类型的数组,里面记录着事务的更新信息,通过transaction_write_set_extraction判断当前事务更新的记录与历史事务更新的记录是否存在冲突,判断过后再采取对应处理方法。writeset储存的最大存储值由binlog-transaction-dependency-history-size控制。
需要注意的是,当设置成WRITESET或WRITESET_SESSION的时候,事务提交是无序状态的,可以通过设置 slave_preserve_commit_order=1 强制按顺序提交。
设置保存在内存中的行哈希数的上限,用于缓存之前事务修改的行信息。一旦达到这个哈希数,就会清除历史记录。
合作电话:010-64087828
社区邮箱:greatsql@greatdb.com