PostgreSQL 物理坏块和文件损坏案例分享

本文经授权转载自 PostgreSQL 中文社区

笔者最近发现很多朋友经常遇到 PostgreSQL 坏块或者数据混乱的情况，网上中文资料比较少，于是笔者整理了一下遇到的各种各样报错以及解决方案。

案例一：物理坏块

逻辑备份时报错

 复制代码

pg_dump: Dumping the contents of table "xxxx" failed: PQgetResult() failed.
pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613
pg_dump: The command was: COPY xxxxxx (id, active_flag, bkd, blk, go_show, grs, lss, lsv, lt, no_show, value, wl, inv_seg_cabin_id, ind) TO stdout;
pg_dump: [parallel archiver] a worker process died unexpectedly

原因：数据库产生坏行（可能是硬件损坏，可能是一个 bug(piece of memory gets overwritten by random data pg9.2 之前版本)，也有可能是不正确的硬件配置）

首先笔者考虑了 pg 自带参数 zero_damaged_pages，将这个参数修改为 true，但发现仍然是报错，看了下官方文档，这种方法不会对物理文件作修改，只是把内存上，损坏页面的缓存变为 0。如果这个方法解决了报错，请将这表备份出来重新恢复，或者 select 到另一张表。

解决方式：删除损坏行

create extension hstore；（过程省略）

1、定义函数：

 复制代码

CREATE OR REPLACE FUNCTIONfind_bad_row(tableName TEXT)RETURNS tidas $find_bad_row$DECLAREresult tid;curs REFCURSOR;row1 RECORD;row2 RECORD;tabName TEXT;count BIGINT := 0;BEGINSELECT reverse(split_part(reverse($1), '.', 1)) INTO tabName;OPEN curs FOR EXECUTE 'SELECT ctid FROM ' || tableName;count := 1;FETCH curs INTO row1; WHILE row1.ctid IS NOT NULL LOOPresult = row1.ctid;count := count + 1;FETCH curs INTO row1; EXECUTE 'SELECT (each(hstore(' || tabName || '))).* FROM '|| tableName || ' WHERE ctid = $1' INTO row2USING row1.ctid;IF count % 100000 = 0 THENRAISE NOTICE 'rows processed: %', count;END IF;END LOOP;CLOSE curs;RETURN row1.ctid;EXCEPTIONWHEN OTHERS THENRAISE NOTICE 'LAST CTID: %', result;RAISE NOTICE '%: %', SQLSTATE, SQLERRM;RETURN result;END$find_bad_row$LANGUAGE plpgsql;

2、通过函数查找问题行：

 复制代码

js1=# select find_bad_row('public.description');
NOTICE: LAST CTID: (78497,6)
NOTICE: XX000: invalid memory alloc request size 18446744073709551613
find_bad_row
--------------
(78497,6)
(1 row)

js1=# select * from xxxxxxx where ctid = '(78498,1)';
ERROR: invalid memory alloc request size 18446744073709551613
js1=# delete from xxxxxx where ctid = '(78498,1)';

在这里我们需要对 xxxx 表格进行处理

3、然后再执行 pg_dump 命令

详细分析可见：

https://www.postgresql.org/message-id/54889986.3000308%40gmail.com

案例二：pgclog 因断电文件损坏

pg_clog 损坏

报错信息：Could not read from file "“pg_clog/0646"” at offset 243287

服务器异常断电，这台因为是测试库，所以没备份以及备库（所以对于 dba 来说备份就是生命啊，不管是测试库还是生产库一定要做好备份）

1. 对数据库进行全库物理备份（为之后操作做保险）

2. 用 dd 进行伪造这个数据块（数据块伪造全部提交）, 并且更改权限

 复制代码

for i in {1..262144}; do printf '\125'; done > committed
ls -l committed
od -xv committed | head
od -xv committed | tail

$ ls -l committed
-rw-r--r-- 1 root root 262144 2009-06-25 11:01 committed

$ od -xv committed  | head
0000000 5555 5555 5555 5555 5555 5555 5555 5555
0000020 5555 5555 5555 5555 5555 5555 5555 5555
0000040 5555 5555 5555 5555 5555 5555 5555 5555
0000060 5555 5555 5555 5555 5555 5555 5555 5555
0000100 5555 5555 5555 5555 5555 5555 5555 5555
0000120 5555 5555 5555 5555 5555 5555 5555 5555
0000140 5555 5555 5555 5555 5555 5555 5555 5555
0000160 5555 5555 5555 5555 5555 5555 5555 5555
0000200 5555 5555 5555 5555 5555 5555 5555 5555
0000220 5555 5555 5555 5555 5555 5555 5555 5555
$ od -xv committed  | tail
0777560 5555 5555 5555 5555 5555 5555 5555 5555
0777600 5555 5555 5555 5555 5555 5555 5555 5555
0777620 5555 5555 5555 5555 5555 5555 5555 5555
0777640 5555 5555 5555 5555 5555 5555 5555 5555
0777660 5555 5555 5555 5555 5555 5555 5555 5555
0777700 5555 5555 5555 5555 5555 5555 5555 5555
0777720 5555 5555 5555 5555 5555 5555 5555 5555
0777740 5555 5555 5555 5555 5555 5555 5555 5555
0777760 5555 5555 5555 5555 5555 5555 5555 5555
1000000

chown postgres.postgres committed
chmod 600 committed
mv -i committed $PGDATA/pg_clog/0646

注意这个只能解决这个问题，不可以修复底层文件的损坏，所以如果有备份还是备份还原比较好。

案例三：toast 表损坏

missing chunk number x for toast value x in pg_toast_x

某张表关联的 toast 表发现数据损坏

解决方案引自： http://m.2cto.com/database/201802/720718.html

1、定位是哪张表的 toast 有问题：

 复制代码

select 2619::regclass; 
   regclass   
--------------
 pg_statistic

2、找到哪个表有问题后，先对该表做一下简单的修复：

 复制代码

REINDEX table pg_toast.pg_toast_2619;
REINDEX table pg_statistic;
VACUUM ANALYZE pg_statistic;

3、定位该表中损坏的数据行。执行

 复制代码

DO $$
declare
v_rec record;
BEGIN
for v_rec in SELECT * FROM pg_statistic loop
raise notice ‘Parameter is:‘, v_rec.ctid;
raise notice ‘Parameter is:’, v_rec;
end loop; 
END;
$$
LANGUAGE plpgsql;

4、将第 3 步中定位的记录删除:

 复制代码

delete from pg_statistic where ctid =‘(50,3)’;

5、重复执行第 3,4 步，直到全部有问题的记录被清除。

6、至此，toast 问题就解决完了，解决之后，对数据库进行一次完整的维护或者索引重建。

其实一般来说，数据库会根据归档或者 wal 去自行将 postgres 中未提交事务进行回滚操作，笔者这个环境当时是因为缺失了归档，所以只能手动将混乱数据进行删除。

最后笔者想说，很多情况下都是因为没有一个靠谱的备份而导致很多问题，所以建议大家不管什么情况，备份为先，检查备份很重要！

作者介绍：

王睿操，平安好医数据库架构岗，多年 postgresql 数据库运维开发工作。曾就职于中国民航信息，迪卡侬。对其他数据库产品也有一定的涉猎。

原文链接：

https://mp.weixin.qq.com/s/mBLxAfVT6_cDOAOD8J0_aw