本文经授权转载自 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 18446744073709551613pg_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 18446744073709551613find_bad_row--------------(78497,6)(1 row)
js1=# select * from xxxxxxx where ctid = '(78498,1)';ERROR: invalid memory alloc request size 18446744073709551613js1=# 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 来说备份就是生命啊，不管是测试库还是生产库一定要做好备份）
对数据库进行全库物理备份（为之后操作做保险）
用 dd 进行伪造这个数据块（数据块伪造全部提交）,并且更改权限
for i in {1..262144}; do printf '\125'; done > committedls -l committedod -xv committed | headod -xv committed | tail
$ ls -l committed-rw-r--r-- 1 root root 262144 2009-06-25 11:01 committed
$ od -xv committed | head0000000 5555 5555 5555 5555 5555 5555 5555 55550000020 5555 5555 5555 5555 5555 5555 5555 55550000040 5555 5555 5555 5555 5555 5555 5555 55550000060 5555 5555 5555 5555 5555 5555 5555 55550000100 5555 5555 5555 5555 5555 5555 5555 55550000120 5555 5555 5555 5555 5555 5555 5555 55550000140 5555 5555 5555 5555 5555 5555 5555 55550000160 5555 5555 5555 5555 5555 5555 5555 55550000200 5555 5555 5555 5555 5555 5555 5555 55550000220 5555 5555 5555 5555 5555 5555 5555 5555$ od -xv committed | tail0777560 5555 5555 5555 5555 5555 5555 5555 55550777600 5555 5555 5555 5555 5555 5555 5555 55550777620 5555 5555 5555 5555 5555 5555 5555 55550777640 5555 5555 5555 5555 5555 5555 5555 55550777660 5555 5555 5555 5555 5555 5555 5555 55550777700 5555 5555 5555 5555 5555 5555 5555 55550777720 5555 5555 5555 5555 5555 5555 5555 55550777740 5555 5555 5555 5555 5555 5555 5555 55550777760 5555 5555 5555 5555 5555 5555 5555 55551000000
chown postgres.postgres committedchmod 600 committedmv -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 $$declarev_rec record;BEGINfor v_rec in SELECT * FROM pg_statistic loopraise 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
评论