三十八、主从复制延时
什么是主从延时
主库发生了数据的变化，从库很长时间才同步过来。
查看主从复制延时时间，单位秒
mysql> show slave status \G;
Seconds_Behind_Master: 0
注意：当该参数等于0时，也只能认为传输过程中没有延迟， 此时还要根据对比主库的Position号跟从库的IO线程接收到的Position号是否一致，以及SQL线程回放才能判断是否有延迟。
参考资料：判断主从是否延时
主从复制延时的原因
主库外部方面原因
1、网络延迟
2、硬件配置差
3、主库业务繁忙
4、从库太多
关于主库外部方面原因其他3点都好解决，这里只介绍一下主库业务繁忙的解决方案
拆分业务，分布式设计
1、组件拆分
2、垂直拆分(将库分担到多个mysql实例中)
3、水平才分(将大表拆分成小表)
4、大事务拆分(将一个事务分成多个事务分别执行)
5、减少慢语句以及锁的影响
主库内部方面原因
1、提交数据迟迟不写入binlog不能触发Dump_thread发送日志
设置sync_binlog=1 参数，即每次事务提交立即写入binlog中
2、dump_thread是串行工作的，导致传送日志较慢
多个update更新操作在主库是并发执行，如果并发事务量大或者大事务时，以dump_thread默认串行传输binlog的方式，即一次只能传一个，导致传送日志慢，引发延时。
注意：5.6之前的版本默认是串行传输，使用Postion号的复制方法，一个事务中每条语句是没有固定编号，如下图所示
这种方式可以使用GTID解决，每个事务都有编号，即使乱序传输也能重新整齐
5.6版本需要手工开启GTID
5.7版本之后是无需开启GTID，系统会默认生成类似GTID信息执行并发传输
从库外部方面原因
1、网络延迟
2、从库配置低
3、主从的参数配置
4、主从版本有差异
从库内部方面原因
1、从库是默认是单SQL线程，一次只能执行一个事务
5.6版本，使用GTID可以实现基于库的sql并发，即基于不同库的事务进行并发回放，同库的事务还是串行的。
5.7版本，增加了logical_clock逻辑时钟模式，即针对事务进行并发，能确定同库级别下事务的前后顺序。
从库的SQL并发工作线程参数，取值范围0-16
mysql> show variables like '%worker%';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| slave_parallel_workers | 0 |
+------------------------+-------+
1 row in set (1.52 sec)
