主从切换后连接池仍连旧主库是因连接池未感知地址变更；需配置探活参数、DNS缓存、多实例验证及抓包确认连接行为与基础设施实时对齐。
主从切换后连接池还在连旧主库？
这是最常踩的坑：数据库主从切换完成，应用却持续往已下线的旧主库发请求，直到连接池超时或业务报错。根本原因不是切换没成功，而是连接池不知道主库变了。
Java 应用常见于 HikariCP 或 Druid，它们默认不会主动探测底层地址变更。即使你改了配置中心里的 JDBC URL，已有连接仍复用旧连接，新连接才走新地址——而连接池通常会长期复用连接。
- 验证方法：切换后立刻查
show processlist（MySQL）或pg_stat_activity（PostgreSQL），看应用 IP 是否仍在连旧主库地址 - 关键参数：
connection-test-query（Druid）、connection-test-query+validation-timeout（HikariCP）必须显式配置，且查询语句得是轻量级的（如SELECT 1） - 更可靠的做法是启用连接池的「自动重连」+「连接失效检测」组合：设
test-on-borrow=true（Druid）或connection-test-query=SELECT 1+validation-timeout=3000（HikariCP） - 注意：MySQL 驱动 8.0+ 的
autoReconnect=true已被弃用，不解决连接池层的缓存问题
演练脚本里只停 MySQL 服务不够
真实故障不只是主库进程挂了，还可能是网络分区、VIP 漂移失败、中间件（如 ProxySQL、MaxScale）转发异常。单靠 systemctl stop mysqld 模拟，会漏掉大量生产级场景。
有效演练必须覆盖控制面与数据面分离的故障：
- 模拟 VIP 失效：在主库机器上
ip addr flush dev eth0，再触发 MHA 或 Orchestrator 切换 - 模拟中间件脑裂：手动 kill 掉 ProxySQL 主节点进程，观察后端是否出现双写或路由混乱
- 验证脚本里必须包含「切换前/后」的
SELECT @@hostname和SELECT @@read_only对比，不能只依赖日志里“failover success”字样 - 别忘了检查从库的
Seconds_Behind_Master：切换瞬间如果延迟 30 秒，业务可能读到过期数据，这不是连接池问题，但会影响有效性判断
业务连接池探活间隔设成 5 秒真能及时发现？
不能。探活间隔只是「检测频率」，真正决定响应速度的是「连续失败次数 × 间隔」+「连接重建耗时」。设成 5 秒，若需连续失败 3 次才摘除连接，那就是 15 秒起步，再加上 DNS 缓存、TCP 建连超时（默认常为 30 秒），实际感知延迟可能超 45 秒。
- DNS 缓存是隐形杀手：JVM 默认永久缓存 DNS，必须加 JVM 参数
-Dnetworkaddress.cache.ttl=30（单位秒） - 连接池摘除连接 ≠ 应用无感知：Spring Cloud LoadBalancer 或自研路由层若缓存了数据源地址，也得同步刷新，否则探活再快也没用
- 建议组合策略：探活间隔 ≤ 2 秒 + 连续失败阈值 = 2 + 启用
soft-evict-stale-connections（Druid）或leak-detection-threshold（HikariCP）辅助识别僵死连接 - 切忌把
maxLifetime设得太长（比如 30 分钟）：它会让连接强行存活，绕过所有探活逻辑
验证结果里出现 “Connection refused” 就算失败？
不一定。这反而是健康信号——说明连接池确实尝试连新地址，且新地址不可达（比如 VIP 没漂过去、防火墙未开、MySQL 未启动）。真正的失败是静默：连接池继续用旧连接发请求，返回 ERROR 1290 (HY000): The MySQL server is running with the --read-only option 或直接超时，但日志里没有任何重连记录。
- 重点盯日志关键词：
Failed to validate connection（HikariCP）、testWhileIdle testOnBorrow testOnReturn是否触发 - 用
tcpdump抓包验证：切换后 10 秒内，应用机器是否向新主库 IP:3306 发起 SYN 包 - 检查
netstat -anp | grep :3306，确认 ESTABLISHED 连接的目标 IP 是否已更新 - 最容易被忽略的是：应用多实例部署时，只验证了其中一台，其他实例可能因配置未同步或本地 DNS 缓存仍连旧地址
