今天业务系统遭遇了一起数据库故障. 数据库端报了一些错误.[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 在从库上是可以运行.
然后回来处理这个问题. 发现这个问题很棘手. 目前还没有成熟快速的套路.
借鉴 了同行们的几个方案均失败. 会跳过这个事务报错. 但是会报另一个错误. block head 损坏.
终极的解决方法. truncate table 或者drop table 然后从备份集中 恢复数据回去.
我们保留了现场: 然后进行了各种演练. 最终都是无解.
https://www.postgresql.org/message-id/alpine.GSO.2.01.0907231353180.6160@westnet.com
http://www.postgresql-archive.org/files-under-pg-clog-directories-are-missing-td2844464.html
我们初步认为 .这是一个数据库中行数据的物理损坏, 对应于oracle 的数据块的物理损坏.
oracle 中会有一个比较完善的报错,诊断机制. 会报 block 损坏.
pg 这里的这个报错.我么猜测是 数据的物理损坏导致 min max 的事务状态的记录溢出 .
因为报错中请求的 应该存在于去年的clog 目录下面才对.
我们最小的clog 文件 03D1 是2017年一月9号的. 这其中已经过了 8个多月了. 对一个频繁访问的业务表.
去年丢的某个日志, 不应该到现在才报错. 然后同步的从库是没有问题. 从库也没有0363 这个文件,但是却可以访问这些记录.
这业验证了.这个错误可能是数据记录 物理损坏了.如果是逻辑出错的话,应该会通过事务日志传递到从库.
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/133735/viewspace-2142485/，如需转载，请注明出处，否则将追究法律责任。