使用pt-heartbeat监控主从复制延迟

    MySQL主从复制是MySQL 高可用架构中重要的组成部分,该技术可以用于实现负载均衡,高可用和故障切换,以及提供备份等等。对于主从复制的监控,仅仅依赖于MySQL自身提供的show slave status并不可靠。pt-heartbeat是主从复制延迟监控的不错选择,本文描述了主从复制情形下的延迟监控并给出相应示例。

    pt-heartbeat为percona-toolkit工具包中的一个,因此使用前需要先安装percona-toolkit,请参考:percona-toolkit的安装及简介

 

1、pt-heartbeat的作用
    pt-heartbeat measures replication lag on a MySQL or PostgreSQL server.  You can use it to update a master or monitor a replica.  If possible, MySQL connection options are read from your .my.cnf file.  For more details, please use the --help option, or try 'perldoc /usr/bin/pt-heartbeat' for complete  documentation.

    pt-heartbeat is a two-part MySQL and PostgreSQL replication delay monitoring system that measures delay by looking at actual replicated data. This avoids reliance on the replication mechanism itself, which is unreliable. (For example, SHOW SLAVE STATUS on MySQL).

 

2、pt-heartbeat的原理
    The first part is an --update instance of pt-heartbeat that connects to a master and updates a timestamp (“heartbeat record”) every --interval seconds. Since the heartbeat table may contain records from multiple masters (see “MULTI-SLAVE HIERARCHY”), the server’s ID (@@server_id) is used to identify records.
    主库上存在一个用于检查延迟的表heartbeat,可手动或自动创建
    pt-heartbeat使用--update参数连接到主库上并持续(根据设定的--interval参数)使用一个时间戳更新到表heartbeat
   
    The second part is a --monitor or --check instance of pt-heartbeat that connects to a slave, examines the replicated heartbeat record from its immediate master or the specified --master-server-id, and computes the difference from the current system time. If replication between the slave and the master is delayed or broken, the computed difference will be greater than zero and otentially increase if --monitor is specified.
    pt-heartbeat使用--monitor 或--check连接到从库,检查从主库同步过来的时间戳,并与当前系统时间戳进行比对产生一个差值,
    该值则用于判断延迟。(注,前提条件是主库与从库应保持时间同步)

    You must either manually create the heartbeat table on the master or use --create-table. See --create-table for the proper heartbeat table structure. The MEMORY storage engine is suggested, but not re-quired of course, for MySQL.
    The heartbeat table must contain a heartbeat row. By default, a heartbeat row is inserted if it doesn’t exist. This feature can be disabled with the --[no]insert-heartbeat-row option in case the database user does not have INSERT privileges.

    pt-heartbeat depends only on the heartbeat record being replicated to the slave, so it works regardless of the replication mechanism (built-in replication, a system such as Continuent Tungsten, etc). It works at any depth in the replication hierarchy; for example, it will reliably report how far a slave lags its master’s master’s master. And if replication is   stopped, it will continue to work and report (accurately!) that the slave is falling further and further behind the master.
    pt-heartbeat has a maximum resolution of 0.01 second. The clocks on the master and slave servers must be closely synchronized via NTP. By default, --update checks happen on the edge of the second (e.g. 00:01) and --monitor checks happen halfway between seconds (e.g. 00:01.5). As long as the servers’ clocks are closely synchronized and replication events are propagating in less than half a second, pt-heartbeat will report zero seconds of delay.
    pt-heartbeat will try to reconnect if the connection has an error, but will not retry if it can’t get a connection when it first starts.
    The --dbi-driver option lets you use pt-heartbeat to monitor PostgreSQL as well. It is reported to work well  with Slony-1 replication.

 

3、获取pt-heartbeat帮助信息
a、获取帮助信息
  [root@DBMASTER01 ~]# pt-heartbeat #直接输入pt-heartbeat可获得一个简要描述,使用pt-heartbeat --help获得一个完整帮助信息
  Usage: pt-heartbeat [OPTIONS] [DSN] --update|--monitor|--check|--stop
  
  Errors in command-line arguments:
    * Specify at least one of --stop, --update, --monitor or --check
    * --database must be specified

