mysql keepalive 脑裂_keepalived 预防脑裂检测脚本

最新推荐文章于 2024-09-10 16:38:12 发布
原创 最新推荐文章于 2024-09-10 16:38:12 发布 · 986 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#mysql keepalive 脑裂

本文介绍了一种针对Keepalived环境下脑裂现象的检测方法。通过部署脚本在备节点上持续监控VIP漂移情况，一旦发现VIP出现在备节点，则触发警告。此外，还提供了一个定时ping网关的脚本示例。

1 检查vip

[root@mysql2 keepalived]# cat /etc/keepalived/check_brain_keepalived.sh

#!/bin/bash

# 检查脑裂的脚本，在备节点上进行部署

LB01_VIP=*

LB01_IP=*

LB02_IP=*

while true

do

ping -c 2 -W 3 $LB01_VIP &>/dev/null

if [ $? -eq 0 -a `ip add|grep "$LB01_VIP"|wc -l` -eq 1 ];then

echo "ha is brain."

else

echo "ha is ok"

fi

sleep 5

done

运行脚本，在备节点(keepalived的备)，不是mysql的备节点

[root@mysql2 keepalived]# ./check_brain_keepalived.sh

ha is ok

ha is ok

由于在M-M+Keepalived环境中，脑裂是一个始终存在的问题，因为vip的存在，这里提供一个脚本进行检查，检查vip漂移到备节点

发现backup有vip就发警告，此脚本部署在backup机器上

2 定时ping网关的方法

[root@mysql1 keepalived]# /sbin/arping -I ens192 -c 5 -s * *

#!/bin/bash

host=127.0.0.1

CHECK_TIME=3

VIP=*

GATEWAY=*

eth=ens192

#mysql is working MYSQL_IS_OK is 1 , mysql down MYSQL_IS_OK is 0

keepalived_IS_OK=1

function check_keepalived_status (){

/sbin/arping -I $eth -c 5 -s $VIP $GATEWAY >/dev/null 2>&1

if [ $? = 0 ] ;then

keepalived_IS_OK=1

else

keepalived_IS_OK=0

fi

return $keepalived_IS_OK

}

while [ $CHECK_TIME -ne 0 ]

do

let "CHECK_TIME -= 1"

check_keepalived_status

if [ $keepalived_IS_OK = 1 ] ; then

CHECK_TIME=0

#/bin/systemctl stop keepalived

echo 1

exit 0

fi

if [ $keepalived_IS_OK -eq 0 ] && [ $CHECK_TIME -eq 0 ]

then

/bin/systemctl stop keepalived

echo 0

exit 1

fi

sleep 3

done

keepalived的脑裂问题

keepalived的脑裂问题 学习了:http://blog.51cto.com/10630401/2089847 split-brain 无HA不脑裂

keepalived 检测脑裂切换脚本

#!/bin/bash count=0 run1=`curl -I 192.168.30.12:8000 | grep "200 OK" | wc -l` run2=`curl - ...

split-brain 脑裂问题(Keepalived)

脑裂(split-brain)指在一个高可用(HA)系统中,当联系着的两个节点断开联系时,本来为一个整体的系统,分裂为两个独立节点,这时两个节点开始争抢共享资源,结果会导致系统混乱,数据损坏.对于无状 ...

解决keepalived脑裂问题

检测思路:正常情况下keepalived的VIP地址是在主节点上的,如果在从节点发现了VIP,就设置报警信息 脚本如下: #!/bin/bash # 检查脑裂的脚本,在备节点上进行部署 LB01_VI ...

Keepalived脑裂

问题描述:开启防火墙后,Keepalived出现脑裂. 背景架构:两台centos7通过Keepalived实现高可用 问题具体表现形式:两台主机通过ip addr (ip  a)查看,发现两台主机都 ...

keepalived脑裂问题查找

在自己环境做keepalived+redis实验时,当重启了备用redies机器后,发现两台redies主机都拿到了VIP [root@redis2 ~]# ip addr list 1: lo: & ...

记一次keepalived脑裂问题查找

