在KingbaseES高可用集群中，物理备份是数据安全的重要防线。但当运维同学修改SSH默认端口后，不少用户发现原本稳定的sys_backup.sh备份工具突然罢工。本文将手把手带你突破这一运维困局，让备份流程重焕新生！

一、问题现场：SSH改端口引发的备份危机

某客户生产环境采用双节点集群架构（主节点node249，备节点node248），在将SSH端口从22调整为2222后，出现以下症状：

1. 集群状态异常
   sys_monitor.sh restart重启后，备节点出现WARNING: node248 is not attached to upstream
2. 物理备份中断
   执行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@node248

3. 备份脚本改造 - 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"

四、运维启示录

1. 变更三板斧
   涉及网络参数的变更，务必遵循 **"配置同步→服务重启→全链路验证"** 的黄金流程。
2. 防御性编程
   建议在备份脚本开头声明SSH端口变量，如SSH_PORT=2222，后续命令统一引用，提升可维护性。
3. 监控闭环
   改造完成后，重点监控：
4. 集群HA切换日志（hamgr.log）
5. 备份任务状态（/tmp/sys_rman_*.log）
6. 网络连通性（配置Zabbix对2222端口监控）

技术彩蛋
KingbaseES版本已支持在sys_backup.conf中通过ssh_port参数统一配置端口，彻底告别手动改脚本的烦恼！建议升级至最新版本获取更优体验。