背景

最近公司在迁移机房，其中涉及到数据库的迁移。DBA给出的迁移方案如下：

在新机房部署一套MySQL集群，作为老机房数据库的从节点，同步数据；数据追平一致后，择机将老数据库的主节点改为readonly模式（一般是业务低潮的时候，比如凌晨）；互换新老集群的主从角色；修改数据库实例的域名，从老集群指向新集群；等应用自动连接新集群后，下线老集群节点。迁移失败

方案看着没啥问题，实则不然。

上周三凌晨，我们按照这个方案严格推进，走完第四步，等待了五分钟左右后，发现新集群的数据库实例一个链接也没有进来，老集群链接依旧keep alive。

除此之外，还有两个现象：

应用日志也能看到有联机业务在持续发生；系统运维伙伴登录到应用实例所在的机器，ping数据库实例的域名，返回的确实是新集群的IP。原因分析业务日志正常，而且老数据库实例有连接，新实例没有连接，首先怀疑是不是域名解析没有生效；登录老实例，通过ping命令ping通域名，发现解析的是新集群的IP地址，说明操作系统级别的域名解析是生效了的，所以怀疑java应用本身缓存了DNS的解析结果；查询应用实例的启动参数，果然有一个参数，-Dnetworkaddress.cache.ttl=300，这个参数的意思是设置jdk解析域名成功的缓存时间，单位秒；5分钟后，新集群依然没有连接进入，怀疑数据库连接本身一直没有重新创建；检查java应用连接池的配置，发现db.minIdle=100，这个参数的意思是连接池里最小空闲连接数。

至此，谜底解开。

恢复系统

平滑点的方式应该是设置db.minIdle=0，并减少jdk域名解析缓存时间。

但是考虑到影响有限，直接重启应用了。