1. 问题描述
某日，生产环境的应用服务器161连不上数据库服务169（CentOS）了。于是，系统崩溃，页面报错，各种问题叠加，甲方爸爸的雷霆之怒铺天盖地而来。
咳咳...说多了，本文不讲故事，只说技术，让我们言归正传。
2. 第一次排查
2.1 第一步
在应用服务器161上，ping 169，不通，telnet 169的数据库端口，不通。整个人的精神状态都不好了。这TM DE也没人动过呀，咋就这样了？
2.2 第二步
SSH登录数据库服务器169，登不上去了。联系服务器厂商，看云控平台上服务器的状态如何，人家说169的网通着呢。
3. 第二次排查
3.1 第一步
线下跑去机房，抱着显示器、键盘、鼠标，到机柜上去，插上键盘鼠标，接上显示器，看数据库服务器169，进行了一次全方位体检，包括看进程、看日志、本地登录等等，能试的都试了，一切正常。
3.2 第二步
胆子大一点，关闭数据库服务器169上的防火墙，再去应用服务器161上试，仍然连不上。
3.3 第三步
在应用服务器161上对来自应用服务器161的连接进行授权，然后从数据库服务器169上远程连接应用服务器161，看这个反向连接能不能成功。失败。
现在结论很清楚：应用服务器161和数据库器169之间的网络不通！ 但是为啥不通？为啥这样了？不知道！
4. 第三次排查
4.1 第一步
检查应用服务器161连接其他服务器有无异常，结论：一切正常，能连，包括redis都还连着呢，没啥问题。包括另外一台相对空闲的服务器163，从应用服务器161连这个空闲的163没问题，从空闲的163连数据库服务器169也没问题。
真是RLGL，其他服务器到数据库服务器169没问题，只有应用服务器161到数据库服务器169不通。
4.2 第二步
胆子再大一点，重置数据库服务器169的网格连接，重启网卡。结论：问题未解决，故障依旧。
4.3 第三步
我突然想到一招儿，应用服务器161能连空闲的163，这空闲的163也能连数据库服务器169，那么我在空闲的163上挂一个代理，应用服务器161现在去不了169了，那就去163吧，绕个路，先通再说。于是在空闲的163上配traefik代理，TCP挂上，端口授权，能做的都做了。
然而，结论是不行，理论上可行，但是软件中会报错，报的是JDBC中的字符串处理越界了，改各种配置，各种尝试都不行。我甚至在应用服务器161上又临时写了一个测试程序去连这个代理，都没问题，就是现有的这个客户软件系统连这个代理会报错，原因不明。WXS啊！！！
5. 最后的挣扎，我拼了
5.1 第一步
再找服务器厂商排查网络，人家仍然给我们看云控平台，一切正常。
5.2 终极主张
找了块大大的硬盘，在数据库服务器169上，把数据库中的数据全都导出来，然后重装系统，重装公共软件，重装数据库软件，重新配置网络，再把数据导进去，这一折腾，就是七八个小时，加上前面浪费的时间，两天过去了，本次系统崩溃时间已经逼近48个小时......
到目前为止，这个过程仍然没有完成，数据库都还没有装好呢，系统仍然没有能够恢复正常。
甲方爸爸说，要不他给我跪下，我浑身汗如雨下，不敢应声，半晌，壮着胆子颤颤巍巍地说：“要不再等等？”
啪！