b、几个重要的参数
  Specify at least one of --stop, --update, --monitor, or --check. #至少指定一个
  --update, --monitor, and --check are mutually exclusive.         #互斥参数
  --daemonize and --check are mutually exclusive.                  #互斥参数
  
  --check
  Check slave delay once and exit. If you also specify --recurse, the tool will try to discover slave’s of the
  given slave and check and print their lag, too. The hostname or IP and port for each slave is printed before its
  delay. --recurse only works with MySQL.
  
  --daemonize
  Fork to the background and detach from the shell. POSIX operating systems only.

  --frames
  type: string; default: 1m,5m,15m
  Timeframes for averages.
  Specifies the timeframes over which to calculate moving averages when --monitor is given. Specify as a
  comma-separated list of numbers with suffixes. The suf?x can be s for seconds, m for minutes, h for hours, or d
  for days. The size of the largest frame determines the maximum memory usage, as up to the specified number
  of per-second samples are kept in memory to calculate the averages. You can specify as many timeframes as
  you like.
  
  --monitor
  Monitor slave delay continuously.
  Specifies that pt-heartbeat should check the slave’s delay every second and report to STDOUT (or if --file
  is given, to the file instead). The output is the current delay followed by moving averages over the timeframe
  given in --frames. For example,
  5s [ 0.25s, 0.05s, 0.02s ]
  
  --stop
  Stop running instances by creating the sentinel file.
  
  --update
  Update a master’s heartbeat.  

 

4、演示使用pt-heartbeat

a、首先添加表
[root@DBMASTER01 ~]# pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --create-table --update 

MASTER> select * from heartbeat;
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+
| ts                         | server_id | file             | position  | relay_master_log_file | exec_master_log_pos |
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+
| 2014-12-01T09:48:14.003020 |        11 | mysql-bin.000390 | 677136957 | mysql-bin.000179      |                 120 |
+----------------------------+-----------+------------------+-----------+-----------------------+---------------------+

b、更新主库上的heartbeat
[root@DBMASTER01 ~]# pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --update &
[1] 31249

c、从库上监控延迟
[root@DBBAK01 ~]# pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --monitor --print-master-server-id
1.00s [  0.02s,  0.00s,  0.00s ] 11  #实时延迟,1分钟延迟,5分钟延迟,15分钟延迟
1.00s [  0.03s,  0.01s,  0.00s ] 11  # Author : Leshami
1.00s [  0.05s,  0.01s,  0.00s ] 11  # Blog   : http://blog.csdn.net/leshami
1.00s [  0.07s,  0.01s,  0.00s ] 11
1.00s [  0.08s,  0.02s,  0.01s ] 11
1.00s [  0.10s,  0.02s,  0.01s ] 11
1.00s [  0.12s,  0.02s,  0.01s ] 11
1.00s [  0.13s,  0.03s,  0.01s ] 11

d、其他操作示例
#将主库上的update使用守护进程方式调度
[root@DBMASTER01 ~]# pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --update --daemonize

#修改主库上的更新间隔为2s
[root@DBMASTER01 ~]# pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --update --daemonize --interval=2

#停止主库上的pt-heartbeat守护进程
[root@DBMASTER01 ~]# pt-heartbeat --stop
Successfully created file /tmp/pt-heartbeat-sentinel
[root@DBMASTER01 ~]# rm -rf /tmp/pt-heartbeat-sentinel

#单次查看从库上的延迟情况
[robin@DBBAK01 ~]$ pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
> --master-server-id=11 --check
1.00

#使用守护进程监控从库并输出日志
[root@DBBAK01 ~]#  pt-heartbeat --user=root --password=xxx -S /tmp/mysql.sock -D test \
--master-server-id=11 --monitor --print-master-server-id --daemonize --log=/tmp/slave-lag.log
时间: 2024-12-02 07:59:16

使用pt-heartbeat监控主从复制延迟的相关文章

mysql主从复制延迟问题的相关知识与解决方案

                一.如何监控发生了主从延迟?   在从库机器上,执行show slave status,查看Seconds_Behind_Master值,代表主从同步从库落后主库的时间,单位为秒,若同从同步无延迟,这个值为0.   Mysql主从延迟一个重要的原因之一是:mysql是以单线程串行执行.   主从复制数据时,在从服务器上的mysql,是一个线程在同步数据. 串行的方式,它是指,执行一个后才继续执行下一个.如果一个卡住了,要等待时间,才会继续下一个.串行与并行是相反的

