seconds_behind_master含义及不足

seconds_behind_master的值是通过将salve服务器当前的时间戳与二进制日志中的事件的时间戳相比得到的，所以只有执行事件时才会报告延迟。

1.1 如果备库复制线程没有运行，就会报延迟为null。

1.2 一些错误比如网络不稳定可能导致复制中断或停止复制线程，但是seconds_behind_master将显示为0，而不是显示错误

1.3 即使备库线程正在运行，备库有时候可能无法计算延时，如果发生这种情况，备库会报0或者null。

1.4 一个大事务可能会导致延迟波动，例如一个事务更新数据长达1个小时，最后提交。这条更新语句将比它实际发生时间要晚一个小时才记录到二进制日志中，当备库执行这条语句时，会临时报告备库延迟1小时，然后又很快变为0。

详细请参考<高性能MySQL 复制章节>

pt-heartbeat原理

改进的做法就是使用percona toolkit工具包的pt-heartbeat，工作原理如下：

2.1 在master上创建一张heartbeat表，按照一定的时间频率更新该表的字段，主要就是向该表写入当前的时间戳

2.2 连接到slave上检查该表的时间记录，和运行pt-heartbeat的当前系统时间进行比较，得出时间的差异，这个时间差异就是复制延迟

注1：这里的2中的系统时间并不一定是slave的系统时间，如果pt-heartbeat的复制监控脚本运行在master上，那么当前系统时间就是master的当前系统时间，这时就不需要严格同步master服务器和slave服务器的时间一致了。

注2：这里的创建的heartbeat表必须在复制同步下的库，有些教材都写了test库，但有时我们在复制配置中过滤了test库的复制，需要注意这一点

pt-heartbeat参数说明

pt-heartbeat用法格式如下，详细的用法可运行pt-heartbeat --help查看，最主要的几个参数介绍如下

Usage: pt-heartbeat [OPTIONS] [DSN] --update|--monitor|--check|--stop

--update|--monitor|--check|--stop这四个参数必须选一个且仅选一个，--update表示每隔默认的秒数更新master库上heartbeat表的时间戳，--monitor表示每隔默认秒都监控延迟状况，--check表示只监控一次就退出，--stop表示停止更新时间戳的进程

--daemonize 后台执行

--file 【--file=output.txt】打印--monitor最新的记录到指定的文件，很好的防止满屏幕都是数据的烦恼。

--frames 【--frames=1m,2m,3m】在--monitor里输出的[]里的记录段，默认是1m,5m,15m。可以指定1个，如：--frames=1s，多个用逗号隔开。

--interval 检查、更新的间隔时间。默认是见是1s。最小的单位是0.01s，最大精度为小数点后两位，因此0.015将调整至0.02。

--log 开启daemonized模式的所有日志将会被打印到制定的文件中。

--monitor 持续监控从的延迟情况

--master-server-id 指定主的server_id

--recurse 多级复制的检查深度。模式M-S-S...不是最后的一个从都需要开启log_slave_updates，这样才能检查到。

pt-heartbeat监控复制延迟及测试

典型的步骤如下

4.1 在master服务器上运行如下命令，这里的ip，user等信息均为master mysql的信息。

pt-heartbeat -D mydb --update -uroot -p 123456 -P 3306 -h 127.0.0.1 --create-table --daemonize

4.2 在master服务器上运行如下命令，这里的ip，user等信息均为slave mysql的信息，然后指定该master-server-id，

pt-heartbeat -D mydb --monitor -u y -p 123456 -P 3306 -h 10.0.11.244 --master-server-id 101

4.3 这时我们在master上插入大量数据，比如一个insert into select，可看到监控界面上延迟值越来越大最后又慢慢变小，具体测试代码略。

4.4 这时我们在slave上stop slave，观察复制延迟情况，可看到延迟越来越大

4.5 这时我们重新start slave，可观察到延迟再次变小

你可能感兴趣的文章