PostgreSQL pg-xact（clog）目录文件缺失处理

 一、 背景

        前些天晚上突然收到业务反馈，查询DB中的一个表报错

Could not open file "pg-xact/005E": No such file or directory.

         两眼一黑难道是文件损坏了...登录查看DB日志，还好没有其他报错，业务也反馈只有这一个表在从库查询报错，主库正常，于是开始分析处理。

二、 解决方法

根据搜索结果看，这个问题基本就两种处理方法，这里先列出来。

1. 数据库恢复

       如果数据库小，或者对数据一致性要求高，建议的方法还是进行恢复，因为方法二实际对数据一致性是有损的。

2. 新建空文件

报错是文件没了，所以解决方法是手动建回去（记得先确认权限）

#postgres用户执行
dd if=/dev/zero of=$PGDATA/pg_xact/005E bs=256k count=1
chmod 600 $PGDATA/pg_xact/005E

风险

       clog存事务的最终状态信息，就是这个事务最终是提交了还是回滚了，建一个空的文件，相当于文件里的事务不知道它提交还是回滚了，理论上会出现数据不一致。

三、 CLOG的原理及作用

postgresql源码学习（51）—— 提交日志CLOG 原理 用途 管理函数-CSDN博客

四、 遗留问题

这个报错为什么会突然出现，目前还没查到相关资料

1. 现场情况

• 报错PG版本为10.5，从库查询报错，主库不报错
• 报错中要找的clog为005E，txid为 99185979
• 报错数据库最旧的clog为0269，并且已经是两个月前的

• 报错数据库当前txid为 9436969370，远远大于报错的

一个小补充：为什么查出来的txid是94亿多，远远大于了42亿，实际上txid的计算有一个转换，转完之后大概是8亿多。

select (txid_current() % (2^32)::bigint)::text::xid;

• 当时数据库中最老的表年龄大概是1.9亿，并且不是报错的这个表

2. 一些猜测

       从现场情况来看，005E文件应该是PG正常删除，而非误删或文件系统损坏导致不可访问。

       奇怪的是为什么查询该表会访问这么旧的文件，从事务年龄来看，这不应该是个正常的访问，比较怀疑还是遇到了奇怪的bug。

参考

PostgresQL-丢失各种数据文件如何恢复 - binbinx - 博客园