在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟。这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素。 首先,我们先看下SLAVE的状态:
代码如下:
yejr@imysql.com [(none)]> show slave status\G
*************************** 1. row *************************** Slave_IO_State: Waiting for master to send event *** Master_Log_File: mysql-bin.000327 Read_Master_Log_Pos: 668711237 Relay_Log_File: mysql-relay-bin.002999 Relay_Log_Pos: 214736858 Relay_Master_Log_File: mysql-bin.000327 Slave_IO_Running: Yes Slave_SQL_Running: Yes *** Skip_Counter: 0 Exec_Master_Log_Pos: 654409041 Relay_Log_Space: 229039311 *** Seconds_Behind_Master: 3296 ***
可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒。 我们再来看下SLAVE上的2个REPLICATION进程状态:
代码如下:
yejr@imysql.com [(none)]> show full processlist\G
*************************** 1. row *************************** Id: 6 User: system user Host: db: NULL Command: Connect Time: 22005006 State: Waiting for master to send event Info: NULL *************************** 2. row *************************** Id: 7 User: system user Host: db: NULL Command: Connect Time: 3293 State: Updating Info: UPDATE ** SET ** WHERE **
可以看到SQL线程一直在执行UPDATE操作,注意到 Time 的值是 3293,看起来像是这个UPDATE操作执行了3293秒,一个普通的SQL而已,肯定不至于需要这么久。 而IO线程的Time值则是该线程自从启动以来的总时长(多少秒),如果系统时间在IO线程启动后发生修改的话,可能会导致该Time值异常,比如变成负数,或者非常大。 来看下面几个状态:
好了,最后我们说下如何正确判断SLAVE的延迟情况:
因此,相对更加严谨的做法是:
例如:
而在SLAVE上执行SHOW SLAVE STATUS\G 的结果是:
这时候,SLAVE实际的延迟应该是: 1073742063 - 654409041 = 419333022 个binlog event 并且还要加上 mysql-bin.000010这个binlog已经产生的107374193个binlog event,共 107374193 + 419333022 = 526707215 个binlog event (责任编辑:IT) |