MySQL复制中slave延迟监控

因此，相对更加严谨的做法是：
在第三方监控节点上，对MASTER和SLAVE同时发起SHOW BINARY LOGS和SHOW SLAVE STATUS\G的请求，最后判断二者binlog的差异，以及 Exec_Master_Log_Pos 和Read_Master_Log_Pos 的差异。

例如：
在MASTER上执行SHOW BINARY LOGS 的结果是：

+------------------+--------------+
| Log_name | File_size |
+------------------+--------------+
| mysql-bin.000009 | 1073742063 |
| mysql-bin.000010 | 107374193 |
+------------------+--------------+

而在SLAVE上执行SHOW SLAVE STATUS\G 的结果是：

Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 668711237
Relay_Master_Log_File: mysql-bin.000009
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
***
Exec_Master_Log_Pos: 654409041

***
Seconds_Behind_Master: 3296
***

这时候，SLAVE实际的延迟应该是：
mysql-bin.000009 这个binlog中的binlog position 1073742063 和 SLAVE上读取到的binlog position之间的差异延迟，即：

1073742063 - 654409041 = 419333022 个binlog event

并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event，共

107374193 + 419333022 = 526707215 个binlog event

后记更新：

1、可以在MASTER上维护一个监控表，它只有一个字段，存储这最新最新时间戳（高版本可以采用event_scheduler来更新，低版本可以用cron结合自动循环脚本来更新），在SLAVE上读取该字段的时间，只要MASTER和SLAVE的系统时间一致，即可快速知道SLAVE和MASTER延迟差了多少。不过，在高并发的系统下，这个时间戳可以细化到毫秒，否则哪怕时间一致，也是有可能会延迟数千个binlog event的。
2、有网友细心支出上面的计算延迟有误，应该是mysql-bin.000009的最大事件数减去已经被执行完的事件数，即1073742063 – 654409041= 419333022个binlog event，再加上mysql-bin.000010这个binlog已经产生的107374193个binlog event，共526707215 个binlog event。

转载自：http://imysql.com/2014/08/30/mysql-faq-howto-monitor-slave-lag.shtml

MySQL复制中slave延迟监控

标签：