说明

前置条件：我们云上有一批同网段虚拟机，其中一台是数据库服务器，剩下的是客户端，需要去连接这个数据库服务器。
本地安装了一个centos7.6的测试系统，连接数据库一切正常，且很快。
下面为云上的centos虚拟机客户端连接数据库的问题：
- 1、最小化安装的系统，selinux没关之前直接无法连接上数据库，关了selinux可以连上，很慢；
- 2、最小化安装后，安装桌面基础包并进入桌面，selinux关了能连上数据库，很慢。
- 3、更换了其他版本的centos系统，一样能连接，很慢。
根据上面情况，猜想可能的问题有
- 1、云上qcow2镜像问题
- 2、网络问题【但同网段，理论上不存在网络延迟，而且网页这些啥啥啥都很快，不可能就数据库的端口有延迟】
- 3、客户端的问题【但是同样的包，在测试机上连就很快，在云上就不行，好像也不能怀疑客户端】
- 4、有啥验证在等待，时间一到就跳过了【因为每次都是180S左右就连上了】，但是我不知道是啥再等待，但我知道肯定是有啥在等待的，找到这个问题就好了。。。。
下面为定制系统
用本地安装的测试系统centos7.6镜像，打包成qcow2镜像，然后放到云上再试。
- 1、装好系统以后的qcow2镜像，没有做过任何操作，能连数据库，很慢。
- 2、装好系统以后并做修改，然后删除关键信息以后再打包为qcow2，能连接数据库，很慢。
到此，又得出结论，和镜像没关系，因为定制的这个镜像iso和本地的测试系统是同一个，而且安装方式都一样。
那么好像只剩下是网络的问题了，但同网段不存在网络延迟之类的说法，到这好像到死胡同了，那么就在云上创建一个windows系统，在windows上装客户端，再链接数据库，如果连接数据库正常，那么就和网络没关系。
创建windows虚拟机
连接很快，那么排除网络延迟的问题了，还是得重客户端上找问题。。。。。至此又陷入死胡同了。。。

解决方案

/etc/resolv.conf配置文件中自动生成同网段的几个dns地址了，把这几个地址注释掉就好了
因为这是内网环境，不需要出外网，所以我们也不可能主动去检查这个配置文件。
而且我们是不会配置这个文件的，是因为在云上的原因，自动生成下面几个地址了，下面几个地址是假的地址，实际并不存在，所以也ping不同。。。。坑爹啊。

总结

云上的主机因为在resolv.conf文件中自动生成了几个不存在的地址，所以jdbc连接数据库的时候，服务端在验证这几个地址，不通就存在等待嘛，3分钟就跳过这个验证，所以就连接上了。。。。所以最开始我的猜想是正确的，这种情况肯定是有啥在等待，因为数据库服务端和客户端都不是我弄的，具体要验证些啥我也不知道。。。
而本地测试机，我有外网的，下面配置文件中也有dns，但配置的是真实存在的dns地址，所以能通，jdbc连接呢就不会有问题。
这个问题陆陆续续搞了1个多月，真的能想到的都试了，没想到最终是因为dns地址的问题。。。
没办法，内网环境，让我排查，我肯定不会去想dns地址这个问题的，因为没有外网，这个地址存在与否不影响系统使用的
最后还是应用方找了大佬查日至，看到dns一直在验证等待，才去看的这个配置文件，问题才解决的。
【其实应用方最开始有让研发的人看的，但研发的人看日志没看出问题。。。】
反正不管咋样，最终问题解决了，就是好事。
后面客户端连接中出现连接很慢的话呢，也可以检查一下该配置文件的。