主备服务器什么时候切换？故障判定、数据状态与防脑裂
切换决定涉及数据写入权
主备方案的关键不是准备了两台机器，而是在故障时决定哪一台可以继续接收写入。若旧主只是与监控点失联，仍然服务部分客户端，备用节点又被提升，两边可能同时接受写入，造成分叉和数据冲突。
PostgreSQL官方故障切换文档强调，需要防止旧主在新主启用后再次作为主节点运行，并指出数据库本身之外还需要故障检测与切换配套。官方故障切换说明
因此，切换条件至少包含故障判断、备用节点数据状态和旧主隔离结果。只看到一次探测超时就执行提升，会把短暂网络问题放大成数据恢复问题。
故障证据应来自多个层次
分别观察外部业务探测、应用连接和主节点自身状态。多个独立观察点都失败，可以增加对服务不可用的判断信心；但若它们共享同一个网络出口，仍然可能一起受到局部网络影响。
假设办公室无法连接主节点，而另一个地区的业务探测仍然正常，这时应先定位访问路径，不应立即切换数据库。若主节点进程已经停止、控制台确认资源故障且业务持续失败，才更接近预案中的切换场景。
还要给短暂抖动设置合理的持续时间与确认次数。阈值应根据业务恢复目标和历史噪声制定，并在演练中验证。自动化能够快速执行既定条件，却不能替代对条件是否可靠的设计。
备用节点“在线”不等于数据足够新
检查复制连接、最近接收位置、重放位置以及复制延迟，并确认备用节点处于可提升状态。异步复制可能存在主节点已确认但备用节点尚未收到的数据；同步复制的保证也受具体配置和故障场景约束，不能仅凭“同步”一词承诺任何故障下零损失。PostgreSQL复制文档
切换前应将预计的数据差距与业务允许的RPO比较。如果差距超出目标，应明确记录当前选择的损失风险、是否还有可取回的日志，以及谁有权决定继续。不要在完成提升后才发现备用节点长时间没有追上。
备用节点的版本、权限、扩展和应用连接配置也应提前验收。数据库进程能启动，却缺少应用依赖，仍可能使切换后的服务无法使用。
先处理旧主，再改变入口
根据采用的集群软件和基础设施，使用受支持的隔离机制确保旧主不再接受写入。隔离可以涉及节点电源、存储访问或网络与服务控制，但必须具备可靠确认；单独修改DNS不保证旧连接立即失效。
随后按预案提升备用节点、更新应用连接或代理入口，并使应用重新建立正确连接。具体命令高度依赖数据库版本和管理工具，不宜把一套通用脚本直接用于生产。每一步都应有完成条件和停止点。
计划内切换可以先停止新写入、等待复制追平并排空连接，通常比突发故障更容易控制。两种场景应分别编写流程，避免用计划内的乐观假设处理真正的主机失联。
切换后验证唯一写入点与业务一致性
先确认所有应用指向新主，旧主保持隔离，再用受控数据验证读写、事务和后台任务。检查是否出现重复执行、连接重试风暴或只读错误，并核对关键业务记录的连续性。
旧主恢复后不能直接以原配置重新上线。需要判断它与新主的数据关系，按数据库支持的方法重新同步或重建为备用节点。对分叉数据的处理应保留现场和记录，避免覆盖仍需核对的信息。
最后整理故障时间、判定依据、复制状态、隔离方式和实际恢复时长。将演练与真实事件中的差距反馈到阈值和自动化流程，主备方案才会逐渐变成可以信赖的恢复能力。