数据库主备切换后应用为何要使用合适的连接入口

🔁 角色变化与连接地址是两件事

主备架构在故障或维护期间可能切换主角色。数据库节点地址表示具体实例；业务连接入口则应表达“当前可写的服务”，并在角色变化后将新连接导向正确目标。入口实现可能是代理、服务发现或平台管理的连接名称，具体行为依部署而异。应用若硬编码某个节点地址，切换成功也可能继续连接旧主，或在旧实例被隔离后反复失败。

设计评估应查清入口如何发现新角色、健康检查依据什么、DNS结果缓存多久、现有连接会如何处理、客户端何时重新解析，以及读写请求如何区分。不能假定入口会自动迁移已建立的 TCP 会话；很多系统只能让新连接走新目标，池内旧会话仍需检测并淘汰。将入口能力和驱动行为通过实际演练验证，避免依赖未经证实的切换假设。

🔌 让连接池识别失效会话

故障切换时旧连接可能处于半开状态，应用短暂无法确认服务器是否处理了最后一条语句。连接池应避免无限等待，并在明确的网络或服务器错误后丢弃失效连接。连接获取超时、连接建立超时、读超时和写超时承担不同职责，应与请求总时间预算配合。连接验证机制不能设置为每次借用都进行昂贵操作，也不能仅凭连接曾经健康就永远信任它。

切换后的新连接需重新经历认证、初始化会话参数和事务状态设置。应用应在事务外重连；若连接在事务中断开，不能假定事务自动按应用预期完成。对写请求尤其要处理结果未知状态：服务端可能已提交，只是响应丢失。仅在操作具备幂等键或业务去重能力时，才适合自动重试。重连成功不等于上一笔写入结果已知。

⚠️ 数据可见性和切换窗口

高可用切换可能受复制模式、确认策略和故障判断影响，未确认或尚未复制的数据是否保留取决于系统设计。应用层应记录切换期间失败请求、重试决策与业务请求标识，并对关键账务或订单数据执行对账。入口切换解决的是连接到可用角色，不自动提供跨节点数据无损、事务重放或业务级一致性保证。对于可能重复的操作，使用唯一业务请求号及数据库唯一约束等机制定义去重边界。

🧪 一次完整切换演练

1. 在非生产环境记录切换前入口解析结果、连接池状态、主备角色、读写成功率及延迟基线。
2. 通过受控方式触发角色变化，观察新连接的目标节点、旧连接错误类型和池的失效连接淘汰时间。
3. 在切换窗口持续执行带幂等标识的代表性读写，记录响应超时、结果未知、重试和最终数据状态。
4. 确认恢复时间、错误率与目标一致，并通过业务键核对可能重复或缺失的写入；验证连接池在流量恢复后不会保留持续失败的会话。

✅ 验收不止看入口

当切换后应用能够在约定时间内建立新连接、向新主执行验证写入、淘汰旧会话，且失败请求能按幂等规则处理，链路才算通过演练。持续监控角色变更和连接错误，定期复测客户端缓存与池行为。合适的连接入口降低地址耦合，超时和重试定义恢复速度，业务幂等与对账则覆盖故障窗口中的结果不确定性。