MySQL中slave监控的延迟情况分析_Mysql

在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟.这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态: 复制代码 代码如下: yejr@imysql.com [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting

深入mysql主从复制延迟问题的详解_Mysql

面试mysqldba的时候遇到一个题: 描述msyql replication 机制的实现原理,如何在不停掉mysql主库的情况下,恢复数据不一致的slave的数据库节点? MySQL的复制(replication)是一个异步的复制,从一个MySQL instace(称之为Master)复制到另一个MySQL instance(称之Slave).实现整个复制操作主要由三个进程完成的,其中两个进程在Slave(Sql进程和IO进程),另外一个进程在Master(IO进程)上. 引用新浪某位大牛的话

MySQL 主从延迟监控脚本(pt-heartbeat)

    对于MySQL数据库主从复制延迟的监控,我们可以借助percona的有力武器pt-heartbeat来实现.pt-heartbeat通过使用时间戳方式在主库上更新特定表,然后在从库上读取被更新的时间戳然后与本地系统时间对比来得出其延迟.本文主要是通过脚本来定期检查从库与主库复制的延迟度并发送邮件,供大家参考.     有关pt-heartbeat工具的安装可以参考:percona-toolkit的安装及简介    有关pt-heartbeat工具的介绍可以参考:使用pt-heartbea

当master down掉后,pt-heartbeat不断重试会导致内存缓慢增长的原因及解决办法_MsSql

最近同事反映,在使用pt-heartbeat监控主从复制延迟的过程中,如果master down掉了,则pt-heartbeat则会连接失败,但会不断重试. 重试本无可厚非,毕竟从使用者的角度来说,希望pt-heartbeat能不断重试,直到重新连接上数据库.但是,他们发现,不断的重试会带来内存的缓慢增长. 重现 环境: pt-heartbeat v2.2.19,MySQL社区版 v5.6.31,Perl v5.10.1,RHEL 6.7,内存500M 为了避免数据库启停对pt-heartbea

MySQL主从复制的延迟监测

主从复制延迟的监测,我以前的做法是通过比较show slave status\G中的两个变量的差值(Read_Master_Log_Pos,Exec_Master_Log_Pos),将差值设置为一个自己认为合理的范围,Seconds_Behind_Master 没有适用过,今天做一次解析: Seconds_Behind_Master 是通过比较 SQL THREAD 接受 events事件的时间戳(timestamp) 与IO THREAD  执行事件 events时间戳的差值--秒数来确定sl

使用pt工具检测MySQL主从延迟(r12笔记第7天)

 今天翻看了下<高性能MySQL>,真是让人拍手称绝,里面的很多实战思路非常不错,各种问题分析如数家珍,如果是有一定基础的同学,看起来会非常不错.    当然里面提到的一个地方,感觉很有意思,那就是主从延迟的一个测算思路.书中他们是通过建立一张表,插入时间相关的数据,值得一提的是这个表的存储引擎是Federated,主要就是为了完成类似Oracle DB link一样的特殊需求,在备库端来对比这个时间差来得到一个相对精准的延迟值.    当然有的同学可能会说,我们有show slave sta

MySQL中的主从复制一致性检测

在MySQL主从复制过程中,常常需要对某些重要的表进行一致性检查. 由于主从数据在同步时存在一定的延迟,因此直接读取服务器数据的方式无法严格保证信息的一致性.在数据在同步完全结束之前,一直处于不断变化且并不完整的状态下.锁表的可能实现这个问题,但是性能又是需要考虑的.能对数据验证是最好的.MySQL的CHECKSUM TABLE指令对于小型列表来说完全够用,但规模庞大的列表往往需要"分块"处理,避免在校验过程中造成负载过高. Percona工具Pt-table-checksum 是不锁

高可用架构-- MySQL主从复制的配置

环境 操作系统:CentOS-6.6-x86_64-bin-DVD1.iso MySQL版本:mysql-5.6.26.tar.gz 主节点IP:192.168.1.205     主机名:edu-mysql-01 从节点IP:192.168.1.206     主机名:edu-mysql-02 主机配置:4核CPU.4G内存   依赖课程 <高可用架构篇--第13节--MySQL源码编译安装(CentOS-6.6+MySQL-5.6)>   MySQL主从复制官方文档 http://dev.