【金仓数据库征文】自动故障转移如何避免脑裂：仲裁与隔离在高可用集群中的实践

文章目录每日一句正能量摘要摘要1. 背景与问题1.1 为什么自动切换会产生脑裂1.2 自动故障转移的安全目标2. 环境与数据2.1 脱敏实验拓扑2.2 演练业务数据3. 复现过程3.1 基线验证3.2 场景一仅切断主备通信3.3 场景二主库自身网络故障3.4 场景三仲裁节点不可用3.5 场景四旧主假死3.6 场景五网络抖动4. 方案实施4.1 仲裁用多数派决定写入资格4.2 隔离先确保旧主不能写4.3 候选备库选择4.4 访问层切换4.5 旧主恢复5. 结果对比5.1 RTO 实测5.2 RPO 实测6. 风险与复盘6.1 仲裁节点自身成为单点6.2 隔离脚本失效6.3 超时设置导致误切换6.4 同步模式与 RPO 的权衡6.5 检查清单总结每日一句正能量“当你能将生命的一切经历都视为成长的养分便终于获得了内在的、不可动摇的从容。”不筛选、不抗拒连痛苦、失败、失去都被纳入“养分”的范畴。不依赖外部境遇的好坏来决定内心的稳定。不再与生活对抗而是与一切遭遇合作。摘要本文以生产级高可用集群为背景讨论自动故障转移中最危险的异常之一——脑裂。文中给出可落地的仲裁、隔离、故障注入、RTO/RPO 实测和检查清单。摘要自动故障转移的目标并不是“尽快把备库升为主库”而是在故障、网络分区和监控误判同时出现时仍能证明集群中只有一个节点具备写入资格。没有仲裁与隔离的自动切换本质上只是把人工风险改成自动化风险切换速度可能更快但一旦旧主仍在对外写入就会形成两个主库各自产生业务流水后续很难通过普通增量同步无损合并。本文以一个两数据节点加独立仲裁节点的高可用集群为例设计主备互联中断、主库外网中断、仲裁节点故障、旧主假死和网络抖动五类故障注入。实施方案遵循三个原则多数派决定写入资格、提升新主之前先隔离旧主、无法确认安全时宁可停写而不是冒险双写。演练结果通过业务写探针、复制位置、订单流水、摘要校验和时间线记录分别计算 RTO 与 RPO并验证故障恢复后旧主只能以备库身份重新加入。1. 背景与问题1.1 为什么自动切换会产生脑裂正常状态下主库承担写入备库持续接收并回放日志。守护进程通过数据库连接、心跳和环境检查判断节点是否健康。当主库实例真正停止时备库提升通常没有争议困难出现在“看不见对方”而不是“对方已死亡”的场景。例如主库与备库之间的复制网络断开但主库仍能接受应用连接备库侧守护进程发现主库不可达误以为主库失效并触发提升。此时原主库仍在机房 A 接收新订单新主库在机房 B 接收另一部分订单两边都认为自己是合法主库主键、账户余额、库存和流水开始分叉。这就是脑裂。它不是简单的“复制延迟”而是产生了两个不可自动合并的写入历史。对订单、支付和账务系统而言脑裂造成的损失往往高于短时间停机。1.2 自动故障转移的安全目标本次方案把安全目标写成可验收的约束而不是模糊描述任一时刻集群中可接受业务写入的数据库节点数量不超过一个。新主提升前必须确认旧主已经停止服务、失去网络或被 FENCE。无法获得仲裁多数派时节点不得自行提升。故障恢复后的旧主不得直接以主库身份启动。每次切换必须能计算 RTO、RPO并留下完整时间线。2. 环境与数据2.1 脱敏实验拓扑角色节点位置说明数据库节点db-a数据中心 A初始主库数据库节点db-b数据中心 B同步或优选同步备库仲裁节点arb-c独立故障域 C只参与投票不承载业务数据访问入口db-vip / 代理双中心将写流量指向唯一主库监控系统monitor独立管理区记录心跳、切换与业务恢复时间KingbaseES 高可用集群由主库、备库与守护进程组成守护进程负责状态检查和故障处理官方资料还说明网络故障容易造成脑裂集群可通过信任网关等方式辅助判断本机网络是否异常。正式部署时应以当前版本手册和实际组件能力为准。2.2 演练业务数据为了测量 RPO不能只看数据库进程是否启动而要持续写入带序号的业务流水。本文使用ha_drill_order表记录连续订单号演练批次号提交时间实际写入节点业务载荷摘要。压测程序每秒写入 100500 条发生故障时继续请求记录成功、失败和重试结果。这样可在切换后检查订单号缺口、重复写入及两个节点是否曾经同时成功写入。3. 复现过程3.1 基线验证演练前先确认主库可写备库只读复制状态正常回放延迟在阈值内仲裁节点与两个数据库节点均可达访问入口只指向当前主库FENCE、远程停库或网络隔离脚本已在维护窗口验证业务写探针、对账脚本和时间同步均正常。基线不健康时禁止故障注入。否则演练结果无法区分是方案问题还是既有故障。3.2 场景一仅切断主备通信阻断 db-a 与 db-b 之间的复制和心跳端口但保留两边到应用网络及仲裁节点的连接。这个场景最能暴露“仅靠节点互相心跳”的风险。错误实现会出现db-a 继续写db-b 因看不到 db-a 而提升形成双主。正确实现应由仲裁多数派决定哪一侧继续服务少数派主动停止数据库写入或退出服务入口。3.3 场景二主库自身网络故障隔离 db-a 到信任网关、应用网络和仲裁节点的连接但 db-a 本机数据库进程仍在运行。此时 db-a 应判断是“本机网络异常”而不是错误地认为其他节点全部故障。保护动作包括停止对外服务、关闭写入口或执行节点隔离。3.4 场景三仲裁节点不可用停止 arb-c 后再模拟数据库节点间网络异常。由于无法形成可靠多数派系统应进入保护模式保持当前已确认主库或停止自动提升不能让两个节点分别自选为主。3.5 场景四旧主假死模拟数据库进程无响应、磁盘长时间阻塞或操作系统卡顿但节点电源仍开、网络时断时续。仅执行“提升备库”是不够的新主提升前必须确认旧主已被停库、断网、断电或由 FENCE/STONITH 隔离。3.6 场景五网络抖动持续注入延迟、丢包和短时断连。若超时阈值过低集群会频繁切换若过高RTO 又会被拉长。因此应通过多轮实验确定心跳间隔、连续失败次数、切换冷却时间和回切抑制时间。4. 方案实施4.1 仲裁用多数派决定写入资格两节点集群最大的问题是出现网络分区时双方票数相同。增加独立仲裁节点后形成奇数票db-a 与 arb-c 可达db-a 获得多数派db-b 与 arb-c 可达db-b 获得多数派db-a 与 db-b 可达但仲裁不可达维持既有主从不随意提升单个数据库节点与其他节点均隔离该节点失去写入资格。仲裁节点应部署在独立故障域不能与任一数据库节点共享同一台主机、同一交换机或同一电源故障点。仲裁服务也要监控否则“有仲裁配置”不等于“仲裁真实可用”。4.2 隔离先确保旧主不能写仲裁解决“谁应该成为主库”隔离解决“旧主是否真的失去写能力”。常见隔离方式包括远程停止数据库服务将旧主从业务 VLAN 或负载均衡中摘除通过 IPMI、云主机 API 或电源控制执行 FENCE共享存储场景使用 STONITH 保障资源唯一所有者撤销旧主的写入 VIP、路由或代理注册。安全顺序应是确认故障与仲裁结果执行旧主隔离验证旧主写探针失败选择回放位置最优且健康的备库提升新主更新访问入口验证业务恢复。任何“先提升、后慢慢隔离”的流程都扩大了双写窗口。4.3 候选备库选择多备库环境不能只按节点名称固定提升。应综合判断WAL 接收和回放位置当前复制状态复制延迟数据目录、磁盘和文件系统健康是否具备多数派是否能够被应用访问是否存在长时间恢复或损坏告警。在同步复制模式下RPO 可以接近零异步复制下仍需根据故障瞬间的发送、接收和回放差距计算实际数据窗口。不能把“自动切换成功”直接等同于“零数据丢失”。4.4 访问层切换数据库提升完成不代表业务已经恢复。还需处理VIP 漂移DNS 缓存数据库代理主节点刷新连接池失效连接清理事务重试与幂等控制只读/读写路由更新。应用重试必须有上限并具备幂等键否则切换期间的超时重试可能造成重复订单。业务恢复时间点应以真实接口成功为准而不是以数据库提升命令返回为准。4.5 旧主恢复旧主重新联网后不允许直接恢复成主库。标准步骤是保持业务入口隔离确认时间线和分叉点判断是否需要重新构建以备库身份从新主同步对账通过后加入集群观察稳定窗口后才恢复读流量。若脑裂已经发生应冻结两边写入按业务流水确定权威数据源并制定专项合并方案不能直接让两端互相覆盖。5. 结果对比本文以三轮脱敏实验展示记录方式数值仅为示例。方案故障发现旧主隔离新主提升与路由业务 RTO实测 RPO脑裂结果仅心跳、无仲裁15 秒未完成35 秒50 秒无法可信计算出现双写有仲裁、无强隔离15 秒45 秒25 秒85 秒02 秒存在短暂风险仲裁 FENCE 路由门禁12 秒8 秒18 秒38 秒01 秒未发生脑裂对比说明一个容易忽略的事实最短 RTO 不一定是最安全方案。若为了追求几秒切换而省略旧主隔离可能用极短停机换来不可逆的数据分叉。更合理的目标是先保证写入唯一性再持续压缩检测、隔离、提升和应用恢复时间。5.1 RTO 实测RTO 按下列时间线计算T0故障注入T1监控告警T2旧主隔离完成T3新主提升完成T4应用首个关键写接口成功T5业务对账完成。严格的业务 RTO 取T4 - T0。若业务要求“对账通过才算恢复”则采用T5 - T0。报告中必须说明口径避免只统计数据库提升时间。5.2 RPO 实测RPO 至少使用两种方式交叉验证时间窗口比较故障前最后确认提交时间与新主最后连续可见时间流水缺口检查连续订单号、消息偏移量或业务版本号摘要对账比较数量、金额、状态分布和逐批摘要客户端确认核对已向客户端返回成功但新主不存在的交易。只有数据库行数相等并不能证明 RPO 为零重复提交、状态回退和跨表不一致也必须检查。6. 风险与复盘6.1 仲裁节点自身成为单点仲裁节点不承载业务数据但其故障会影响自动切换决策。应至少保证独立故障域服务自动拉起容量和磁盘告警时间同步多路径网络或清晰的降级策略定期验证投票状态。6.2 隔离脚本失效FENCE 设备、云 API 凭证、IPMI 密码或远程命令可能长期未使用而失效。建议每季度在维护窗口验证一次并将“隔离成功”作为自动提升的前置条件而不是仅记录告警后继续切换。6.3 超时设置导致误切换超时阈值应依据真实网络 RTT、抖动、磁盘延迟和数据库恢复时间设定。过低会误切换过高会增加 RTO。建议使用历史监控的 P99 延迟加安全余量并设置连续失败次数与冷却时间。6.4 同步模式与 RPO 的权衡实时同步有助于降低 RPO但会增加提交路径对网络和备库性能的依赖。异步模式可保持主库写入吞吐却无法承诺故障时零丢失。应按业务等级分别配置不应把所有系统套用同一模式。6.5 检查清单部署前仲裁节点位于独立故障域数据库节点、仲裁节点和信任网关地址正确FENCE/停库/断网方式至少一种可验证主备时间同步和证书、密钥有效应用连接串、代理和 VIP 具备切换能力写接口具备幂等键。演练前复制状态健康延迟低于门槛备份与回退方案可用业务写探针和时间线表已启动明确暂停条件和人工接管人记录主备位置、连接数和业务基线。演练中逐项记录 T0T5确认旧主隔离后再提升验证同一时间仅一个节点写入成功检查新主读写、序列、任务和权限监控连接池重连、错误率和重试量。演练后计算并复核 RTO、RPO完成数量、金额、状态和流水对账旧主以备库方式重建清理临时规则与测试数据更新阈值、脚本和应急预案保存日志、截图与个人复盘。总结自动故障转移避免脑裂的核心不是某一条切换命令而是一条不可绕过的安全链健康检查发现异常仲裁确认多数派隔离剥夺旧主写权限再提升新主并切换业务入口。其中任何一步缺失都可能让“高可用”变成“双主高风险”。真正可信的高可用方案必须通过故障注入证明主备互联中断、主库网络故障、仲裁失效、旧主假死和网络抖动时集群仍然最多只有一个写主还必须用业务流水实测 RTO 与 RPO而不是只引用产品能力值。高可用演练的目标不是追求一次漂亮的秒级切换而是形成可重复、可审计、可回退的生产保障流程。转载自https://blog.csdn.net/u014727709/article/details/163271002欢迎 点赞✍评论⭐收藏欢迎指正