在mysql的主备架构中,我们很关心的一种情况是,备库到底落后了主库多少,因为只有知道了具体的情况,我们才能知道当前系统的复制是否正常。如果一个在主上插入的数据,可能要等到上分钟后才能在从库插入,那这样的设计肯定是有问题的。在备库上执行show slave status\G;可以看到其中有一列为Seconds_Behind_Master,这个值理论上显示出了备库的延时,但是他不准确,比如在我的实验环境下大量并发插入数据的时候Seconds_Behind_Master的值一直为0。
原因如下:(这里借用High performance mysql一书中的原文)
首先要在主服务器下创建一个定期更新heartbeat表的命令如下:
/usr/local/bin/pt-heartbeat -D test --update -u mysql -p 123456 -P 3306 -h 192.168.1.106 --create-table --daemonize
参数说明如下:-D 需要监控的数据库,--update会在指定的时间更新一个时间戳,-u 用户,-p 密码 -P端口 -h 主机 --create-table自动生成heartbeat表,--daemonize在后台运行
/usr/local/bin/pt-heartbeat -D test --monitor -u mysql -p 123456 -P 3306 -h 192.168.1.111
参数说明:--monitor会连接到从上检查复制的心跳记录,并且与当前的时间相比,得出复制的延迟,-h是备库的地址
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
0.00s [ 0.00s, 0.00s, 0.00s ]
因为此时没有往主库中添加数据,备库不需要更新,所以一直为0。现在新开一个端口,往主库中插入大量数据的时候
2.06s [ 0.13s, 0.03s, 0.01s ]
2.16s [ 0.16s, 0.03s, 0.01s ]
0.18s [ 0.16s, 0.03s, 0.01s ]
1.52s [ 0.19s, 0.04s, 0.01s ]
2.03s [ 0.22s, 0.04s, 0.01s ]
可以看到备库已经有了明显的延迟
/usr/local/mysql/bin/mysqlbinlog --no-defaults /data/mysql/mysql-bin.000010 | tail -n 30
BEGIN