PG 数据库遭遇 pg_clog file missing 故障.

今天业务系统遭遇了一起数据库故障.  

数据库端报了一些错误.[code]
2017-07-24 00:16:25.514 CST,"pcauto","pcauto",24404,"192.168.11.60:49721",5974c895.5f54,1,"SELECT",2017-07-24 00:02:29 CST,4/149911010,0,ERROR,58P01,"could not access status of transaction 909258544","Could not open file ""pg_clog/0363"": No such file or directory.",,,,,
[/code]

从报错日志上看 好像是事务日志缺失了. 好大件事.  

然后发现对这个表的全部扫描也失败了.因为绕不过跟这个事务相关的几十行记录. 

然后发现这个事务涉及的sql 在从库上是可以运行.  

为了不阻塞业务, 于是启动了ha 切换. 

然后回来处理这个问题.   发现这个问题很棘手. 目前还没有成熟快速的套路. 

借鉴 了同行们的几个方案均失败. 会跳过这个事务报错. 但是会报另一个错误. block head 损坏. 

最终还是无法解决. 

终极的解决方法.  truncate table  或者drop table  然后从备份集中 恢复数据回去. 

我们保留了现场: 然后进行了各种演练. 最终都是无解. 

参考方案:  

https://www.postgresql.org/message-id/alpine.GSO.2.01.0907231353180.6160@westnet.com

根据 BRUCE  大神 在邮件列表中的一个回复:  

 http://www.postgresql-archive.org/files-under-pg-clog-directories-are-missing-td2844464.html

根据我们主从之间是sync 同步的. 

我们初步认为 .这是一个数据库中行数据的物理损坏, 对应于oracle 的数据块的物理损坏. 

oracle 中会有一个比较完善的报错,诊断机制. 会报 block 损坏. 

pg 这里的这个报错.我么猜测是 数据的物理损坏导致  min max 的事务状态的记录溢出 . 

因为报错中请求的  应该存在于去年的clog 目录下面才对. 

我们最小的clog 文件 03D1  是2017年一月9号的. 这其中已经过了  8个多月了. 对一个频繁访问的业务表.

去年丢的某个日志, 不应该到现在才报错. 然后同步的从库是没有问题. 从库也没有0363 这个文件,但是却可以访问这些记录. 

这业验证了.这个错误可能是数据记录 物理损坏了.如果是逻辑出错的话,应该会通过事务日志传递到从库. 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/133735/viewspace-2142485/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/133735/viewspace-2142485/