凌晨两点十七分，监控大屏上那个代表pubdata服务的绿色图标突然变成了刺眼的红色。数据库连接失败，pubdata服务中断，这八个字像一盆冷水泼在值班工程师脸上。你要是干过运维这行，肯定懂这种心跳漏一拍的感觉——不是因为半夜被叫醒有多烦，而是你知道，接下来的一两个小时，可能要在日志文件和命令行之间反复折腾了。
先说清楚pubdata是干嘛的。它不是什么花哨的中间件，就是负责把业务系统产生的结构化数据统一收口，再分发给下游分析平台的那个枢纽站。订单数据、用户行为日志、设备上报信息，全都得从这个口子过。一旦它连不上数据库，整个数据管道就堵住了，下游报表全是空的，业务方那边可能已经炸开锅了。所以排查这事，拼的就是速度和准确性。
第一步，别急着去翻业务代码，先确认最基础的事：数据库进程到底活着没。用systemctl status或者ps aux grep 5432，看看是不是监听在正确的IP和端口上。很多时候所谓连接失败，其实是数据库服务重启后忘了设listenaddresses，默认只绑了localhost，pubdata从别的机器连过来自然被拒。
端口通了，连接还是报错，那就得看连接池了。pubdata一般会配一个连接池，比如HikariCP或者Druid，池子里的连接数是有限的。如果某个上游接口突然发疯，一次性拿了五千个连接不释放，池子被占满，新的请求就只能排队等超时。这时候看连接池的监控指标最直观，active-count顶到上限，idle-count归零，基本就是这情况。解决办法也简单，调大最大连接数，但别只顾着调大——真正该做的是揪出那个不释放连接的程序，给它加上try-with-resources或者finally块里close()。
连接池没问题，那就往认证和权限方向想。pubdata连数据库用的账号，是不是密码过期了？或者某个DBA手滑，把pubdata账号的远程访问权限给revoke了？这种坑我踩过不止一次：业务代码没动过，昨天还好好的，今天突然连不上，查到发现是数据库侧跑了个定时任务，把过期账号给清理了，而pubdata的账号正好命中了清理规则。所以排查的时候，登录数据库查一下user表，确认账号状态是active，再查一下host授权，确保pubdata所在服务器IP在允许列表里。
网络层面也得看一眼。别笑，真有人连防火墙都没查就闷头改代码改了俩小时。pubdata服务器到数据库服务器之间的连通性，用telnet或者nc测一下端口，通不通一目了然。如果中间有安全组或者iptables规则，记得确认是不是有人刚加了一条drop规则。还有就是VPN或者专线——有些公司办公网和机房之间走的是VPN，VPN断了，连接自然失败。这种情况在日志里往往表现为connect timeout而不是connection refused，因为包直接被丢了，根本没到数据库那边。
还有一种容易忽略的情况：DNS解析。pubdata配置里如果用的是主机名而不是IP，那DNS一抽风，解析出来的地址是错的，连接也会失败。排查方法很简单，在pubdata服务器上ping一下数据库主机名，看解析出来的IP对不对。之前遇到过一台内部DNS服务器缓存了旧的记录，数据库迁移后IP早换了，但DNS里还是老地址，结果pubdata这边死活连不上。清缓存或者改配置成新IP，问题秒解。
如果以上全查了一遍还没头绪，那就得看数据库自身的负载了。连接数太多导致maxconnections被打满，或者磁盘满了导致数据库无法写入新事务，这些都会让连接失败。查一下pgstatactivity（PG）或者show processlist（MySQL），看看有没有大量sleep状态的连接堆积。磁盘的话df -h看一眼使用率，超过90%就该警惕了。数据库日志也别放过，PostgreSQL的log目录下会有详细的错误信息，有时候一条“sorry, too many clients already”就直接告诉你了答案。
想说，排查这种事，最忌讳的就是东一榔头西一棒子。按顺序来：进程→端口→连接池→认证→网络→DNS→负载→日志，每查一步就排除一个可能。pubdata服务中断虽然吓人，但只要思路清晰，大多数情况下十分钟内就能定位问题。等你把这次故障处理完，记得写个排查文档存下来，下次再遇到，照着走就行。毕竟数据库连接失败这种事，谁都不想同一个坑踩两次。
