记一次PG引发的生产故障

微信扫一扫,分享到朋友圈

记一次PG引发的生产故障

前几天,突然收到报修,一个文件接收服务突然宕了。

我们运维同事很快就进行了重启,此时怪异的事情发生了:

重启服务后,服务一会儿就没响应了,端口可以通,文件全部上传失败,没有任何异常日志输出。

那就排查吧:

1、PG数据库连接正常,无死锁,表空间正常,数据查询秒回

2、服务配置几个月都没人改过,CPU、内存、存储、IO、网络,全部正常

3、上传客户端日志输出,显示其工作正常

4、只有文件接收服务,没有响应,也没有日志输出

初步判断,文件接收服务出问题了。

于是,新开一个云主机,重新安装服务,仍然无响应。

然后,拷贝了一个正常工作的主机,修改配置后,仍然无响应。

来来回回折腾了几个小时,还是不行。

无奈之余,试了一下向PG数据库插入数据,我去,几十秒都没有响应。

赶快问DBA,原来是做了高可用,主从库数据同步,从库异常了,导致主库可读不可写。

众人皆表示无奈,重启从库,问题解决。

其实,一开始就排查数据库了,但由于是生产库,只试过查询,没有试过写入。

但是,我们都大意了:

1、服务日志,输出不够详细,就算DEBUG打开,也不知道数据进行到哪一步了,这个最坑

2、没有正确的设置超时时间,原因是接收文件后,写入数据库一直在等待,服务日志没有任何数据库异常

3、数据库监视软件,只做了主库监视,根本没做从库监视

4、数据库主从配置,本应该是异步,但现在配置成了同步

5、没有监视主从库同步的情况

6、生产库,不敢轻易进行写操作,只看了查询效率及死锁,没有看慢语句

就这样一个小问题,绕过了层层监控机制,让问题排查十分困难,花费了大量的人力。

反思起来,如果只是为了记录日志而记录日志,但日志不能反应服务状态,那不如不记;如果只是为了监控而监控,但监控不到位,那不如不监控。

我们日常做事情,也是同样的道理,细节是魔鬼,把该把控的把控好了,才能提升效率,得到想要的结果。

微信扫一扫,分享到朋友圈

记一次PG引发的生产故障

nginx 1.19.3 主线版发布

上一篇

英国发射板载超算的纳米卫星 可精准追踪和预测船舶动向

下一篇

你也可能喜欢

记一次PG引发的生产故障

长按储存图像,分享给朋友