sql数据库主备切换实现“无感知”的核心是业务连接不中断、数据不丢失、状态自动同步，需网络层、中间件、应用层与数据库协同；连接层须通过代理（如proxySQL）或负载均衡（如HAProxy）统一入口，配合健康检查、分步切换脚本及一致性校验。
SQL数据库主备切换实现“无感知”，核心在于业务连接不中断、数据不丢失、状态自动同步。这并非单纯靠数据库自带功能就能达成，而是需要网络层、中间件、应用层与数据库协同配合的一整套方案。
连接层：用代理或负载均衡屏蔽后端变化
客户端不应直连具体数据库IP和端口，否则主备切换时必须修改配置或重启应用。推荐使用轻量代理（如ProxySQL、mysql router）或四层负载均衡（如HAProxy、lvs）作为统一入口：
- 代理监听固定VIP或域名（如db.example.com:3306），后端指向当前主库；
- 主备切换后，代理快速探测到新主库并更新路由，对应用透明；
- 配合健康检查（如检测read_only=OFF或复制延迟
数据库层：确保主备强一致与快速故障识别
避免因复制延迟或脑裂导致数据丢失或双写，需在数据库配置上做硬性约束：
- MySQL建议启用semisync replication（半同步），至少一个备库确认接收才提交；
- PostgreSQL推荐synchronous_commit = remote_apply，确保事务日志同步且已重放；
- 主库心跳监控不能只看进程存活，要结合SELECT 1、复制位点比对、磁盘IO响应等多维度判断；
- 禁用手动SET GLOBAL read_only=OFF，通过高可用工具（如MHA、Patroni）统一管控角色变更。
应用层：连接池与重试机制适配切换窗口
即使代理层毫秒级切换，应用仍可能遇到短暂连接断开或事务失败。需在代码/框架中主动应对：
- 连接池（如HikariCP、Druid）开启testOnBorrow或validationQuery，及时剔除失效连接；
- 对非幂等写操作（如INSERT无唯一键），增加重试+去重逻辑（例如用业务单号做幂等表）；
- 避免长事务或超时未提交的连接占用资源，设置wait_timeout与应用侧socketTimeout联动；
- 关键接口可增加降级兜底（如缓存暂存、异步落库），减少对实时DB强依赖。
切换流程：自动化驱动，人工仅做最终确认
一次可靠切换应全程脚本化，人工只参与风险决策环节：
- 触发条件可为告警（如主库CPU>95%持续2分钟+复制延迟>30秒）或计划内维护；
- 切换脚本依次执行：停写→校验GTID/LSN一致性→提升备库→更新代理配置→刷新dns缓存→恢复读写；
- 每步带超时与回滚分支（如提升失败则自动切回原主）；
- 切换完成后自动运行数据一致性校验脚本（对比关键表行数、checksum），结果推送至运维群。