线上一个mysql主备延迟很大,master节点写入频繁,slave节点积累大量relay-log无法即使写入。
参考:https://www.cnblogs.com/conanwang/p/6006444.html
为什么会出现大量relay-log
首先这个需要从mysql的同步机制说起,同步-->半同步
Master节点的数据库实例并发跑多个线程同时提交事务,提交的事务按照逻辑的时间(数据库LSN号)顺序地写入binary log日志,slave节点通过I/O线程写到本地的relay log日志,为了保证主备数据一致性,slave节点必须按照同样的顺序执行,如果顺序不一致容易造成主备库数据不一致的风险。但是slave节点只有SQL单线程来执行relay log中的日志信息重放主库提交得事务,造成主备数据库存在延迟- 处理方法
能物理处理的建议直接物理解决
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