在自己环境做keepalived+Redis实验时,当重启了备用redies机器后,发现两台redies主机都拿到了VIP [root@redis2 ~]# ip addr list 1: lo: & ...

keepalive脑裂的处理,从节点发现访问的虚拟IP就报警,同时尝试发送内容到主节点服务器关闭keepalive和nginx,或者关机

解决keepalived脑裂问题   检测思路:正常情况下keepalived的VIP地址是在主节点上的,如果在从节点发现了VIP,就设置报警信息 脚本如下: 1 2 3 4 5 6 7 8 9 10 ...

keepalive和脑裂问题

keepalive keepalive起初专门为lvs负载均衡软件设计的,用来管理监控lvs集群系统中各个服务节点的状态,后来又加入了可以实现高可用的vrrp功能. keepalive软件通过vrrp ...

随机推荐

loadrunner 的Administration Page页面设置

工作中用到Loadrunner不是很多,能够简单用用,深入的知识还得靠自己空余时自学.对于loadrunner 的Administration Page页面设置,我的理解是给自己设置各种障碍,然后一个 ...

洛谷P1738 洛谷的文件夹

原题目:点我 题目是一个略水的题,我机制地用面向对象做了...所以代码量急剧加大,100行233 模拟即可,字符串处理麻烦点.如果没有找到子文件夹就新建文件夹,如果有就进入该文件夹. 提示:高能,指针 ...

[JS] 面向对象的5种写法和拓展JS对象的写法

面向对象的JAVA  最开始当然是对象的定义了 收集了以下的五种写法 //第1种写法 function Circle(r) { this.r = r; } Circle.PI = 3.14159; C ...

使用NIO提升性能

NIO是New I/O的简称,与旧式的基于流的I/O方法相对,从名字看,它表示新的一套Java I/O标准. 具有以下特性: 传统Java IO,它是阻塞的,低效的.那么Java NIO和传统Java ...

nginx的优缺点

1.nginx相对于apache优点: 轻量级同样起web 服务比apache占用更少内存及资源 抗并发nginx 处理请求异步非阻塞而apache 则阻塞型高并发下nginx 能保持低资源低消耗高性 ...

javascript高级特性(面向对象)

javascript高级特性(面向对象): * 面向对象: * 面向对象和面向过程的区别: * 面向对象:人就是对象,年龄\性别就是属性,出生\上学\结婚就是方法. * 面向过程:人出生.上学.工作. ...

关于android:screenOrientation="portrait" 横竖屏切换

当在AndroidManifest.xml文件中定义了android:screenOrientation="portrait",就表示当我们切换横竖屏的时候,屏幕的内容始终以竖屏显 ...

C#获取设备的IP和Mac类

/// /// 此类用于获得设备的Ip和Mac /// public class Mac { [DllImport("Iph ...

SZU:A25 Favorite Number

Judge Info Memory Limit: 32768KB Case Time Limit: 10000MS Time Limit: 10000MS Judger: Number Only Ju ...

php定时执行操作及ob_flush()与flush()的使用

版权声明:本文为博主原创文章,未经博主允许不得转载. http://blog.youkuaiyun.com/qq_38125058 一: 每隔30s执行一次,将字符串写入文件 // 30秒执行一次 ignore_ ...

