Aurora MySQL集群故障转移后，Java Web应用无法连接写入数据库求助

刚踩过几乎一模一样的坑——Tomcat8+HikariCP+ConnectorJ的组合，故障转移后应用死活连不上可写节点，折腾了大半天终于搞定，给你分享下排查和解决的步骤：

先搞懂核心原因 #

Aurora集群端点故障转移后，云端DNS会更新指向新的主节点，但你的应用连接池里的旧连接还握着原来主节点（现在变成只读副本）的IP；再加上ConnectorJ默认会缓存服务器配置，HikariCP如果没做针对性的连接有效性检测，就会一直复用这些失效的连接，自然就写不进去了。

一步步解决问题 #

1. 调整Connector/J的JDBC URL参数 #

在你的JDBC连接URL里加上这几个关键参数，强制适配Aurora的故障转移逻辑：

jdbc:mysql://your-cluster-endpoint.rds.amazonaws.com:3306/your-db?cacheServerConfiguration=false&autoReconnect=true&maxReconnects=3&useSSL=true&enabledTLSProtocols=TLSv1.2

• cacheServerConfiguration=false：禁止ConnectorJ缓存服务器IP，每次获取连接时重新解析DNS，确保拿到最新的主节点地址
• autoReconnect=true：连接断开时自动尝试重连，避免因节点切换导致的连接中断
• useSSL和enabledTLSProtocols：保证和Aurora的加密连接兼容性，避免版本不匹配导致的连接失败

2. 优化HikariCP的连接池配置 #

HikariCP默认的连接回收和检测机制不够灵敏，需要调整这些参数（在context.xml或Hikari专属配置文件里修改）：

# 强制回收超过30分钟的连接，避免长期持有旧IP的无效连接
maxLifetime=1800000
# 闲置5分钟的连接自动回收，减少无效连接占比
idleTimeout=300000
# 每次获取连接前验证有效性，依赖ConnectorJ的isValid()方法（5.1.37+版本支持）
validationTimeout=5000
# 可选：检测连接泄漏，超过1分钟未归还就触发告警
leakDetectionThreshold=60000

如果你的ConnectorJ版本低于5.1.37，就把validationTimeout换成connectionTestQuery=SELECT 1，用SQL查询来验证连接有效性。

3. 验证EC2实例的DNS解析结果 #

登录部署应用的EC2实例，用命令解析集群端点，确认是否指向新的主节点IP：

dig your-cluster-endpoint.rds.amazonaws.com

如果返回的还是旧IP，说明EC2的DNS缓存没更新，Linux系统可以用这个命令刷新：

systemd-resolve --flush-caches

不同OS的刷新命令有差异，比如CentOS 7可以用service nscd restart。

4. 确认新主节点的可写状态 #

登录数据库执行这条SQL，确认当前连接的节点是可写的：

SELECT @@global.read_only;

返回0代表可写状态，如果返回1，说明你可能误连了只读副本，得检查是不是用了只读端点而非集群端点。

5. 升级Connector/J版本 #

如果还在使用5.1.x的旧版本，强烈建议升级到8.0.x系列，新版本对Aurora的故障转移、DNS解析和连接稳定性都做了针对性优化，能避免很多莫名其妙的问题。

测试验证 #

修改配置后重启Tomcat，然后手动触发一次Aurora故障转移，观察应用是否能自动切换到新主节点，写入操作是否正常。如果还是有问题，去Tomcat日志里找连接超时、权限不足或者只读错误的堆栈信息，精准定位剩余问题。

内容的提问来源于stack exchange，提问作者im dumb