MySQL主从延时监控

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+		以上