Chinaunix首页 | 论坛 | 博客
  • 博客访问: 187088
  • 博文数量: 52
  • 博客积分: 120
  • 博客等级: 民兵
  • 技术积分: 1189
  • 用 户 组: 普通用户
  • 注册时间: 2011-08-03 15:41
个人简介

MySQL DBA

文章分类

全部博文(52)

文章存档

2013年(51)

2011年(1)

分类: Mysql/postgreSQL

2013-03-07 14:26:48

这个值来自show slave status\G 命令输出的其中一行,用于显示复制中slave 的同步延迟,单位秒。大部分时间认为它是准确地显示了同步的延迟情况,其实不然。

本质上seconds_behind_master的值的计算方式为salve 上SQL线程和IO线程的时间差,如果为0,则表示SQL线程和IO线程的进度是一致的(并不代表slave与master 是一致的)。

seconds_behind_master 的计算基于bin log 中event的时间戳。也是在某一时刻:      

             seconds_behind_master=ts(IO thread)-ts(SQL thread)      

     relay log 中event 的时间与master的binlog一致,则主从所在服务器的时钟不一致不会影响seconds_behind_master的计算。

如果master 与slave之间的网络状态良好,则IO线程和master的binlog进度延时非常小,如果master网络负载较高或者网络情况较差,则IO线程实际上是落后与master的,但SQL线程此时很容易就和IO线程保持一致而使seconds_behind_master=0,事实上复制存在延迟。

seconds_behind_master=NULL 时的情况:

    1.SQL 线程状态为NO,原因可以是relay log重放失败、人为停止slave/slave-sql 。

    2.IO线程未成功连接到master或者正在连接中。

所以网络良好的情况下,seconds_behind_master的值是有意义的。如果要排除网络问题更准确地计算复制的延迟,则需要准确计算master binlog 最新事件与slave sql 线程最新事件之间的时间差。

percona toolkit 中的工具pt-heartbeat (perl)通过创建实体表(server_id,timestamp),并周期性插入数据(当前时间),然后比较mater 和slave 上该表ts列的时间差来计算复制的延迟,但要求主从服务器时钟必须一致。从原理上看该工具对复制时延的监控会更加准确。

阅读(1811) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~