核心是主动控制连接生命周期：设硬性超时（connect_timeout 1–3秒、socket_timeout 30–90秒），分级响应故障——建连失败立即切节点，sql报错清空连接重建，多次失败触发降级；客户端需动态发现主节点，业务层参与重连决策，事务中断必须回滚。

主备切换期间客户端连接重连与超时重试，核心不是“等它自己好”，而是主动控制连接生命周期、快速识别失效、分级响应故障。重点在于：连接不能卡住，重试不能盲目，失败不能静默。

连接层必须设硬性超时，避免长等待假死

很多客户端在切换瞬间不报错，只是卡住几十秒甚至几分钟——这是没设连接和读写超时的典型表现。

• connect_timeout：控制建连阶段最大等待时间，建议设为 1–3 秒。超过即放弃当前节点，不阻塞后续重试逻辑
• socket_timeout / readTimeout：控制已建立连接上单次操作（如执行 SQL）的最大等待时间，建议 30–90 秒，防止主库假死（TCP 通但 SQL hang）拖垮整个调用链
• 数据库驱动如 psycopg2、pymysql、openGauss JDBC 均支持这些参数，必须显式传入，不能依赖默认值（常为 0 或无限）

重连策略要分场景，不能统一“失败就重试”

一次连接失败，背后原因不同，应对方式也应不同：

• 首次建连失败（如主节点已下线）→ 立即尝试备用地址列表中的下一个节点，不退避、不延迟
• 已建连后执行 SQL 报“只读错误”或“连接被拒绝” → 判定为主从已切换，清空当前连接，强制重建，不走普通重试逻辑
• 连续多次失败（如 3 次全节点不可达）→ 触发降级：返回缓存数据、返回兜底响应、或抛出明确异常供上层熔断

客户端需感知角色变化，而非依赖静态地址

直连 IP + 端口的模式在主备切换中天然脆弱。真正可靠的方案是让客户端具备动态发现能力：

• 使用支持多地址的 JDBC 连接串（如 openGauss 的 jdbc:opengauss://host1:5432,host2:5432/db?targetServerType=master&loadBalanceHosts=true），由驱动自动轮询并跳过只读节点
• 通过轻量代理（如 ProxySQL、HAProxy）暴露固定 VIP 或域名，客户端只连这个入口，代理负责探测主节点并转发
• 微服务中可集成配置中心监听（如 etcd/ZooKeeper），failover-controller 更新主地址后，各服务实时拉取，Repository 层按新地址重建 masterDB 实例

应用自身要带自动重连机制，且不可绕过业务语义

重连不是底层驱动的事，业务代码必须参与决策：

• 事务内发生连接中断 → 不能简单重试，必须回滚并通知上游重发，否则可能造成重复写入
• 非事务性查询（如首页展示）→ 可启用带退避的重试（如指数退避 100ms/200ms/400ms），最多 3 次
• 所有重连动作必须记录日志，包含原节点、目标节点、失败原因、耗时，便于事后定位是否真发生了切换