MySQL主从复制之并行复制说明
传统单线程复制说明
众所周知,MySQL在5.6版本之前,主从复制的从节点上有两个线程,分别是I/O线程和SQL线程。
- I/O线程负责接收二进制日志的Event写入Relay Log。
- SQL线程读取Relay Log并在数据库中进行回放。
以上方式偶尔会造成延迟,那么可能造成主从节点延迟的情况有哪些?
- 1.主库执行大事务(如:大表结构变更操作)。
- 2.主库大批量变更(如:大量插入、更新、删除操作)。
- 3.ROW同步模式下,主库大表无主键频繁更新。
- 4.数据库参数配置不合理,从节点性能存在瓶颈(如:从节点事务日志设置过小,导致频繁刷盘)。
- 5.网络环境不稳定,从节点IO线程读取binlog存在延迟、重连情况。
- 6.主从硬件配置差异,从节点的硬件资源使用达到上限。(比如:主节点SSD盘,从节点SAS盘)
可以对以上延迟原因做个大致分类。
- 1.硬件方面问题(包括磁盘IO、网络IO等)
- 2.配置方面问题。
- 3.数据库设计问题。
- 4.主库大批量变更,从节点SQL单线程处理不够及时。
总结
分析以上原因可以看出要想降低主从延迟,除了改善硬件方面条件之外,另外就是需要DBA关注数据库设计和配置问题,最后就是需要提高从节点的并发处理能力,由单线程回放改为多线程并行回放是一个比较好的方法,关键点在于如何在多线程恢复的前提下解决数据冲突和故障恢复位置点的确认问题。
MySQL5.6基于库级别的并行复制
在实例中有多个数据库的情况下,可以开启多个线程,每个线程对应一个数据库。该模式下从节点会启动多个线程。线程分为两类 Coordinator 和 WorkThread。
- 线程分工执行逻辑
Coordinator
线程负责判断事务是否可以并行执行,如果可以并行就把事务分发给WorkThread
线程执行,如果判断不能执行,如DDL
,跨库操作
等,就等待所有的worker线程执行完成之后,再由Coordinator
执行。
- 关键配置信息
slave-parallel-type=DATABASE