SQL主从无感切换关键在应用层：连接池需支持自动故障转移，应用需实现读写分离与主库探活，事务重试须幂等可控，且应通过服务发现动态寻址。
SQL主从切换实现“无感”，关键不在数据库本身，而在于应用层能否自动识别节点状态、快速重连新主库，并屏蔽切换过程中的短暂不可用。真正的无感不是零延迟，而是不抛错、不中断业务、不需人工介入。
连接池必须支持故障自动转移
应用直连数据库时，主从切换后旧连接会失效，若连接池不主动剔除或重试，请求将持续失败。需确认所用连接池是否具备以下能力：
- 开启连接有效性校验（如 HikariCP 的 connection-test-query 或 validation-timeout）
- 配置合理的 max-lifetime 和 idle-timeout，避免长连接滞留旧主节点
- 启用 failover 模式（如 MySQL JDBC 的 loadBalance 或 replication 连接类型）
- 例如使用 MySQL Connector/J 8.0+ 时，可配置：
jdbc:mysql:loadbalance://host1:3306,host2:3306/db?loadBalanceAutoCommitStatementThreshold=5&loadBalanceConnectionGroup=group1
应用需具备读写分离+主库探活机制
单纯靠中间件或代理做读写分离不够可靠，应用自身应掌握主库实时地址。建议采用轻量级探活+本地缓存策略：
- 定时向各候选节点发送 SELECT 1 或 SHOW VARIABLES LIKE 'read_only'
- 将当前主库地址缓存在本地（如 Caffeine），并设置较短过期时间（如 10 秒）
- 写操作前检查缓存主库是否可用，不可用则触发重新探测，失败则降级为异常处理（如返回友好提示或进入只读模式）
- 避免所有实例同时刷新探测，加入随机抖动（如 ±2 秒）防雪崩
事务与重试逻辑必须可控
主从切换窗口内，正在执行的事务可能因连接中断回滚，应用不能简单重试所有操作：
- 仅对幂等写操作（如 UPDATE 订单状态=‘paid’ WHERE id=? AND status=‘unpaid’）启用自动重试
- 非幂等操作（如 INSERT 订单）需结合业务唯一键 + 去重表/缓存，防止重复下单
- 分布式事务场景下，优先使用 SAGA 或本地消息表，而非强依赖数据库主库连续性
- 重试次数建议 ≤3 次，间隔指数退避（如 100ms → 300ms → 900ms）
配合 DNS/服务发现实现动态寻址
硬编码 IP 或固定域名会让切换变成运维动作。推荐解耦网络层与应用层：
- 用 Consul/Etcd/Nacos 管理主库 VIP 或逻辑名（如 mysql-primary.service）
- 应用启动时订阅该服务，变更时收到通知并刷新连接池
- DNS 方案需注意 TTL 必须设为 5 秒以内，并确保客户端不缓存解析结果（JVM 可通过 networkaddress.cache.ttl 控制）
- 避免使用 LVS/VIP 类方案——它无法解决连接池中残留旧连接问题
