second_behind_master：

1、 当从库不断的处理更新的时候，(正在复制的时候)这个值显示从库当前主机时间戳和来自主库的二进制中记录的时间戳之间的差异。

2、 当从库没有任何需要处理的更新时，例如主库不写入时，如果I/O线程和SQL线程都是yes，则这个值是0，否则为NULL

3、如果主库和从库之间的网络非常快， 那么从库的I/O线程读取的binlog会与主库中最新的binlog非常接近，这样计算出来的值会

很小，单位为秒，基本上可以替代主从之间的数据延迟时间，这个时候是可靠的。 相反，如果主库和从库之间的网络特别慢，则

从库中的binlog时间可能远远落后于主库最新的binlog，但是二者的真实偏差时间非常小（由于网络慢导致看着偏差比较大），

这个时候，这个字段的值是不可靠的。即使显示为0，但是也有可能是因为主库网络不好导致大量的binlog没有传过来，所以这个

值在网络比较慢的时候不可靠。

4、如果主库与从库本身的时间不一致，那么只要从库的复制线程启动之后，没有做过任何的时间变更，那么这个字段的值也是

可靠的，一旦修改了服务器的时间，那么这个值就变的不可靠了。

5、如果从库的SQL线程没有运行，则该字段显示为NULL；

如果从库的SQL线程已经消费完了relay log而I/O线程没有运行，则该字段显示为NULL；

如果I/O线程已经停止，但是relay log还没有重放完成的时候，仍旧会显示出复制时间。直到relay log被消费完，显示为NULL；

如果SQL线程和I/O线程都运行着，但是处于空闲状态，则该字段为0；

6、正常情况下，主库和从库中的binlog event值都来自于主库。如果在单线程复制的时候，我们在从库上做了一些操作，

则有可能导致这个值产生一些波动。因为有时候event的值来自于主库，有时候来自于从库。如果是多线程复制，则这个值是

基于Exec_Master_Log_Pos的enent时间戳来计算的。

    binglog日志中event的event header（event header的前4个字节）记录了event的时间戳， SQL回放的时间减去这个event产生的时间，就是Seconds_Behind_Master的时间。但是这个时间不准确，线上有时延时是几千秒(3600s)，但是突然就变成了0，有这种情况。

上面是官方文档中的说明，我从一些研究MySQL源码的文章中得到了下面这样的计算公式：

* clock_of_slave - last_timestamp_executed_by_SQL_thread - clock_diff_with_master

也就是"从库的当前系统（主机）时间 - 从库 SQL 线程正在执行的event的时间戳 - 主从库的系统（主机）之间的时间差",其中最

后一项diff的值，就是主库和从库的主机时差。这个时差在I/O线程启动的时候只计算一次，如果此时更改了系统时间，那么无疑会

导致复制的SBM值不可靠。

当Seconds_Behind_Master计算结果为负数的时候，直接归零

通过上面的描述，我们可以得到以下的结论：

1.  如果 I/O 和 SQL线程同时为 Yes，且SQL线程没有做任何事情（没有需要被执行的event），此时直接判定复制延迟结果为0，

不会走公式计算延迟时间，否则会走公式计算延迟时间

2.  如果 SQL线程为Yes，且还存在着 I/O 线程已经读取的relay log未应用完成的，则会走公式计算延迟时间，而不管 I/O线程是

否正在运行，但当SQL线程重放完成了所有relay log时，如果 I/O线程不为Yes，直接判定复制延迟结果为NULL

3.  任何时候，如果SQL线程不为Yes，直接判定复制延迟结果为NULL。当计算出的复制延迟为负数时，直接归0

4. 当SQL线程重放大事务时，SQL线程的时间戳更新相当于被暂停了（因为一个大事务的event在重放时需要很长时间才能完成，

虽然这个大事务也可能会有很多event，但是这些event的时间戳可能全都相同），此时，根据计算公式可以得出，无论主库是否

有新的数据写入，从库复制延迟仍然会持续增大，会出现主库停止写入之后，从库复制延迟逐渐增大到某个最高值之后突然变为

0的情况

5.根据公式计算，如果主库持续不断产生二进制日志（持续不断有数据变更），则复制延迟的计算结果不会出现误差

（或者说误差可以忽略不计，因为从库的系统时钟是正常向后推进的，除非主从库的系统时间被改动了），如果在慢速网络中

主库断断续续写入数据，甚至主库突然停止任何数据写入，之后实际上主库并没有新的数据写入（也就不会有新的binlog event时

间戳产生），但是由于计算公式中并不感知这个变化，所以随着从库的系统时钟继续向前推进，就会导致在追赶上主库的数据之

前，计算出的延迟时间值越来越大。

pt-heartbeat，下载通用二进制包

创建监控数据库：

mysql> create database monitor;
Query OK, 1 row affected (0.02 sec)

下载安装
./pt-heartbeat -D monitor --update -uroot -p oracle -P3306 -h 10.10.60.60 --create-table --daemonize

参数的意义：

• --update表示要实时更新时间戳的数据，这就是和之前的seconds_behind_master不同，seconds_behind_master并不是实时更新。

• --daemonize放到后台执行

• --create-table第一次需要创建heartbeat名的表。

  
  pt-heartbeat创建一个带有时间戳的表，并且因为是主从，这样表会复制到从上。
  

并且我们可以看到，每次查询的时候时间戳和position都是变化的，
备库上heartbeat表的ts列时间和主库heartbeat表中ts列的时间差就是主从复制的延迟时间
并且工具中还提供了monitor监控工具。

监控：

./pt-heartbeat -D monitor --monitor --master-server-id  603306 -uroot -p oracle -P3306 -h 10.10.60.60

看精确的看第一列，后几列分别为1min、5min、15min内的延迟时间。