MySQL中slave监控的延迟情况分析
在MySQL复制环境中，我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟。这么做大部分情况下尚可接受，但并不够准确，而应该考虑更多因素。
首先，我们先看下SLAVE的状态：
*************************** 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进程状态：
*************************** 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而已，肯定不至于需要这么久。
实际上，在REPLICATION进程中，Time 这列的值可能有几种情况：
1、SQL线程当前执行的binlog（实际上是relay log）中的timestamp和IO线程最新的timestamp的差值，这就是通常大家认为的 Seconds_Behind_Master 值，并不是某个SQL的实际执行耗时；
2、SQL线程当前如果没有活跃SQL在执行的话，Time值就是SQL线程的idle time；
而IO线程的Time值则是该线程自从启动以来的总时长（多少秒），如果系统时间在IO线程启动后发生修改的话，可能会导致该Time值异常，比如变成负数，或者非常大。
来看下面几个状态：
#设置pager，只查看关注的几个status值 yejr@imysql.com [(none)]> pager cat | egrep -i 'system user|Exec_Master_Log_Pos|Seconds_Behind_Master|Read_Master_Log_Pos' #这是没有活跃SQL的情况，Time值是idle time，并且 Seconds_Behind_Master 为 0 yejr@imysql.com [(none)]> show processlist; show slave status\G | 6 | system user | | NULL | Connect | 22004245 | Waiting for master to send event | NULL | | 7 | system user | | NULL | Connect | 13 | Has read all relay log;** Read_Master_Log_Pos: 445167889 Exec_Master_Log_Pos: 445167889 Seconds_Behind_Master: 0 #和上面一样 yejr@imysql.com [(none)]> show processlist; show slave status\G | 6 | system user | | NULL | Connect | 22004248 | Waiting for master to send event | NULL | | 7 | system user | | NULL | Connect | 16 | Has read all relay log;** Read_Master_Log_Pos: 445167889 Exec_Master_Log_Pos: 445167889 Seconds_Behind_Master: 0 #这时有活跃SQL了，Time值是和 Seconds_Behind_Master 一样，即SQL线程比IO线程“慢”了1秒 yejr@imysql.com [(none)]> show processlist; show slave status\G | 6 | system user | | NULL | Connect | 22004252 | Waiting for master to send event | NULL | | 7 | system user | | floweradmin | Connect | 1 | Updating | update ** Read_Master_Log_Pos: 445182239 Exec_Master_Log_Pos: 445175263 Seconds_Behind_Master: 1 #和上面一样 yejr@imysql.com [(none)]> show processlist; show slave status\G | 6 | system user | | NULL | Connect | 22004254 | Waiting for master to send event | NULL | | 7 | system user | | floweradmin | Connect | 1 | Updating | update ** Read_Master_Log_Pos: 445207174 Exec_Master_Log_Pos: 445196837 Seconds_Behind_Master: 1
好了，最后我们说下如何正确判断SLAVE的延迟情况：
1、首先看 Relay_Master_Log_File 和 Master_Log_File 是否有差异；
2、如果Relay_Master_Log_File 和 Master_Log_File 是一样的话，再来看Exec_Master_Log_Pos 和 Read_Master_Log_Pos 的差异，对比SQL线程比IO线程慢了多少个binlog事件；
3、如果Relay_Master_Log_File 和 Master_Log_File 不一样，那说明延迟可能较大，需要从MASTER上取得binlog status，判断当前的binlog和MASTER上的差距；
因此，相对更加严谨的做法是：
在第三方监控节点上，对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
相关文章
MySQL日志记录了MySQL数据库日常操作和错误信息,MySQL有不同类型的日志文件,下面这篇文章主要给大家介绍了关于mysql日志文件之undo log和redo log的相关资料,需要的朋友可以参考下2022-04-04
MySQL中count(*)、count(1)和count(col)的区别汇总
count()函数是用来统计表中记录的一个函数，返回匹配条件的行数，下面这篇文章主要给大家总结介绍了关于MySQL中count(*)、count(1)和count(col)的区别，文中通过示例代码介绍的非常详细，需要的朋友可以参考下。2018-03-03
这篇文章主要给大家介绍了关于mysql中GROUP_CONCAT函数使用及遇到问题的相关资料,GROUP_CONCAT是用于将分组后的多个行连接为一个字符串的聚合函数,文中通过代码介绍的非常详细,需要的朋友可以参考下2023-09-09
这篇文章主要介绍了MySQL如何修改字段的默认值和空值，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2022-08-08
MySQL 不允许从远程访问的原因有很多除了下面的方法，还有需要看服务器安全设置禁止访问本机的3306端口。2010-03-03
这篇文章主要介绍了MySQL 数据类型及最优选取规则，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下，希望对你的学习有所帮助2022-08-08
这篇文章主要给大家介绍了关于如何通过一篇文章掌握MySQL的索引查询优化技巧，文中通过示例代码介绍的非常详细，对大家的学习或者使用MySQL具有一定的参考学习价值，需要的朋友们下面来一起学习学习吧2020-07-07
本文主要介绍了MySQL迁移KingbaseESV8R2的实现步骤，文中通过示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2022-02-02
这篇文章主要介绍了mysql获取group by总记录行数的方法,主要通过group by SQL_CALC_FOUND_ROWS语句来实现该功能,具有一定的实用价值,需要的朋友可以参考下2014-10-10
今天小编就为大家分享一篇关于GDB调试Mysql实战之源码编译安装，小编觉得内容挺不错的，现在分享给大家，具有很好的参考价值，需要的朋友一起跟随小编来看看吧2019-02-02
最新评论