主从复制延迟的监测，我以前的做法是通过比较show slave status\G中的两个变量的差值（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表示无延时，差值越大表示 延时的秒数越多。
语法：
pt-heartbeat -D test --monitor -h slave-server
pt-heartbeat -D test --monitor -h slave-server --dbi-driver Pg
只检查一次slave复制延迟：
pt-heartbeat -D test --check h=slave-server
它由两部分组成：第一部分 是--update 实例，它连接到master每--interval秒更新一张表的时间记录。第二部分是--monitor或者--check实例 连接到slave。它会检查新记录中的时间戳来确定两者之间的延迟。
CREATE TABLE heartbeat ( ts varchar(26) NOT NULL, server_id int unsigned NOT NULL PRIMARY KEY, file varchar(255) DEFAULT NULL, -- SHOW MASTER STATUS position bigint unsigned DEFAULT NULL, -- SHOW MASTER STATUS relay_master_log_file varchar(255) DEFAULT NULL, -- SHOW SLAVE STATUS exec_master_log_pos bigint unsigned DEFAULT NULL -- SHOW SLAVE STATUS );
存储引擎推荐使用memory存储引擎。pt-heartbeat时间精确到0.01秒，master和slave的始终速率必须经过NTP服务进行同步。只要检查的时间差小于0.5秒，那么pt-heartbeat will report zero seconds of delay。
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/977998，如需转载请自行联系原作者
