主从复制通过三个线程来完成，在master节点运行的binlog dump的线程，在slave 节点运行I/O线程和SQL线程master节点的Binlog

dump线程，当slave节点与master正常连接的时候，master把更新的binlog 内容推送到slave节点。

slave节点的I/O 线程 ，该线程通过读取master节点binlog日志名称以及偏移量信息将其拷贝到本地relay log日志文件。

slave节点的SQL线程，该线程读取relay

log日志信息，将在master节点上提交的事务在本地回放，达到与主库数据保持一致的目的。

问题1：

Master节点的数据库实例并发跑多个线程同时提交事务，提交的事务按照逻辑的时间(数据库LSN号)顺序地写入binary

log日志，,slave节点通过I/O线程写到本地的relay log日志，但是slave节点只有SQL单线程来执行relay

log中的日志信息重放主库提交得事务，造成主备数据库存在延迟(lag)

无论是MySQL还是MariaDB在Binary

Log Group Commit优化的目的都是：使高并发下的事务尽可能的在同一个时间点提交，然后用一次fsync()的操作将这一组的Binary

log缓存的数据写入磁盘。当并发事务可以在同一个时间提交，说明每个线程所执行的事务之间没有锁冲突(如果有锁冲突，并发的事务将无法在同一个时刻提交)，那么意味着这一组并发提交的事务在slave机器上能并发重放主库提交的事务，所以我们只需要在master机器对二进制日志进行Group

Commit的时候标记上组提交相关信息，slave机器就可以安全的并发执行主库提交的事务 为此主库的BINLOG会把一组可以并发的事打上last_committed=N的标记.

我们用命令 mysqlbinlog -vvv mysqlbinlog.0000003 | grep -i

last_committed    在MySQL

5.7的master机器上可以看到last_committed

和sequence_number

1.  #151223 15:11:28 server id 15102  end_log_pos 14623 CRC32

0x767a33fa GTID      last_committed=18         sequence_number=26

2.

3.  #151223 15:11:28 server id 15102  end_log_pos 15199 CRC32

0x7dd1bf05 GTID     last_committed=26         sequence_number=27

4.

5.  #151223 15:11:28 server id 15102  end_log_pos 15773 CRC32

0xb01dc76e GTID     last_committed=26

sequence_number=28

slave机器的relay

log中 last_committed相同的事务可以并发执行。从上面截取的信息可以看出last_committed=26的事务一共有8个：从sequence_number=27~33。假设当slave_parallel_workers=7时，Coordinator线程(SQL线程)分配这一组事务到worker中排队去执行。这里可以看出增加master库binary

log group

commit组中事务的数量可以提高slave机器并发处理事务的数量，MySQL5.7引入 binlog_group_commit_sync_delay和

binlog_group_commit_sync_no_delay_count参数即提高binary

log组提交并发数量。MySQL等待binlog_group_commit_sync_delay毫秒的时间直到binlog_group_commit_sync_no_delay_count个事务数时，将进行一次组提交。

总结:

MySQL 5.7 GA版本推出的 Enhanced Multi-threaded

Slaves功能，彻底解决了之前版本主备数据复制延迟的问题，开启该功能参数如下：

1.  # slave机器

2.  slave-parallel-type=LOGICAL_CLOCK

3.  slave-parallel-workers=16 ＃开启多线程复制

4.  master_info_repository=TABLE

5.  relay_log_info_repository=TABLE

6.  relay_log_recovery=ON