主从复制延迟的监测,我以前的做法是通过比较show slave statusG中的两个变量的差值(Read_Master_Log_Pos,Exec_Master_Log_Pos),将差值设置为一个自己认为合理的范围,Seconds_Behind_Master 没有适用过,今天做一次解析:
   Seconds_Behind_Master 是通过比较 SQL THREAD 接受 events事件的时间戳(timestamp) 与IO THREAD  执行事件 events时间戳的差值--秒数来确定slave 落后于master多少。如果主从机器的时间不同,该时间的计算也是不会受影响的(如果时间发生异常,则这个秒数的就不怎么可靠啦)
   如果slave SQL thread 或者 slave I/O thread 或者没有连接到master,那么该变量的值为NULL.
       0:表示master slave 复制没有延迟(大部分情况下是这个样子)。
   正值:表示slave落后于master的秒数。
   在网络很快的情况下,I/O thread 能够很快的从master上获取binlog到slave的 relay-log。这种情况下, seconds_behind_master的值能真正代表slave落后于master的秒数。在网络很差的情况下,I/O thread 同步很慢,slave收到的二进制日志信息,SQL THREAD能够很快的执行。这个时候 seconds_behind_master 是0,这种情况下 slave落后于master很多。
    为了排除网络的干扰,我们可以参考percona 的工具 pt-heartbeat.
    该工具可以计算出MySQL复制或者是PostgreSQL,它可以更新master或者监控复制。它还可以从my.cnf 读取配置。它借助timestmp的比较实现的,首先需要保证主从必须要保持一致,通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表,里面的时间戳ts就是当前的时间戳 now(),该结构也会被复制到从库上。表建好以后,会在主库上以后台进程的模式去执行一行更新操作的命令,定期去向表中的插入数据,这 个周期默认为1 秒,同时从库也会在后台执行一个监控命令,与主库保持一致的周期+0.5S(默认0.5S延迟检查)去比较,复制过来记录的ts值与主库上的同一条ts值,差值为0表示无延时,差值越大表示 延时的秒数越多。