mysql slave节点多线程复制

线上一个mysql主备延迟很大，master节点写入频繁，slave节点积累大量relay-log无法即使写入。

参考：https://www.cnblogs.com/conanwang/p/6006444.html

1. 为什么会出现大量relay-log
   首先这个需要从mysql的同步机制说起，同步-->半同步
   Master节点的数据库实例并发跑多个线程同时提交事务，提交的事务按照逻辑的时间（数据库LSN号）顺序地写入binary log日志，slave节点通过I/O线程写到本地的relay log日志，为了保证主备数据一致性，slave节点必须按照同样的顺序执行，如果顺序不一致容易造成主备库数据不一致的风险。但是slave节点只有SQL单线程来执行relay log中的日志信息重放主库提交得事务，造成主备数据库存在延迟

2. 处理方法
   能物理处理的建议直接物理解决
   a. 磁盘使用SSD
   b. 磁盘组raid10
   c. 从文件系统层面/内核优化层面处理IO问题

mysql的处理方法
想方法让slave多线程执行relay log
MySQL 5.6版本引入并发复制（schema级别），基于schema级别的并发复制核心思想：“不同schema下的表并发提交时的数据不会相互影响，即slave节点可以用对relay log中不同的schema各分配一个类似SQL功能的线程，来重放relay log中主库已经提交的事务，保持数据与主库一致”。

MySQL 5.6基于schema级别的并发复制能够解决当业务数据的表放在不同的database库下，但是实际生产中往往大多数或者全部的业务数据表都放在同一个schema下，在这种场景即使slave_parallel_workers>0设置也无法并发执行relay log中记录的主库提交数据。 高并发的情况下，由于slave无法并发执行同个schema下的业务数据表，依然会造成主备延迟的情况。

MySQL 5.7 引入Enhanced Muti-threaded slaves,当slave配置slave_parallel_workers>0并且global.slave_parallel_type＝‘LOGICAL_CLOCK’,可支持一个schema下，slave_parallel_workers个的worker线程并发执行relay log中主库提交的事务。但是要实现以上功能，需要在master机器标记binary log中的提交的事务哪些是可以并发执行，虽然MySQL 5.6已经引入了binary log group commit，但是没有将可以并发执行的事务标记出来。

MySQL 5.7 GA版本推出的 Enhanced Multi-threaded Slaves功能，彻底解决了之前版本主备数据复制延迟的问题，开启该功能参数如下：

# slave机器
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-type=DATABASE #兼容MySQL 5.6基于schema级别的并发复制
slave-parallel-workers=4 ＃开启多线程复制
master_info_repository=TABLE
relay_log_info_repository=TABLE
relay_log_recovery=ON