在KingbaseES高可用集群中，物理备份是数据安全的重要防线。但当运维同学修改SSH默认端口后，不少用户发现原本稳定的sys_backup.sh备份工具突然罢工。本文将手把手带你突破这一运维困局，让备份流程重焕新生！
一、问题现场：SSH改端口引发的备份危机
某客户生产环境采用双节点集群架构（主节点node249，备节点node248），在将SSH端口从22调整为2222后，出现以下症状：
- 集群状态异常
sys_monitor.sh restart重启后，备节点出现WARNING: node248 is not attached to upstream - 物理备份中断
执行sys_backup.sh init初始化时，报错ssh: connect to host 192.168.7.248 port 22: Connection refused
诊断结论：
SSH端口变更后，集群管理工具repmgr与备份脚本sys_backup.sh仍使用旧端口通信，导致节点失联。
二、破局关键：三处配置同步改造
1. 集群通信改造 - repmgr.conf
# 修改所有节点的repmgr配置文件
vim ${KINGBASE_HOME}/etc/repmgr.conf
# 定位ssh_options参数，修改端口号
ssh_options='-q -o ConnectTimeout=10 -o StrictHostKeyChecking=no ... -p 2222' # 关键修改点2. 操作系统改造 - sshd_config
# 修改SSH服务端口（所有节点）
sudo vim /etc/ssh/sshd_config
# 取消Port注释，改为2222
Port 2222
# 重启服务
systemctl restart sshd
# 验证新端口连通性
ssh -p 2222 kingbase@node2483. 备份脚本改造 - sys_backup.sh
# 修改脚本中的SSH命令端口（重点修改两处）
# 修改位置1：_gene_ssh_pwd_less函数
function _gene_ssh_pwd_less() {
ssh -p 2222 -t ... # 追加端口参数
}
# 修改位置2：_ssh_cmd_变量定义
_ssh_cmd_="ssh -p 2222 -n -o ConnectTimeout=30 ..."三、避坑指南：三大常见故障排查
场景1：集群重启后节点失联
现象：repmgr cluster show显示备节点Upstream异常
解法：
- 检查repmgr.conf是否所有节点同步修改
- 执行sys_monitor.sh restart后观察VIP漂移日志
场景2：备份初始化卡在check stanza
现象：ERROR: check stanza failed
解法：
- 查看/tmp/sys_rman_check.log确认SSH连接错误
- 检查备份脚本中所有ssh命令是否已添加-p 2222
场景3：crontab定时任务失效
现象：手工执行备份成功，定时任务报错
解法：
- 在crontab命令中显式指定SSH端口
- bash
- 0 4 * * * ssh -p 2222 kingbase@node249 "/opt/backup.sh"
四、运维启示录
- 变更三板斧
涉及网络参数的变更，务必遵循 **"配置同步→服务重启→全链路验证"** 的黄金流程。 - 防御性编程
建议在备份脚本开头声明SSH端口变量，如SSH_PORT=2222，后续命令统一引用，提升可维护性。 - 监控闭环
改造完成后，重点监控： - 集群HA切换日志（hamgr.log）
- 备份任务状态（/tmp/sys_rman_*.log）
- 网络连通性（配置Zabbix对2222端口监控）
技术彩蛋
KingbaseES版本已支持在sys_backup.conf中通过ssh_port参数统一配置端口，彻底告别手动改脚本的烦恼！建议升级至最新版本获取更优体验。