nagios 实现Mysql 主从同步状态的监控

一、系统环境


主机名


IP


nagios


192.168.15.111


mysql_s


192.168.15.21

二、操作步骤

2.1 mysql_s端的配置

2.1.1 编写check_mysql_slave监控脚本

cd /usr/local/nagios/libexec   #切换到nagios
监控插件所在目录

vim check_mysql_slave       #开始编写mysql_slave监控脚本

注意:监控脚本中的mysql账户一定要新建一个,并设置有限的权限。

 

2.1.2 给脚本增加可执行权限

chmod 755 check_mysql_slave

-rwxr-xr-x   1 root root        471 Oct 16 12:59 check_mysql_slave

2.1.3编辑nrpe的配置文件

vim  /usr/local/nagios/libexec/etc/nrpe.cfg +204

#添加监控mysql 主从同步状态的命令

command[check_mysql_slave]=/usr/local/nagios/libexec/check_mysql_slave

2.1.4重新启动 nrpe 服务

2.1.5执行脚本测试输出

[[email protected]_s  libexec]#  ./check_mysql_slave

OK mysql_s  is running

2.2  nagios端的配置:

2.2.1 修改已有的 /usr/local/nagios/etc/objects/service.cfg 配置文件

define service {

use                                          generic-service

host_name                            mysql_slave

service_description            check_21_mysql_replication_status

check_command                 check_nrpe!check_mysql_slave

max_check_attempts          3

normal_check_interval        2

retry_check_interval             2

check_period                        24x7

notification_interval             10

notification_period                24x7

notification_options            w,u,c,r

contact_groups                   admins

process_perf_data            1

}

2.2.2重启 nagios

[[email protected] objects]#/etc/init.d/nagios  checkconfig  #检查配置文件是否有误

[[email protected] objects]#/etc/init.d/nagios  reload           
#重新加载配置文件

Running configuration check...done.

Stopping nagios: done.

Starting nagios: done.

说明:如果nagios reload完毕,监控页面尚未出现检测结果,可以手动测试

/usr/local/nagios/libexec/check_nrpe -H192.168.15.21 -c check_mysql_slave

2.2.3 最终效果图

时间: 2024-08-27 14:20:54

nagios 实现Mysql 主从同步状态的监控的相关文章

监控mysql主从同步状态是否异常,如果异常,则发生短信或邮寄给管理员

阶段1:开发一个守护进程脚本每30秒实现检测一次. 阶段2:如果同步出现如下错误号(1158,1159,1008,1007,1062),请跳过错误 阶段3:请使用数组技术实现上述脚本(获取主从判断及错误号部分) [[email protected] ~]# mysql -u root -proot -e "show slave status\G;" *************************** 1. row ***************************       

MySQL主从同步状态

因为mysql的slave报错,导致slave落后master很远.找资料查看同步状态. 引用 mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.0.103 Master_User: root Master_Port: 3306

监控MySQL主从同步状态

1.       [[email protected] mysql]# cat check_slave_status.sh 2.       #!/bin/sh 3.       #-------------------------------------------- 4.       #Author: Created by randolph 2016-08-17. 5.       #Function: This scripts function is"Monitoring MySQL Ma

监控docker容器内mysql主从同步状态

Docker exec 命令docker exec :在运行的容器中执行命令语法docker exec [OPTIONS] CONTAINER COMMAND [ARG...]OPTIONS说明:-d :分离模式: 在后台运行-i :即使没有附加也保持STDIN 打开-t :分配一个伪终端 脚本cat /server/scripts/mysql.sh #!/bin/bashdocker exec -t docke_mysql mysql -uroot -p123456 -e "show slav

MySQL主从同步状态监控脚本及邮件通知

网络版本 #!/bin/bash mysql_cmd="mysql -u root -pxxxxxxxxx" errorno=(1158 1159 1008 1007 1062) while true do array=($($mysql_cmd -e "show slave status\G"|egrep '_Running|Behind_Master|Last_SQL_Errno'|awk '{ print $NF }')) if [ "${array

监控MYSQL主从同步配置中监控从库运行状态的脚本

代码如下: [java] view plain copy #!/bin/bash #Check MySQL Slave's Runnning Status #Crontab time 00:10 MYSQLPORT=`netstat -na|grep "LISTEN"|grep "3306"|awk -F[:" "]+ '{print $5}'` MYSQLIP=`ifconfig eth0|grep "inet addr" 

mysql主从同步(4)-同步延迟状态考量(seconds_behind_master和pt-heartbea)

一般情况下,我们是通过"show slave status \G;"提供的Seconds_Behind_Master值来衡量mysql主从同步的延迟情况.具体说明见:mysql主从同步(4)-Slave延迟状态监控,这种方法在大多数情况下确实是可行的.但是经验告诉我,仅仅依靠Seconds_Behind_Master的值来监测主从同步数据是否延迟是绝对不可靠的!!! 曾经遇到过的一个坑:Mysql主从环境部署后,刚开始主从数据同步是没问题的,也是通过监控Seconds_Behind_M

监控MySQL主从同步

脚本监控数据库主从同步 来源:http://oldboy.blog.51cto.com/2561410/1632876 来源: (生产实战案例):监控MySQL主从同步是否异常,如果异常,则发送短信或者邮件给管理员.提示:如果没主从同步环境,可以用下面文本放到文件里读取来模拟: 阶段1:开发一个守护进程脚本每30秒实现检测一次. 阶段2:如果同步出现如下错误号(1158,1159,1008,1007,1062),则跳过错误. 阶段3:请使用数组技术实现上述脚本(获取主从判断及错误号部分 [[em

mysql主从同步(3)-percona-toolkit工具(数据一致性监测、延迟监控)使用梳理

转自:http://www.cnblogs.com/kevingrace/p/6261091.html 在mysql工作中接触最多的就是mysql replication mysql在复制方面还是会有一些常规问题: 比如主库宕机或者从库宕机有可能会导致复制中断,通常需要进行人为修复, 或者很多时候需要把一个从库提升为主库,但对从库和主库的数据一致性不能保证一样. 这种情况下就需要使用percona-toolkit工具的pt-table-checksum组件来检查主从数据的一致性:如果发现不一致的