共计 1153 个字符，预计需要花费 3 分钟才能阅读完成。
如何监控 MySQL 主从之间的延迟，通常有两种方法：Seconds_Behind_Master 和 mk-heartbeat
方法 1：通过监控 show slave status\G 命令输出的 Seconds_Behind_Master 参数的值来判断，是否有发生主从延时。
show slave status; # 需要有 replcation client 权限
以下是 show slave status\G 的输出结果的几个重点参数说明：
Slave_IO_Running：该参数可作为 io_thread 的监控项，Yes 表示 io_thread 的和主库连接正常并能实施复制工作，No 则说明与主库通讯异常，多数情况是由主从间网络引起的问题；
Slave_SQL_Running：该参数代表 sql_thread 是否正常，具体就是语句是否执行通过，常会遇到主键重复或是某个表不存在。
Seconds_Behind_Master：是通过比较 sql_thread 执行的 event 的 timestamp 和 io_thread 复制好的 event 的 timestamp(简写为 ts) 进行比较，而得到的这么一个差值；
NULL—表示 io_thread 或是 sql_thread 有任何一个发生故障，也就是该线程的 Running 状态是 No，而非 Yes。
0 — 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为 lag 不存在。
正值 — 表示主从已经出现延时，数字越大表示从库落后主库越多。
负值 — 几乎很少见，我只是听一些资深的 DBA 说见过，其实，这是一个 BUG 值，该参数是不支持负值的，也就是不应该出现。
方法 2：mk-heartbeat：Maatkit 万能工具包中的一个工具，被认为可以准确判断复制延时的方法。
mk-heartbeat 的实现也是借助 timestmp 的比较实现的，它首先需要保证主从服务器必须要保持一致，通过与相同的一个 NTP server 同步时钟。它需要在主库上创建一个 heartbeat 的表，里面至少有 id 与 ts 两个字段，id 为 server_id，ts 就是当前的时间戳 now()，该结构也会被复制到从库上，表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这个周期默认为 1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期去比较，复制过来记录的 ts 值与主库上的同一条 ts 值，差值为 0 表示无延时，差值越大表示延时的秒数越多。我们都知道复制是异步的 ts 不肯完全一致，所以该工具允许半秒的差距，在这之内的差异都可忽略认为无延时。这个工具就是通过实打实的复制，巧妙的借用 timestamp 来检查延时；
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-08/133872.htm
