MySQL DBA面试全揭秘（三）

波嗷宝

接上一篇文章MySQL DBA面试全揭秘（二）
五、如何确认MySQL replication真正的复制延迟是多少？
1、利用Seconds_Behind_Master计算主从复制延迟时间
在slave上执行show slave status，监控Seconds_Behind_Master列值，备库Seconds_Behind_Master值是通过将服务器当前的时间戳与二进制日志中的事件时间戳相对比得到的。
它的值有以下几种：
NULL：表示io线程或sql线程至少有一个发生故障。
0：该值为零，表示主从复制良好。
正数：表示主从已经出现延时，数字越大表示从库落后主库越多。
如果在I/O线程没有延时的情况下，这个值还是准确的，但在网络异常时延迟的数据就不准确了。
你可能会问，如果主备库机器的系统时间设置不一致，会不会导致主备延迟的值不准？
其实不会的。因为，备库连接到主库的时候，会通过执行 SELECTUNIX_TIMESTAMP() 函数来获得当前主库的系统时间。如果这时候发现主库的系统时间与自己不一致，备库在执行 Seconds_Behind_Master 计算的时候会自动扣掉这个差值。

2、利用Master_Log_Pos计算主从复制延时日志量
如果I/O有延迟，那么Seconds_Behind_Master列值就不准确了，这时应该在主库上show master status，记录LogFile和Log Position值，然后再在从库上show slave status，查看Read_Master_Log_Pos和Exec_Master_Log_Pos，看看BinLog在主从上各自的位置，可以知道是否延迟以及延迟日志量。

3、利用第三方工具pt-heartbeat或mk-heartbeat计算主从复制延迟时间
pt-heartbeat是percona公司开发用来更为精确的检测主从延迟的小工具，其工作原理如下：
首先通过pt-heartbeat在主库创建一张heartbeat表，并以--interval(seconds)参数指定的频率写入timestamp类型数据(heartbeat record)，
然后在从库回放该记录时，通过与从库的系统时间做比对计算出时间差，得出主从延迟的具体数值，这样当主从延迟或复制中断，延迟值仍会不断增加。
mk-heartbeat，Maatkit万能工具包中的一个工具，被认为可以准确判断复制延时的方法。
mk-heartbeat的实现也是借助timestmp的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面至少有id与ts两个字段，id为server_id，ts就是当前的时间戳now()，该结构也会被复制到从库上。表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为1秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示延时的秒数越多。
我们都知道复制是异步的，ts值不可能完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制，巧妙的借用timestamp来检查延时，非常好用。
虽然这两种工具监控延迟时间比Seconds_Behind_Master准确，但是心跳进程存在单点风险，当心跳进程不可用时则延迟检测失效，且心跳记录表数据会污染 binlog，大量心跳事件占据 binlog，占用更多空间，干扰排查和日志恢复。
总之，生产环境监控主从复制延时需要根据监控场景和需求灵活使用。
以上。