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

标签: mysql 延迟 监控 | 发表时间:2014-12-08 05:59 | 作者:robinson_0612
出处:http://blog.csdn.net

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

    有关pt-heartbeat工具的安装可以参考: percona-toolkit的安装及简介
    有关pt-heartbeat工具的介绍可以参考: 使用pt-heartbeat监控主从复制延迟

 

1、脚本概述
   a、脚本定期使用--check方式单次检查当前的延迟性(定期的方式可以使用cron job比如每1分钟或5分钟)
   b、通过设定指定的延迟阀值来判断当时的延迟性是否在可控范围
   c、一旦当前的延迟大于指定阀值,则马上使用--monitor方式不停的监控其延迟性并写入到日志文件
   d、对于--monitor方式,其进程运行超过30分钟,自kill其进程,以避免无限期运行导致日志过大,空间不够用

 

2、脚本内容 

[mysql@SZDB run]$ more ck_slave_lag.sh 
#!/bin/bash
#set -x
if [ $# -ne 3 ];then
      echo "usage:"
      echo "ck_slave_lag.sh <Servier-id> <MaxLag> <LogDir>"
      exit 0;
fi

# Author : Leshami
# Blog   : http://blog.csdn.net/leshami

ServerID=$1
MaxLag=$2
LogDir=$3
Timestamp=`date +%Y%m%d_%H%M%S`
Rentition=7
LogFile=$LogDir/slave_lag_$Timestamp.log
LagDetail=$LogDir/slave_lag_Detail_$Timestamp.log
[email protected]

echo $ServerID
echo $MaxLag
echo $LogDir
echo $LogFile
echo $LagDetail
echo $mailadd

if [ ! -d $LogDir ];then
    mkdir -p $LogDir
fi

Lag=`/usr/bin/pt-heartbeat --user=monitor --password=xxx -S /tmp/mysql.sock -D test --master-server-id=$ServerID --check`
Lag=`echo ${Lag%.*}`
#Lag=3
echo $Lag
ptStatus=`ps -ef|grep pt-heart|grep daemonize`
echo $ptStatus

if [ $Lag -gt $MaxLag ]; then
    echo "The current date is `date` at `hostname`."          >>$LogFile 
    echo "The current lag log file is $LogFile."              >>$LogFile
    echo "The current replication lag is $Lag."               >>$LogFile
    echo "The replication lag is larger than max lag $MaxLag." >>$LogFile
   
    if [ -z "$ptStatus" ] ; then
        echo "Start a monitor daemon with below command: "        >>$LogFile 
        echo "pt-heartbeat --user=monitor --password=xxx -S /tmp/mysql.sock -D test " >>$LogFile
        echo " --master-server-id=11 --monitor --print-master-server-id --daemonize --log=$LagDetail" >>$LogFile
        /usr/bin/pt-heartbeat --user=monitor --password=xxx -S /tmp/mysql.sock -D test \
        --master-server-id=$ServerID --monitor --print-master-server-id --daemonize --log=$LagDetail
        echo "More detail please check lag log from $LagDetail." >>$LogFile
        cat $LogFile | mutt -s "Found slave lag on `hostname`." $mailadd
    fi
fi

if [ -n "$ptStatus" ] ; then
    STime=`ps -ef|grep pt-heart|grep daemonize |gawk '{print $5}'`
    Pid=`ps -ef|grep pt-heart|grep daemonize |gawk '{print $2}'`
    STime=`date '+%Y%m%d'`" "$STime
    s_STime=`date -d "$STime" '+%s'`
    s_ETime=`date +%s`
    DiffSec=`expr $s_ETime - $s_STime`

    echo $STime
    echo $s_STime
    echo $s_ETime
    echo $DiffSec

    if [ "$DiffSec" -gt 1800 ]; then
       echo "kill -9 $Pid"
       kill -9 $Pid
    fi
fi

# Remove history slave lag log.
find $LogDir -name "*slave_lag*" -ctime +$Rentition -delete 
exit

3、部署参考

[mysql@SZDB run]$ crontab -l

#check slave lag
*/1 * * * * /run/ck_slave_lag.sh 11 3 /log/SlaveLag
作者:robinson_0612 发表于2014-12-7 21:59:22 原文链接
阅读:96 评论:0 查看评论

相关 [mysql 延迟 监控] 推荐:

[MySQL FAQ]系列 — MySQL复制中slave延迟监控

- - MySQL中文网
在MySQL复制环境中,我们通常只根据 Seconds_Behind_Master 的值来判断SLAVE的延迟. 这么做大部分情况下尚可接受,但并不够准确,而应该考虑更多因素. 首先,我们先看下SLAVE的状态:. 可以看到 Seconds_Behind_Master 的值是 3296,也就是SLAVE至少延迟了 3296 秒.

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

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

relay fetch 解决mysql replication 主从延迟

- - CSDN博客推荐文章
      mysql replication 中主从延迟是一个比较常见的问题,请看前期一篇博文: 怎样解决MySQL数据库主从复制延迟的问题. 根据目前有些公司使用的方案,最近测试了两个,其中之一是阿里的relay fetch ,业绩说法数据预热,当然也有其他开源类似开源工具,目前诸如 mk-slave-prefetch及 replication-prefetch等,感兴趣可以去看看.

mysql监控工具:zabbix+MPM(Performance Monitor for MySQL)

- - CSDN博客数据库推荐文章
MPM主要用于监控mysql的各种参数性能指标,下面简单说一下他与zabbix的配置:. 下面是它的配置文件关系图. 1、zabbix 模板: Template_FromDual.MySQL.*.xml. 2、MPM agent perl 模块: FromDualMySQL*.pm. 下面是在linux 6.4下安装,先安装如下包:.

[MySQL优化案例]系列 — slave延迟很大优化方法

- - MySQL中文网
备注:插图来自网络搜索,如果觉得不当还请及时告知 :). 一般而言,slave相对master延迟较大,其根本原因就是slave上的复制线程没办法真正做到并发. 简单说,在master上是并发模式(以InnoDB引擎为主)完成事务提交的,而在slave上,复制线程只有一个sql thread用于binlog的apply,所以难怪slave在高并发时会远落后master.

