KingbaseES集群failover失败案例分析与解决方案

1. 案例背景与问题描述最近在维护一套KingbaseES V8R3数据库集群时遇到了一次典型的failover切换失败案例。这套集群采用标准的主备架构主库运行在node209192.168.103.209备库在node210192.168.103.210。故障发生时主库的data目录突然变为只读状态触发了自动failover流程但最终切换却失败了。问题的核心在于当主库检测到存储异常后虽然正确触发了failover流程但在切换过程中由于SSH连接问题导致VIP192.168.103.211无法成功转移到新主库最终使得整个高可用切换功亏一篑。这种故障在数据库集群运维中非常典型也极具警示意义。2. 故障时间线还原2.1 主库异常触发时间点通过分析主库的recovery.log可以清晰看到故障的起始点2023-10-15 07:57:01 recover beging... could not create/write the file /home/kingbase/cluster/clusterdb/db/data/rw_status_file_714111580 unlink: 无法清除/home/kingbase/cluster/clusterdb/db/data/rw_status_file_714111580 的链接: 只读文件系统关键点在于主库定期检查存储可写性时发现无法创建测试文件由于use_check_diskon的配置系统自动触发保护机制经过多次重试后08:01:01系统判定存储故障开始关闭数据库服务经验提示生产环境中use_check_disk参数建议保持开启虽然可能产生误报但能有效防止数据损坏。同时rw_status_file的检查间隔默认为60秒可根据业务需求调整。2.2 备库检测与failover触发备库的cluster.log记录了故障检测过程2023-10-15 07:57:21: pid 47108: LOG: failed to connect to kingbase server on 192.168.103.209:62163 2023-10-15 07:57:57: pid 47108: LOG: health checking retry count 10 2023-10-15 07:57:57: pid 47108: LOG: setting backend node 0 status to NODE DOWN这里有几个关键参数需要注意连接重试次数10次默认值检测间隔约3秒一次总检测时间约36秒从07:57:21到07:57:573. 核心故障点分析3.1 SSH连接失败的根本原因在failover.log中我们看到了最关键的报错2023-10-15 08:01:47 add VIP on 192.168.103.210 the new primary can not ssh, exit failover深入查看备库的recovery.log发现更早之前就存在SSH问题ssh -o StrictHostKeyCheckingno -l root -T localhost /sbin/ip addr | grep -w 192.168.103.211/28 | wc -l execute failed经过排查发现根本原因是备库节点的SSH服务配置存在问题导致localhost连接自身都失败集群的VIP转移机制依赖SSH执行远程命令由于长期未进行failover测试该问题一直未被发现3.2 VIP转移机制详解KingbaseES集群的VIP转移流程大致如下确认新主库身份node210通过SSH连接到旧主库node209执行停止数据库服务删除VIPip addr del通过SSH连接到新主库node210执行添加VIPip addr add启动数据库服务这个过程中的每个SSH连接都需要配置免密登录且要求root权限。在本案例中由于备库节点自身SSH连接就有问题导致整个流程在最后一步失败。4. 问题排查与解决方案4.1 诊断SSH连接问题通过以下步骤可以诊断SSH配置问题检查SSH服务状态systemctl status sshd测试本地SSH连接ssh -v rootlocalhost检查认证日志tail -f /var/log/auth.log在本案例中发现是SELinux策略阻止了root用户的本地SSH连接。4.2 解决方案实施临时解决方案不推荐setenforce 0永久解决方案# 修改SELinux策略 semanage boolean --modify --on ssh_root # 或者添加自定义策略 ausearch -c sshd --raw | audit2allow -M my-sshd semodule -i my-sshd.pp配置免密登录所有集群节点# 生成密钥对 ssh-keygen -t rsa # 分发公钥 ssh-copy-id rootnode209 ssh-copy-id rootnode2104.3 预防措施定期进行failover演练建议每月一次设置监控告警对以下情况发出警报集群节点间SSH连接失败VIP检测命令执行失败存储只读状态日志监控策略监控recovery.log中的错误信息对execute failed等关键字设置告警5. 集群配置优化建议5.1 SSH连接优化配置在/etc/ssh/sshd_config中添加PermitRootLogin prohibit-password StrictModes no UsePAM yes5.2 KingbaseES集群参数调整增加存储检测间隔减少误报ALTER SYSTEM SET use_check_disk_interval 300s;调整故障检测灵敏度ALTER SYSTEM SET health_check_timeout 5s; ALTER SYSTEM SET health_check_retry 5;5.3 VIP管理增强方案为避免SSH依赖可以考虑使用Keepalived管理VIP或者采用分布式配置存储如etcd协调VIP状态示例Keepalived配置vrrp_instance VI_1 { state BACKUP interface bond0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.103.211/28 } }6. 故障处理流程标准化6.1 Failover失败时的应急步骤确认故障现象检查集群状态ksql -U system -d test -h vip_host -p port -c show pool_nodes;查看VIP状态ip addr show bond0手动恢复流程# 在原主库停止服务 systemctl stop kingbase # 在备库提升为主库 touch /home/kingbase/cluster/clusterdb/db/data/trigger.file # 手动转移VIP ip addr add 192.168.103.211/28 dev bond06.2 事后检查清单存储状态检查mount | grep datadmesg | grep error网络连接验证# 节点间SSH测试 for node in node209 node210; do ssh root$node hostname done # VIP连通性测试 ping -c 4 192.168.103.211集群健康检查SELECT * FROM pg_stat_replication; SELECT * FROM sys_stat_activity;7. 经验总结与最佳实践这次故障给我们几个重要启示不要忽视小问题备库的SSH连接问题在平时可能不影响业务但关键时刻会导致严重故障监控要覆盖所有关键路径包括SSH连接、VIP状态等基础设施定期演练至关重要至少每季度进行一次完整的failover测试文档和流程要完善建立详细的故障处理手册和检查清单对于数据库集群运维我建议建立以下日常检查项每日检查集群状态show pool_nodes复制延迟select * from sys_stat_replication每周检查SSH连通性测试VIP转移测试可以手动触发存储可写性测试每月检查完整failover演练备份恢复测试安全审计包括SSH配置、权限等通过这次故障分析我们不仅解决了具体问题更重要的是完善了整个集群的运维体系。数据库高可用不是简单的配置问题而是需要从架构设计、日常运维到应急处理的全方位保障。