MySQL8.0新特性学习笔记（一）：binlog复制策略优化

看一下几个版本以来binlog复制策略的演进。

 

5.6以前的版本
经典的主从复制模型：

1，Master提交事务。

2，binlog写入binlog文件。

3，Slave的IO线程把Master上的binlog写入Slave的RelayLog。

4，Slave单线程从RelayLog中读取日志并执行。

瓶颈：单线程处理RelayLog太慢。

 

5.6版本
开始使用库级的并行复制，为了优化单线程处理RelayLog太慢的问题。

有SQL线程作为Coordinator调度线程，同时启动多个线程作为WorkThread工作线程，调度线程读取RelayLog文件内容，判断是否跨库，然后分配给不同的工作线程来处理。

单库模式下，效率可能还没有原来的模式快。

 

5.7版本
开始使用基于Group Commit的并行复制。

 

Group Commit解决的问题：

Master提交事务时，需要将binlog写入磁盘文件并调用fsync磁盘同步指令，这是一个加锁的操作，所以写入binlog还是串行的。提交事务并发比较高时，效率比较慢。

 

Group Commit的策略：

把提交事务的过程分为三个阶段，分别是Flush，Sync，Commit，每个阶段维护一个队列，由队列中的第一个线程执行该阶段的操作。达到的效果是可以一次把一批事务的binlog写到磁盘文件。每次一起提交的文件属于一个Group。

根据InnoDB事务的原理，Group Commit中的事务应该是没有行级锁的冲突，一批事务在Slave中可以并行处理。

 

在binlog中会记录两个值，last_committed 和 sequence_number。

sequence_number：事务编号，全局唯一。

last_committed：上组事务中最后提交的那个事务的编号。

那么，两个事务如果last_committed相同，代表他们是同一组提交的事务。

 

相关参数：

slave_parallel_type：回放策略。设为DATABASE表示采用5.6版本的库级并行复制，设为LOGICAL_LOCK表示采用5.7版本的Group Commit策略。

binlog_group_commit_sync_delay：为Group Commit而设定的commit延迟。

binlog_group_commit_sync_no_delay_count：为Group Commit而设定的不再等待延迟的事务数。

以上两个参数是为了Master并发不大时也能享受到Group Commit的性能提高。

 

8.0版本
使用WriteSet策略。

在Master生成binlog时，不再按照Group提交，而是通过WriteSet策略，使用写集合，判断提交的事务是否有依赖关系。

 

更详细一点的WriteSet策略流程：

1，建立vector变量保存已提交事务的Hash值。

2，如果某事务修改的行里面有主键，则vector保存主键（及库，表等信息）的Hash值，有非空唯一键，则保存非空唯一键（及库，表等信息）的Hash值，如果有外键，则保存外键的Hash值，以上都没有，vector不保存该事务信息。

3，如果某事务修改的行的主键是其他表的外键，则此事务不参与此策略，vector不保存此事务的信息。

4，如果某事务最终没有被vector保存信息，则此事务不参与此策略。

5，比较事务的vector信息，无冲突则表示可以一起提交，last_committed改为最后一个已提交的事务相同的last_committed。

6，一起提交的事务最终被并行处理。不参与此策略的事务使用5.7版本的组提交策略。

 

注：

1，WriteSet策略依赖主键或者非空唯一键。

2，WriteSet策略需要把Binlog设为Row格式。

3，此策略在Master生成binlog时就生效，所以即使Slave不是8.0版本也能享受此策略的优化。

 

相关系统变量

binlog-transaction-dependency-tracking

此系统变量可设置以下三个值：

COMMIT_ORDER：5.7版本的组提交策略。

WRITESET：基于WriteSet的策略。效率最高。

WRITESET_SESSION：基于WriteSet的策略后再次计算，可以保证同一个session在Slave上执行事务的顺序不变。