在监控Mysql主从集群的时候,通常会使用以下三个参数
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Seconds_Behind_Master: 0
实际上,这种方式是有问题的。下面转载的两篇文章有详细的描述。
简单来说:如果由于某种原因,主库的“线程”僵死,无法将binlog“推送”到从库,那么从库的IO状态将在“一段时间”内一直处于yes状态,而SQL和SBM也分别处于YES和0的状态,无法识别主从已经出现异常。
其中几个比较关键的地方:
- 负责推送binlog的线程binlog dump意外终止,从库即无法接受到主库的binlog日志。
- 从库需要等待一段时间slave_net_timeout之后,才会感知到这种错误的发生。
转载一:
MySQL同步状态双Yes的假象及seconds_behind_master的含义
Shows the replication heartbeat interval (in seconds) on a replication slave.
This counter increments with each replication heartbeat received by a replication slave since the last time that the slave was restarted or reset, or a CHANGE MASTER TO
statement was issued.
转载二:
请不要用Seconds_Behind_Master来衡量MySQL主备的延迟时间
http://www.woqutech.com/?p=1116
在mysql-5.6版本的环境中,按照作者的方法测试没有成功。是因为5.6的多线程复制引起的么?