Seconds_Behind_Master从 SHOW SLAVE STATUS 来看，它被认为是一种不可靠的从属滞后测量方法。mk-heartbeat 通常被提供作为一种可靠的替代方案。
现在mk-heartbeat甚至不需要Slave运行。
http://www.maatkit.org/doc/mk-heartbeat.html
摘抄：
mk-heartbeat 是一个由两部分组成的 MySQL 和 PostgreSQL 复制延迟监控系统，它不需要从属服务器工作（换句话说，它不依赖于 MySQL 上的 SHOW SLAVE STATUS）。
所以我的理解是，您在 Master 上创建一个 DB/表，然后使用 --update 运行 mk-heartbeat，如下所示：
./mk-heartbeat -D heart --table beat -u heartbeat -p XXXXXXXXX --update -h 192.168.2.80
然后在从服务器上将 mk-heartbeat 指向主服务器上的数据库/表（即，在主服务器上执行 GRANT 语句以赋予从服务器权限）并使用 --monitor 运行，如下所示：
./mk-heartbeat -D heart --table beat -u heartbeat_slave -p XXXXXXXXX --monitor -h 192.168.2.80
我已经这样做了，甚至在反复更新 MySQL 示例员工工资表中的 280 万多行时（这会产生 Slave 滞后，至少根据不可靠的 Seconds_Behind_Master），我从未看到 mk-heartbeat --monitor 发生变化：
0s [ 0.00s, 0.00s, 0.00s ]
也许是我没有产生足够的滞后，并且根据 mk-heartbeat 文档，复制事件在不到半秒的时间内传播，我可以预期看到零秒的延迟：
mk-heartbeat 的精度为一秒。这取决于主服务器和从服务器的时钟是否通过 NTP 紧密同步。--update 检查发生在秒的边缘，而 --monitor 检查发生在秒的中间。只要服务器的时钟偏差不大，并且复制事件在不到半秒的时间内传播，mk-heartbeat 就会报告零秒延迟。
（我的服务器的时钟使用 NTP 并且同步。）
但是Seconds_Behind_Master落后了数百秒，所以我认为它们不会在不到半秒的时间内传播，所以我仍然不确定我是否获得了对 mk-heartbeat 实用程序的准确视图。
我很想听听那些已经部署此工具来监控他们的 MySQL 复制的人的意见。
提前致谢。
干杯
答案1
你已经接近了，但问题是你让两个实例都指向主实例。你想要的是，一个实例每秒更新主实例，第二个实例每秒读取从实例。
还请注意，它根本不需要在实际的数据库服务器上运行，它使用常规的 mysql 客户端连接。我从我的 cacti 服务器运行它。下面是我的清理过的 /etc/rc.local 作为示例：
/usr/bin/mk-heartbeat -D maatkit -u maatkit -paardvark --update -h sql-master.fake.net --daemonize /usr/bin/mk-heartbeat -D maatkit -u maatkit -paardvark -h sql-slave.fake.net --monitor --file /tmp/sql-slave.heartbeat --daemonize
答案2
这是我正在做的事情：
mk-heartbeat -D maatkit -u maatkit -p pass --update -h master
mk-heartbeat -D maatkit -u maatkit -p pass -h slave --monitor
当我运行上述代码时，输出代码片段是
1618s [ 53.92s, 10.78s, 3.59s ]
1619s [ 80.90s, 16.18s, 5.39s ]
1620s [ 107.90s, 21.58s, 7.19s ]
1621s [ 134.92s, 26.98s, 8.99s ]
1622s [ 161.95s, 32.39s, 10.80s ]
1623s [ 189.00s, 37.80s, 12.60s ]
1624s [ 216.07s, 43.21s, 14.40s ]
1625s [ 243.15s, 48.63s, 16.21s ]
数字只是缓慢上升。
心跳表是否需要复制到从属设备？这是我所忽略的吗？