开发监测keepalived裂脑的脚本
baiqian1909的博客
10-05 417
检测思路：在备节点上执行脚本，如果可以ping通主节点并且备节点有VIP就报警，让人员介入检查是否裂脑。 在LB02备节点上开发脚本并执行： [root@lb02 ~]# cat /server/scripts/shell/check_split_brain.sh #!/bin/bash #Author:Mr.Ding #Created Time:2018-10-05 1...
keepalived脑裂和haproxy
cc2022928的博客
06-21 299
【代码】keepalived和haproxy。
keepalived 检测脑裂切换脚本
weixin_30716725的博客
05-23 478
#!/bin/bash count=0 run1=`curl -I 192.168.30.12:8000 | grep "200 OK" | wc -l` run2=`curl -I 192.168.30.12:8020 | grep "200 OK" | wc -l` run3=`curl -I 192.168.30.12:8080 | grep "200 OK" |...
检测keepalived脑裂的脚本
weixin_33813128的博客
11-22 330
检测思路：正常情况下keepalived的VIP地址是在主节点上的，如果在从节点发现了VIP，就设置报警信息 脚本如下： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 #!/bin/bash #检查脑裂的脚本，在备节点上进行部署...
keepalived产生脑裂的原因与解决方法
热门推荐
WanJiaBaoBao的博客
11-09 1万+
脑裂产生的原因 一般来说，裂脑的发生，有以下几种原因： 高可用服务器对之间心跳线链路发生故障，导致无法正常通信。 因心跳线坏了（包括断了，老化）。 因网卡及相关驱动坏了，ip配置及冲突问题（网卡直连）。 因心跳线间连接的设备故障（网卡及交换机）。 因仲裁的机器出问题（采用仲裁的方案）。 高可用服务器上开启了 iptables防火墙阻挡了心跳消息传输。 高可用服务器上心跳网卡地址等信息配置...
mysqlkeepalived脑裂
计算机毕业论文源码，学生个人网页制作html源码。贴近用户做网络推广和互联网优化。
11-17 366
mysql keepalive+ 双主多从是怎么做的 我们通常说的双机热备是指两台机器都在运行，但并不是两台机器都同时在提供服务。当提供服务的一台出现故障的时候，另外一台会马上自动接管并且提供服务，而且切换的时间非常短。MySQL双主复制，即互为Master-Slave(只有一个Master提供写操作)，可以实现数据库服...
keepalived脑裂监控
m0_56305656的博客
10-24 349
keepalived脑裂监控 1. 脑裂简介 在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上的HA软件像“裂脑人”一样，争抢“共享资源”、争起“应用服务”，就会发生严重后果——或者共享资源被瓜分、2边“服务”都起不来了；或者2边“服务”都起来了，但同时读写“共享存储”，导致数据损坏（常见如数据库轮询着的联机日志出错）。 　　 对付HA系统“裂脑”的对策，目前达成共识的的大概有以下几条
12.11keepalived脑裂、nginx优化
weixin_46837396的博客
04-05 668
一、keepalived 脑裂 1.脑裂的故障 2.脑裂模拟 1）开启防火墙 2）访问网站 3）关闭防火墙 3.脑裂解决的办法 二、高可用keepalived与nginx 1.nginx故障切换脚本 2.使用keepalived配置文件调用nginx切换脚本 1）配置抢占式时 2）配置非抢占式时 3.测试 Nginx常见问题 一、nginx多server优先级 1.准备多个配置文件 2.创建站点文件 3.访问测试 4.多server优先级总结 5.多server优先级总结验证 二、nginx禁止IP访问 1
keepalived-脑裂
Mzh_优快云的博客
08-06 528
keepalived-脑裂 文章目录keepalived-脑裂1. 什么是脑裂2. 脑裂产生的原因3. 脑裂的常见解决方案4. 对脑裂进行监控5. zabbix监控部署5.1 创建主机组5.2 创建监控主机5.3 添加模版5.4添加监控项5.5 添加触发器5.6 创建监控脚本5.7 添加媒介5.8 添加动作6. 监控测试 1. 什么是脑裂 在高可用（HA）系统中，当联系2个节点的“心跳线”断开时，本来为一整体、动作协调的HA系统，就分裂成为2个独立的个体。由于相互失去了联系，都以为是对方出了故障。两个节点上
centos 7 防止及解决keepalive脑裂现象（主备均有vip）
天涯的浪子
09-10 1123
最近在两台centos7机ARP表是一个动态表，存储在计算机当中，目的是做一个ip地址与mac地址的对应。假设在同一子网段，计算机A与计算机B通信计算机A的ip地址： 192.168.0.11 MAC地址AA-AA-AA-AA-AA-AA计算机B的ip地址： 已知192.168.0.12 MAC地址未知那么计算机A就要发起一个ARP查询，“谁能告诉我，192.168.0.12的MAC地址是多少？很显然通过交换机的时候，交换机并不能看懂ip地址，所以要广播这个信息，就把这个查询信息发到除发送端的其它所有端口。
keepalive应用脚本
05-05
包括主、从MySQL库，监视、主从切换shell脚本
Zabbix监控keepalived脑裂
itxiaoyu_lang的博客
06-22 372
Zabbix监控keepalived脑裂 环境 主机名 IP 安装 master 192.168.147.10 keepalived slave 192.168.147.66 keepalived、zabbix-agentd zabbix端 192.168.147.44 lamp、zabbix-server、zabbix-agentd VIP 192.168.147.100 安装 zabbix安装 keepalived安装 [root@za ~]# zabbix_serve
keepalived 预防脑裂检测脚本
weixin_30856725的博客
11-07 860
1 检查vip [root@mysql2 keepalived]# cat /etc/keepalived/check_brain_keepalived.sh #!/bin/bash # 检查脑裂的脚本，在备节点上进行部署 LB01_VIP=* LB01_IP=* LB02_IP=* while true do ping -c 2 -W 3 $LB01_VIP &...
keepalived一脚本监控裂脑问题
南风喃的博客
08-14 1339
1.什么是脑裂 2.裂脑发生的原因 3. 解决裂脑的常见方案 4.编写脚本监控脑裂 4.1测试两台高可用之间能否通 4.2查看VIP 4.3在管理端，执行脚本（管理端可以免秘钥操作两台高可用服务器） 4.4脚本内容 1.什么是脑裂 keepalived高可用的服务器之间出现ping不通，但服务器还在运行的状况，然后互相争抢资源。 2.裂脑发生的原因 a)高可用...
mysql脑裂_keepalived的脑裂问题
weixin_39836876的博客
12-23 945
1、什么是脑裂脑裂(split-brain)：指在一个高可用(HA)系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。对于无状态服务的HA，无所谓脑裂不脑裂；但对有状态服务(比如MySQL)的HA，必须要严格防止脑裂。2、解决keepalived脑裂问题检测思路：正常情况下keepalived的VIP地址是在...
keepalived MySQL 脑裂_keepalived 脑裂解决思路
weixin_33359523的博客
01-20 705
(主从模式)脑裂问题上述主从配置方式存在脑裂的可能，即两个节点实际都处于正常工作状态，但是无法接收到彼此的组播通知，这时两个节点均强行绑定虚拟IP，导致不可预料的后果。这时就需要设置仲裁，即每个节点必须判断自身的状态(应用服务状态及自身网络状态)，要实现这两点可使用自定义shell脚本实现，通过周期性地检查自身应用服务状态，并不断ping网关(或其它可靠的参考IP)均可。当自身服务异常、或无法pi...
说说Keepalived的脑裂
weixin_33919941的博客
03-17 297
1. 工作场景Keepalived提供了Loadbalancing和High-Availability的功能, 本文说的是其为2个Mycat节点提供HA功能的场景.2. 关键配置如下, 为主备非抢占模式.! mycat01, 192.168.4.196global_defs { # 一个keepalived.conf, 对应一个router_id router_i...
keepalived MySQL 脑裂_解决keepalived脑裂问题
weixin_35548251的博客
01-18 442
检测思路：正常情况下keepalived的VIP地址是在主节点上的，如果在从节点发现了VIP，就设置报警信息脚本如下：#!/bin/bash#检查脑裂的脚本，在备节点上进行部署LB01_VIP=10.10.10.229LB01_IP=10.10.10.129LB02_IP=10.10.10.130whiletruedoping-c2-W3$LB01_VIP&>/dev...
keepalive 检测脚本实现对多个实例master状态的检测
最新发布
08-23
<think>我们想要编写一个Keepalived检测脚本，用于监控多个Keepalived实例的Master状态。这个脚本的目标是定期检查每个配置的Keepalived实例（例如VI_1, VI_2等）的当前状态是否为MASTER，并根据检查结果进行一些操作（比如报警、日志记录等）。 注意：Keepalived本身提供了状态检测脚本的功能（通常用于检测服务的健康状态），但这里我们需要的是检测Keepalived实例自身的状态（即该节点当前是MASTER还是BACKUP状态）。 然而，Keepalived实例的状态信息通常可以通过以下方式获取： 1. 通过系统日志（/var/log/syslog或/var/log/messages）中查找。 2. 通过ipvsadm命令（但ipvsadm主要用于LVS状态，不直接反映VRRP实例状态）。 3. 通过查看Keepalived的运行时状态文件（如果配置了状态文件输出）或使用keepalived的套接字接口（如果启用）。 实际上，Keepalived在运行时会在内存中维护状态，我们可以通过配置vrrp_track_file或者使用keepalived的控制接口（通过unix域套接字）来获取状态。 但是，更简单的方法是利用Keepalived的notify机制将状态写入文件，然后我们的脚本读取这些文件来获取状态。 具体步骤： 方案一：利用notify机制将每个实例的状态写入单独的状态文件 在Keepalived配置文件中，为每个vrrp_instance配置notify_state（或者notify_master, notify_backup, notify_fault）脚本，将当前状态写入一个文件。 例如： vrrp_instance VI_1 { ... notify_master "/etc/keepalived/state.sh VI_1 MASTER" notify_backup "/etc/keepalived/state.sh VI_1 BACKUP" notify_fault "/etc/keepalived/state.sh VI_1 FAULT" } 然后，state.sh脚本可以这样写： #!/bin/sh echo $2 > /var/run/keepalived_$1.state 这样，每个实例的状态会被实时更新到对应的状态文件。 然后，我们编写一个检测脚本（比如check_keepalived_state.sh）来读取这些状态文件，检查每个实例的状态。 方案二：直接通过keepalived的套接字查询（需要启用控制接口） 在keepalived.conf中配置： vrrp_script check_keepalived_socket { script "[[ -S /var/run/keepalived.sock ]]" interval 2 } global_defs { enable_script_security script_user root vrrp_username root } vrrp_instance VI_1 { ... use_vmac [optional] vrrp_track_process [optional] } 然后，通过发送命令到套接字来查询状态。但这种方法比较复杂，需要解析返回的JSON。 考虑到简单性，我们采用方案一。 下面我们具体实现： 步骤1：修改keepalived配置文件，为每个实例添加notify状态脚本 步骤2：创建状态写入脚本（/etc/keepalived/state.sh） 步骤3：创建检测脚本（/etc/keepalived/check_keepalived_state.sh）来检查这些状态文件 注意：状态文件的位置，我们放在/var/run/目录下（因为该目录是内存文件系统，重启会丢失，但keepalived状态变化时会重新写入）。 检测脚本的目标： - 检查每个实例的状态是否为MASTER - 如果某个实例的状态不是MASTER（而是BACKUP或FAULT），则进行报警或记录日志（这里我们以日志为例） 下面我们编写脚本： 1. 状态写入脚本（/etc/keepalived/state.sh）： ```bash #!/bin/sh # 参数1：实例名称，参数2：状态 # 将状态写入文件 echo $2 > /var/run/keepalived_$1.state ``` 2. 检测脚本（/etc/keepalived/check_keepalived_state.sh）： ```bash #!/bin/bash # 定义要监控的实例列表 INSTANCES=("VI_1" "VI_2") # 根据实际情况修改 # 日志文件 LOG_FILE="/var/log/keepalived_state_check.log" # 当前时间 TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S') # 检查每个实例的状态 for INSTANCE in "${INSTANCES[@]}"; do STATE_FILE="/var/run/keepalived_${INSTANCE}.state" if [ -f "$STATE_FILE" ]; then STATE=$(cat "$STATE_FILE") if [ "$STATE" == "MASTER" ]; then echo "$TIMESTAMP [INFO] Instance $INSTANCE is MASTER." >> "$LOG_FILE" else echo "$TIMESTAMP [ERROR] Instance $INSTANCE is in $STATE state!" >> "$LOG_FILE" # 这里可以添加报警动作，比如发送邮件、短信等 fi else echo "$TIMESTAMP [ERROR] State file for $INSTANCE not found!" >> "$LOG_FILE" fi done ``` 3. 将检测脚本加入crontab，定期执行（比如每分钟一次）： 在crontab中添加： ```cron * * * * * /bin/bash /etc/keepalived/check_keepalived_state.sh ``` 4. 确保脚本有执行权限： ```bash chmod +x /etc/keepalived/state.sh chmod +x /etc/keepalived/check_keepalived_state.sh ``` 5. 重启keepalived服务使配置生效。 注意：如果系统重启，/var/run/目录下的状态文件会丢失，直到keepalived状态发生变化才会重新生成。因此，在keepalived启动时，我们可以通过notify_state在初始状态时写入文件。 在keepalived配置中，我们还可以使用： notify_state "/etc/keepalived/state.sh VI_1 $STATE" 但是，在旧版本中可能不支持notify_state，所以我们可以分别配置notify_master, notify_backup, notify_fault。 另外，在keepalived配置中，我们也可以使用notify_stop脚本，在keepalived停止时清理状态文件。 但是，为了简单，我们只使用notify_master, notify_backup, notify_fault。 补充：在keepalived配置文件中，每个实例的配置示例： ``` vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.1.100/24 } notify_master "/etc/keepalived/state.sh VI_1 MASTER" notify_backup "/etc/keepalived/state.sh VI_1 BACKUP" notify_fault "/etc/keepalived/state.sh VI_1 FAULT" # 如果keepalived停止，我们可以使用notify_stop来清除状态（可选） notify_stop "/etc/keepalived/state.sh VI_1 STOP" } ``` 这样，当实例状态变化时，状态文件就会被更新。 最后，我们的检测脚本会定期检查这些状态文件，并记录日志。 注意：如果某个实例的状态是BACKUP，这可能是正常的（因为同一时间只有一个MASTER），所以报警需要根据实际情况考虑。例如，我们可能只关心某个特定的实例是否成为MASTER，或者我们可能希望所有实例都应该是MASTER（在多个VIP独立漂移的情况下，但通常不会这样配置，因为多个实例通常在同一节点上同时为MASTER或BACKUP）。 因此，这个脚本的报警逻辑可以根据实际需求调整。比如，我们可能只关心某个关键实例（如VI_1）的状态，如果它不在MASTER状态就报警。 另外，在双主或者多主的配置中，可能每个实例的MASTER分布在不同的节点上，那么我们的报警逻辑就需要更加复杂，需要知道每个实例期望在哪个节点上是MASTER。 这里我们只实现了基本的状态监控和日志记录。 相关问题： 1. 如何配置Keepalived以实现多个VIP的联动漂移？ 2. Keepalived的健康检测脚本如何编写？ 3. 如何防止Keepalived脑裂？ 4. 在云环境中部署Keepalived有哪些注意事项？ 5. Keepalived与Docker或Kubernetes如何集成？</think>以下是一个用于监控多个Keepalived实例Master状态的检测脚本实现方案，结合引用内容中的关键点进行设计： ### 脚本功能说明 1. 实时监控多个Keepalived实例的Master状态 2. 当实例状态异常时自动记录日志 3. 支持自定义报警机制 4. 可集成到Keepalived健康检测系统中 ```bash #!/bin/bash # keepalived_multi_monitor.sh - 监控多个Keepalived实例的Master状态 # 用法：在keepalived配置中通过vrrp_script调用 # 配置需要监控的实例名称（与keepalived.conf中的vrrp_instance名称一致） INSTANCES=("VI_1" "VI_2" "VI_3") # 状态文件存储路径 STATUS_DIR="/var/run/keepalived" # 日志文件 LOG_FILE="/var/log/keepalived_status.log" # 创建状态目录 mkdir -p $STATUS_DIR # 检查实例状态函数 check_instance_status() { local instance=$1 local status_file="${STATUS_DIR}/${instance}.status" # 获取当前实例状态（通过keepalived状态文件） if [ -f "/tmp/keepalived.${instance}.status" ]; then current_state=$(awk '/^State/{print $2}' /tmp/keepalived.${instance}.status) else current_state="UNKNOWN" fi # 检查状态变化 if [ -f "$status_file" ]; then last_state=$(cat $status_file) if [ "$current_state" != "$last_state" ]; then log_status "状态变化: $instance 从 $last_state 变为 $current_state" echo $current_state > $status_file # 添加报警触发点（邮件/短信等） # send_alert "$instance 状态变化: $last_state → $current_state" fi else echo $current_state > $status_file log_status "初始状态: $instance = $current_state" fi # 验证Master状态 if [ "$current_state" == "MASTER" ]; then # 检查实际服务状态（示例：Nginx） if ! pgrep -x "nginx" >/dev/null; then log_status "WARNING: $instance 是MASTER但Nginx未运行!" return 1 fi return 0 else log_status "INFO: $instance 当前状态 $current_state" return 0 fi } # 日志记录函数 log_status() { echo "[$(date '+%Y-%m-%d %T')] $1" >> $LOG_FILE } # 主循环检查所有实例 for instance in "${INSTANCES[@]}"; do check_instance_status $instance # 如果检测失败可触发优先级调整（用于VIP漂移） if [ $? -ne 0 ]; then exit 1 # 返回非0触发keepalived优先级调整[^3][^4] fi done exit 0 ``` ### 配置步骤 1. **保存脚本** ```bash sudo nano /etc/keepalived/keepalived_multi_monitor.sh sudo chmod +x /etc/keepalived/keepalived_multi_monitor.sh ``` 2. **修改Keepalived主配置** 在`keepalived.conf`中添加： ```nginx vrrp_script chk_multi_instances { script "/etc/keepalived/keepalived_multi_monitor.sh" interval 3 # 每3秒检测一次 weight -20 # 检测失败时权重降低20[^3] } vrrp_instance VI_1 { ... track_script { chk_multi_instances } } vrrp_instance VI_2 { ... track_script { chk_multi_instances } } ``` 3. **启用状态文件**（可选） 在每个实例配置中添加： ```nginx vrrp_instance VI_1 { ... state_file "/tmp/keepalived.VI_1.status" } ``` ### 功能验证 ```bash # 手动测试脚本 sudo /etc/keepalived/keepalived_multi_monitor.sh # 查看日志 tail -f /var/log/keepalived_status.log # 模拟服务故障 sudo systemctl stop nginx # 观察日志和VIP漂移情况 ``` ### 关键特性说明 1. **多实例监控** 通过`INSTANCES`数组配置需要监控的实例名称，灵活扩展 2. **状态变化检测** 记录实例状态变化历史，避免频繁报警[^5] 3. **服务状态验证** 当实例处于MASTER状态时，自动验证实际服务（如Nginx）是否正常运行[^4] 4. **联动机制** 返回非0状态码触发Keepalived优先级调整，实现VIP漂移[^3] 5. **云环境适配** 通过权重调整而非直接停止服务，适应云环境限制[^5] --- ### 相关问题 1. Keepalived在MASTER节点服务恢复后如何避免VIP不回切？[^5] 2. 如何扩展此脚本以支持Kubernetes中的Keepalived部署？ 3. Keepalived与Nginx/Haproxy集成时有哪些最佳监控实践？[^2][^4] 4. 在跨机房部署中如何优化Keepalived的检测灵敏度？ 5. Keepalived的`nopreempt`参数在高可用场景中的实际作用是什么？[^5] [^1]: Keepalived集成了LVS功能和心跳检测能力 [^2]: 通过脚本实现Nginx存活检测可构建完整高可用方案 [^3]: 检测脚本需部署到所有节点并设置可执行权限 [^4]: Keepalived的价值依赖于实际服务的健康状态监控 [^5]: 在多个Master节点配置中需合理设置优先级和抢占策略
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值