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

Posted 2022-06-24 xibuhaohao

作者简介

王睿操，平安好医数据库架构岗，多年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 FUNCTION
  find_bad_row(tableName TEXT)
  RETURNS tid
  as $find_bad_row$
DECLARE
  result tid;
  curs REFCURSOR;
  row1 RECORD;
  row2 RECORD;
  tabName TEXT;
  count BIGINT := 0;
BEGIN
  SELECT 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 LOOP
    result = row1.ctid;
    count := count + 1;
    FETCH curs INTO row1;
    EXECUTE ‘SELECT (each(hstore(‘ || tabName || ‘))).* FROM ‘
         || tableName || ‘ WHERE ctid = $1‘ INTO row2
         USING row1.ctid;
    IF count % 100000 = 0 THEN
      RAISE NOTICE ‘rows processed: %‘, count;
    END IF;
  END LOOP;

  CLOSE curs;
  RETURN row1.ctid;
  EXCEPTION
    WHEN OTHERS THEN
      RAISE 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中未提交事务进行回滚操作，笔者这个环境当时是因为缺失了归档，所以只能手动将混乱数据进行删除。

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

 

 

转载自：

http://blog.sina.com.cn/s/blog_67d069a90102vibc.html