client-reconfig-script 是 Redis Sentinel 官方唯一支持的故障转移后回调机制，用于在 failover 完成时执行自定义脚本，接收 master-name、role、state 等6个固定参数，实现 VIP 切换、DNS 更新等运维操作。
Redis哨兵模式本身不执行外部脚本，但可以通过 client-reconfig-script 配置项，在主从切换完成后，由 Sentinel 主动调用你指定的 shell 脚本 —— 这是唯一被官方支持的、用于响应 failover 事件的扩展机制。
client-reconfig-script 是什么，为什么必须用它
当 Sentinel 完成一次故障转移（failover），把某个 slave 提升为新 master，并让其余 slave 指向它后，会触发一次「重配置通知」。此时如果配置了 client-reconfig-script，Sentinel 就会在本地以子进程方式执行该脚本，并传入 6 个固定参数：master-name、role（old-master / new-master / slave）、state（start / end）、from-ip:port、to-ip:port、quorum。
这是 Sentinel 唯一暴露给用户的 hook 点；不用它，就无法在切换发生时自动做 VIP 切换、DNS 更新、服务注册下线等运维动作。
常见错误现象：
- 写了个脚本放在
/opt/redis/notify.sh，但没加client-reconfig-script mymaster /opt/redis/notify.sh这行配置 → 脚本永远不会被执行 - 脚本有语法错误或权限不足（比如没
chmod +x）→ Sentinel 日志里只报Failed to execute script，不输出具体错误 - 脚本执行时间超过 60 秒（Sentinel 默认超时）→ 被强制 kill，且不会重试
如何正确配置 client-reconfig-script
必须在每个 Sentinel 的 sentinel.conf 中显式声明，不能只配一个节点。配置格式为：
sentinel client-reconfig-script mymaster /path/to/your/script.sh
其中 mymaster 必须与 sentinel monitor 中定义的 master 名称完全一致。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
关键注意事项：
- 路径必须是绝对路径，不能用
~或相对路径 - 脚本文件需对运行 Sentinel 的用户（如
redis用户）可读可执行 - 脚本内不要依赖交互式环境（如
sudo、source ~/.bashrc），Sentinel 启动时用的是最小 shell 环境 - 建议开头加
#!/bin/bash -e，并用set -u防止未定义变量出错 - 日志务必重定向到文件（如
> /var/log/redis/failover.log 2>&1），否则看不到输出
脚本里能拿到哪些参数，怎么安全使用
Sentinel 会按顺序传入以下 6 个参数：
-
$1：master 名（如mymaster） -
$2：角色变化类型（old-master/new-master/slave） -
$3：事件阶段（start/end） -
$4：旧地址（如192.168.10.11:6379） -
$5：新地址（如192.168.10.12:6379） -
$6：当前参与投票的 Sentinel 数量（即 quorum 值）
典型用法示例（简化版）：
#!/bin/bash -e MASTER_NAME="$1" ROLE="$2" STATE="$3" OLD_ADDR="$4" NEW_ADDR="$5" <p>if [[ "$ROLE" == "new-master" && "$STATE" == "end" ]]; then echo "[$(date)] Failover completed: $OLD_ADDR → $NEW_ADDR" >> /var/log/redis/failover.log</p><h1>这里可以调用 keepalived CLI、curl 更新服务发现、发企业微信通知等</h1><p>/usr/local/bin/vip-switch.sh --activate "$NEW_ADDR" >> /var/log/redis/vip.log 2>&1 fi
注意：start 阶段只是开始选举，不代表切换成功；只有 end 阶段才代表配置已落地、所有 Sentinel 和从节点都已更新。别在 start 里做最终态操作。
容易被忽略的权限和调试细节
最常卡住的地方不是逻辑，而是环境权限：
- Sentinel 进程默认以
redis用户运行，脚本里若调用systemctl、ip、curl等命令，需确认该用户有对应权限（如sudoers白名单） - SELinux 开启时，可能阻止 Sentinel 执行外部脚本，临时验证可用
setenforce 0；长期方案是写 SELinux policy - 脚本中避免硬编码路径，优先用
$(dirname "$0")获取自身所在目录 - 调试时可在脚本开头加
env >> /tmp/sentinel-env.log查看实际运行环境变量 - 修改配置后必须重启 Sentinel（
kill -USR2不会重载此配置），且要确保所有 Sentinel 节点都配置一致，否则部分节点不会触发脚本
真正上线前，一定要手动模拟一次 failover（如 redis-cli -p 26379 sentinel failover mymaster），观察脚本是否被调用、参数是否正确、下游系统是否收到通知 —— 自动化链条里，最后一个环节往往最脆弱。
