主从延时(二)

对于Seconds_Behind_Master,很多人误以为是从库落后主库多少秒,从Seconds_Behind_Master单词的字面上看也是如此。

但是看看Seconds_Behind_Master的原理就明白了,其延迟是通过备库当前的时间戳减去SQL线程正在执行的SQL语句的时间戳计算出来的。


Seconds_Behind_Master描述延时是不太准确的,比如IO线程挂起了,主从有明显的延时,你会发现Seconds_Behind_Master可能还是0.


可以进行下面两个测试:

测试一:把备库当前时间进行调整。

测试二:断开备库的网络连接,你会发现Seconds_Behind_Master仍旧为0,备库过来slave-net-timeout秒还没有收到主库来的数据,它就会开始第一次重试。然后每过master-connect-retry秒,备库会再次尝试重连主库。直到重试了master-retry-count次,它才会放弃重试。如果重试的过程中,脸上了主库,那么它认为当前主库是好的,又会开始slave-net-timeout秒的等待。

slave-net-timeout的默认值是3600秒,master-connect-retry默认值是60秒,master-retry-count默认值为86400次。


slave-net-timeout的3600秒的默认值有些大,建议可以设置小一点,比如30秒。


可以使用percona的pt-heartbeat工具计算延时:

原理是在主库生成一张表,把这个表同步到备库上,这个表里记录时间,在备库上用当前时间减去表里时间就得到了延时数据。

表如下:



在主库上执行:

pt-heartbeat --defaults-file=/usr/local/mysql/my.cnf --database test --update --create-table --deamonize 

说明:

--defaults-file 指定配置文件

--database 指定数据库
--update 更新

--create-table  创建表

-deamonize 后台运行


在从库上执行:

pt-heartbeat --defaults-file=/usr/local/mysql/my.cnf  -D test --monitor --master-slave-id 1

-defaults-file 指定配置文件 

 -D 指定数据库

--monitor 监控

--master-slave-id  指定主库的server id



第一列的当前延时时间,后面的三列分别是5分钟、10分钟、15分钟的延时。

相关文章
相关标签/搜索