pt-heartbeat使用实践记录

共计 4506 个字符，预计需要花费 12 分钟才能阅读完成。

使用 pt-heartbeat 这个工具检测主从延迟时间，决定自己使用 pt-heartbeat 这个工具，顺便在此记录一下。

工作原理：

1，在主上创建一张 heartbeat 表，按照一定的时间频率更新该表的字段（把时间更新进去）。

2，连接到从上检查复制的时间记录，和从库的当前系统时间进行比较，得出时间的差异。

使用方法：

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

在主库上开启守护进程来更新 linuxidc.heartbeat 表：

pt-heartbeat -D linuxidc --update -h master-server --daemonize

监控从的延迟情况：

pt-heartbeat -D linuxidc --monitor -h slave-server   #一直执行，不退出
pt-heartbeat -D linuxidc--check h=slave-server       #执行一次就退出

常用参数：

注意：需要指定的参数至少有 --stop，--update，--monitor，--check。其中 --update，--monitor 和 --check 是互斥的，--daemonize 和 --check 也是互斥。--ask-pass
隐式输入 MySQL 密码

--charset
字符集设置

--check
检查从的延迟，检查一次就退出，除非指定了--recurse 会递归的检查所有的从服务器。--check-read-only
如果从服务器开启了只读模式，该工具会跳过任何插入。--create-table
在主上创建心跳监控的表，如果该表不存在。可以自己建立，建议存储引擎改成 memory。通过更新该表知道主从延迟的差距。CREATE TABLE heartbeat (ts                    varchar(26) NOT NULL,
  server_id             int unsigned NOT NULL PRIMARY KEY,
  file                  varchar(255) DEFAULT NULL,    -- SHOW MASTER STATUS
  position              bigint unsigned DEFAULT NULL, -- SHOW MASTER STATUS
  relay_master_log_file varchar(255) DEFAULT NULL,    -- SHOW SLAVE STATUS
  exec_master_log_pos   bigint unsigned DEFAULT NULL  -- SHOW SLAVE STATUS
);
heratbeat 表一直在更改 ts 和 position, 而 ts 是我们检查复制延迟的关键。--daemonize
执行时，放入到后台执行

--user
-u，连接数据库的帐号

--database
-D，连接数据库的名称

--host
-h，连接的数据库地址

--password
-p，连接数据库的密码

--port
-P，连接数据库的端口

--socket
-S，连接数据库的套接字文件

--file【--file=output.txt】打印--monitor 最新的记录到指定的文件，很好的防止满屏幕都是数据的烦恼。--frames【--frames=1m,2m,3m】在 --monitor 里输出的[] 里的记录段，默认是 1m,5m,15m。可以指定 1 个，如：--frames=1s，多个用逗号隔开。可用单位有秒（s）、分钟（m）、小时（h）、天（d）。--interval
检查、更新的间隔时间。默认是见是 1s。最小的单位是 0.01s，最大精度为小数点后两位，因此 0.015 将调整至 0.02。--log
开启 daemonized 模式的所有日志将会被打印到制定的文件中。--monitor
持续监控从的延迟情况。通过--interval 指定的间隔时间，打印出从的延迟信息，通过 --file 则可以把这些信息打印到指定的文件。--master-server-id
指定主的 server_id，若没有指定则该工具会连到主上查找其 server_id。--print-master-server-id
在--monitor 和 --check 模式下，指定该参数则打印出主的 server_id。--recurse
多级复制的检查深度。模式 M -S-S... 不是最后的一个从都需要开启 log_slave_updates，这样才能检查到。--recursion-method
指定复制检查的方式, 默认为 processlist,hosts。--update
更新主上的心跳表。--replace
使用--replace 代替 --update 模式更新心跳表里的时间字段，这样的好处是不用管表里是否有行。--stop
停止运行该工具（--daemonize），在 /tmp/ 目录下创建一个“pt-heartbeat-sentinel”文件。后面想重新开启则需要把该临时文件删除，才能开启（--daemonize）。--table
指定心跳表名，默认 heartbeat。

测试环境：

Master  192.168.0.10:3306
Slave   192.168.0.20:3306

1，在主上运行：–daemonize表示守护进程，后台运行。

