mysql主从之主从延时监控及原因分析

网络 
主从硬件差异较大
版本差异
参数因素

(1) 二进制日志写入不及时
[rep]>select @@sync_binlog;
(2) CR(传统)的主从复制中,binlog_dump线程,事件为单元,串行传送二进制日志(5.6 5.5)

1. 主库并发事务量大,主库可以并行,传送时是串行
2. 主库发生了大事务,由于是串行传送,会产生阻塞后续的事务.
3. 主库本身就及其繁忙,如慢语句, 锁等待, 从库个数比较多

解决方案:
1. 5.6 开始,开启GTID,实现了GC(group commit)机制,可以并行传输日志给从库IO线程,这个还需要配合双一标准来实现
2. 5.7 开始,不开启GTID,会自动维护匿名的GTID,也能实现GC,我们建议还是认为开启GTID
3. 大事务拆成多个小事务,可以有效的减少主从延时.

SQL线程导致的主从延时
在CR(传统)复制情况下: 从库默认情况下只有一个SQL线程,只能串行回放事务SQL
1. 主库如果并发事务量较大,从库只能串行回放
2. 主库发生了大事务,会阻塞后续的所有的事务的运行

解决方案:
1. 5.6 版本开启GTID之后,加入了SQL多线程的特性,但是只能针对不同库(database)下的事务进行并发回放.
2. 5.7 版本开始GTID之后,在SQL线程方面,提供了基于逻辑时钟(logical_clock),binlog方面加入了seq_no机制(同线程下的序列号),
　　真正实现了基于事务级别的并发回放,这种技术我们把它称之为MTS(enhanced multi-threaded slave).
　　总结: 5.6基于库级别的并发sql线程; 5.7基于事务级别的并发sql线程.
3. 大事务拆成多个小事务,可以有效的减少主从延时.
[https://dev.mysql.com/worklog/task/?id=6314]

1. 可以直接查看relay-log.info文件, 该文件中记录了relay-log和master-log之间的对应关系.
2. show relaylog events in '192-relay-bin.000005';


66.