MySQL主从延时监控
一、什么是主从延时？
主库发生了操作,从库"很久"才跟上来。
二、主从延时怎么监控？
Seconds_Behind_Master: 0 #从库落后于主库的时间
PS：有或者没有延时的情况。等于0，不代表没有延时。
评估主从延时更加精确的指标是，延时了多少日志量。
主库执行的日志量,从库执行的日志的对比。
日志量：
主库binlog位置点
从库：relay执行的位置点
三、如何计算日志量
单位是字节
[root@slave1 mysql]# cat relay-log.info
7 #来自于那个主库？
./slave1-relay-bin.000005 #relay执行到的位置点（两行）
360
mysql-bin.000004 #对应主库的日志位置点
679121
0 #不管
0
1
四、主从复制延迟原因
4.1、主库
外部:网络，硬件配置，主库业务繁忙，从库太多
主库业务繁忙:
1．拆分业务（(分布式):组件分离，垂直，水平
2．大事务的拆分。比如，1000w业务拆分为20次执行。
内部:
1.二进制日志更新问题:
解决方案:
sync binlog=1
2．问题: ―5.7之前的版本，没有开GTID之前，主库可以并发事务，但是dump传输时是串行。所以会导致，事务量，大事务时会出现比较严重延时。
解决方案:
5.6+版本，手工开启gtid，事务在主从的全局范围内就有了唯一性标志。
5.7+版本，无需手工开启，系统会自动生成匿名的GTID信息
有了GTID之后，就可以实现并发传输binlog。
但是,即使有这么多的优秀特性，我们依然需要尽可能的减少大事务，以及锁影响
判断主库传输不及时：
1. seconds behind master
2．主库:show master status; 从库:show slave status G
4.2、从库
外部:网络，从库配置低，参数设定。
内部:
Io线程:
写relay-log -->Io 性能。
sQL线程:
回放sQL默认在非GTID模式下是串行的解决方案:
1．开启GTID2．串行改并行
5.6+ GTID: database级别，基于库级别sQL线程并发。
5.7+ GTID: Logic clock逻辑时钟。保证了同库级别下的事务顺序问题。所以可以理解为基于事务级别的并发回放。
以后生产推荐版本：
5.6.34+ 以上
5.7.17+ 以上
8.0.17+ 以上