[root@linuxidc_192.168.0.10 ~]# pt-heartbeat --user=root --ask-pass --host=127.0.0.1 --create-table -D linuxidc --interval=1 --update --replace --daemonize
Enter password: 
[root@linuxidc_192.168.0.10 ~]#

[root@linuxidc_192.168.0.10 ~]# pgrep -fl pt-heartbeat
4156 perl /usr/bin/pt-heartbeat -D linuxidc --table=heartbeat --create-table --update -h 127.0.0.1 -uroot --ask-pass --daemonize
[root@linuxidc_192.168.0.10 ~]#

3.在主上运行监测复制延迟

[root@linuxidc_192.168.0.10 ~]# pt-heartbeat -D linuxidc --table=heartbeat --monitor -h 192.168.0.20
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.00s [0.00s,  0.00s,  0.00s ]

0 表示从没有延迟。[ 0.00s, 0.00s, 0.00s ] 表示 1m,5m,15m 的平均值。可以通过–frames 去设置。

我们这里看见复制没有延迟，那么我们可以使用压力工具测试一下。在主库创建测试数据库 sbtest；

mysql> create database sbtest;
Query OK, 1 row affected (0.00 sec)

mysql>

开始生成 100w 记录的数据

[root@linuxidc_192.168.0.10 ~]#  sysbench --test=oltp --oltp-table-size=1000000 --oltp-read-only=off --init-rng=on --num-threads=16 --max-requests=0 --oltp-dist-type=uniform --max-time=1800 --mysql-user=root --mysql-socket=/tmp/mysqld.sock --mysql-password=123456 --db-driver=mysql --mysql-table-engine=innodb --oltp-test-mode=complex prepare
sysbench 0.4.10:  multi-threaded system evaluation benchmark

Creating table 'sbtest'...
Creating 1000000 records in table 'sbtest'...

再次检测复制延时：

[root@linuxidc_192.168.0.10 ~]# pt-heartbeat -D linuxidc --table=heartbeat --monitor -h 192.168.0.20
28.21s [0.47s,  0.09s,  0.03s ]
28.72s [0.95s,  0.19s,  0.06s ]
29.38s [1.44s,  0.29s,  0.10s ]
29.13s [1.92s,  0.38s,  0.13s ]
30.85s [2.44s,  0.49s,  0.16s ]
31.04s [2.96s,  0.59s,  0.20s ]
29.84s [3.45s,  0.69s,  0.23s ]
31.24s [3.97s,  0.79s,  0.26s ]
32.20s [4.51s,  0.90s,  0.30s ]
32.96s [5.06s,  1.01s,  0.34s ]
33.82s [5.62s,  1.12s,  0.37s ]
34.15s [6.19s,  1.24s,  0.41s ]

立马发现效果了哦 ^_^

我们还可以使用 –check 监测一次就退出:

[root@linuxidc_192.168.0.10 ~]# pt-heartbeat -D linuxidc --table=heartbeat --check -h 192.168.0.20
0.00
[root@linuxidc_192.168.0.10 ~]#

2，如何关闭主上面执行的后台进程。可以用参数 –stop 去关闭：

[root@linuxidc_192.168.0.10 ~]# pt-heartbeat --stop
Successfully created file /tmp/pt-heartbeat-sentinel
[root@linuxidc_192.168.0.10 ~]#

这样就把在主上开启的进程杀掉了，后续要继续开启后台进行的话，需要把/tmp/pt–heartbeat–sentinel 文件删除，否则启动不了。

总结：

通过 pt-heartbeart 工具可以很好的弥补默认主从延迟的问题，但需要搞清楚该工具的原理。而默认的 Seconds_Behind_Master 值是通过将服务器当前的时间戳与二进制日志中的事件时间戳相对比得到的，所以 只有在执行事件时才能报告延时 。备库 复制线程没有运行 ，也会报延迟 null。还有一种情况： 大事务，一个事务更新数据长达一个小时，最后提交。这条更新将比它实际发生时间要晚一个小时才记录到二进制日志中。当备库执行这条语句时，会临时地报告备库延迟为一个小时，执行完后又很快变成 0。

更多详细资料请参考：

http://www.percona.com/doc/percona-toolkit/2.1/pt-heartbeat.html

本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-09/135586.htm