MySQL主从复制延迟的监测及缓解

- - 数据库 - ITeye博客
MySQL的主从复制有多种原因可以导致延迟,这个是公认的了,下面我们谈谈怎样监测复制的延迟,以及怎样尽量的解决延迟的问题. 在SLAVE上执行SHOW SLAVE STATUS,监控Seconds_behind_master列值,备库Seconds_Behind_Master值是通过将服务器当前的时间戳(这里其实有个主从服务器时间差的问题,但是实际上主从在连接上后会做一次主从时间差的对比并记录该偏移量)与二进制日志中的事件时间戳相对比得到的,如果在I/O线程没有延时的情况下,这个还是准的.

意想不到的 MySQL 复制延迟原因

- - IT瘾-dev
线上有个MySQL实例,存在严重的复制延迟问题,原因出乎意料. 线上有个MySQL 5.7版本的实例,从服务器延迟了3万多秒,而且延迟看起来好像还在加剧. 我们看到, binlog文件落后了64个,相当的夸张. MySQL 5.7不是已经实现并行复制了吗,怎么还会延迟这么厉害. 看到 mysqld进程其实负载还好,不算太高,也不存在严重的SWAP等问题.

记一次 MySQL 主从复制延迟的踩坑

- - 文章 – 伯乐在线
最近开发中遇到的一个 MySQL 主从延迟的坑,记录并总结,避免再次犯同样的错误. 一个活动信息需要审批,审批之后才能生效. 因为之后活动要编辑,编辑后也可能触发审批,审批中展示的是编辑前的活动内容,考虑到字段比较多,也要保存审批活动的内容,因此设计采用了一张临时表,审批中的活动写进审批表(activity_tmp),审批通过之后才把真正的活动内容写进活动表(activity).

彻底终结MySQL同步延迟问题 - 简书

- -
作为一名DBA,在工作中会经常遇到一些MySQL主从同步延迟的问题,这些同步慢的问题,其实原因非常多,可能是因为主从的网络问题导致,可能是因为网络带宽问题导致,可能是因为大事务导致,也可能是因为单线程复制导致的延迟. 最近遇到一个很典型的同步延迟问题,将分析过程写出来,希望对广大DBA在排查同步延迟问题有比较系统的方法论.

如何发现并处理MySQL主从延迟问题

- -
在 Percona MySQL 支持团队中,我们经常看到客户抱怨复制延迟的问题. 当然,这对 MySQL 用户来说并不是什么新鲜事,多年来我们在 MySQL 性能博客上发表过一些关于这个主题的文章(过去有两篇特别受欢迎的文章:"Reasons for MySQL Replication Lag" 和 “Managing Slave Lag with MySQL Replication"),两篇文章均由 Percona 首席执行官 Peter Zaitsev 撰写).