标准答案
- 连接池要在连接断开、读写角色变化或探活失败时丢弃旧连接，并按退避重建；不能让每个请求同时无限重连，把故障放大成连接风暴。
- 一个事务在连接断开时可能已经提交，也可能尚未执行，应用通常无法仅凭网络错误判断结果；写请求必须通过幂等键、业务状态查询或安全重试策略确认。
- 读写路由要通过代理、服务发现或受控 DNS 识别当前主库，并在新连接上重新设置 session 参数、prepared statement 和应用上下文，不能永久缓存旧主库地址。
- 故障切换涉及复制延迟、可能的数据丢失和新时间线；切换前要有旧主库隔离或 fencing，避免旧主库恢复后与新主库形成双写。
- 恢复后逐步放量，验证写入、读取、复制、连接池、重试积压、数据对账和外部副作用，确认应用不是“能连上”但持续写错角色。
题目解析
连接恢复和请求恢复是两个问题。连接池可以重新建立 TCP 连接，但断线前的事务结果可能未知；如果应用无条件重放支付、扣库存或发消息，就可能把一次故障变成重复副作用。
切换路径还要处理旧主库。只改变 DNS 或代理目标并不能保证旧连接立即消失，旧主库如果仍能接受写入，会造成分叉数据和后续对账困难，因此必须有角色探测和隔离机制。
重试策略应以业务幂等和截止时间为边界，并设置退避、抖动和最大次数。恢复验证要把数据库状态、应用指标和关键业务不变量放在同一时间线上观察。
常见误区
- 误区：捕获连接异常后无条件重试整个写请求。改正：先判断事务结果是否未知，只对幂等或带幂等键的操作重试，必要时查询业务状态。
- 误区：只修改 DNS 就认为切换完成。改正：连接池、驱动缓存、代理探活和旧主库隔离都要验证，DNS TTL 不是故障切换协议。
- 误区：新主库能接受写入就立即恢复全部流量。改正：先确认角色、时间线、复制和数据校验，再小流量放开并观察重试与副作用。