PostgreSQL физические сбойные блоки и коррупции файл Примеры

Об авторе

Ван Жуйте упражнение , хорошая схема базы данных здоровья Ping Kong, эксплуатация и техническое обслуживание в течение многих лет работы в области развития базы данных PostgreSQL. Работали Информация гражданской авиации, Decathlon Китай. Есть также некоторые другие продукты , базы данных , охватываемые.

фон

Недавно я нашел много друзей, часто встречаются плохие блоки или путаница данных PostgreSQL, онлайн китайские данные относительно невелики, поэтому заказать немного, я обнаружил ошибку и разнообразие решений

Случай I: Физическая плохой блок

Будучи дано логическое резервное копирование

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

Причина: база данных плохой линии (оборудование может быть повреждено и может быть ошибка (часть перед памятью переопределена случайные данными версии pg9.2), может быть неправильной конфигурацией аппаратных средств)

Прежде всего, я считаю, что пг собственных параметров zero_damaged_pages, этот параметр так, но все-таки нашла ошибку, заглянула под официальными документами, этот метод не делает физические изменений в файл, но в памяти, кэш повреждена страница 0. Если этот способ устранил ошибку, пожалуйста, возобновить эту таблицу обратно, или выбрать другую таблицу.

Решение: удалить поврежденную линию

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)';

Должны быть обработаны в виде хххх нас здесь

3, а затем выполнить команду pg_dump

Детальный анализ показывает: https://www.postgresql.org/message-id/54889986.3000308%40gmail.com

Случай II: pgclog файл с коррупцией из-за перебоев в подаче электроэнергии

повреждение pg_clog

Сообщение об ошибке:Could not read from file ""pg_clog/0646"" at offset 243287

Аномальное выключения питание сервера, это происходит потому, что тестовые библиотеки, поэтому нет резервного копирования и библиотечного оборудования (дБ так и для резервного копирования это жизнь ах, является ли это испытание или производства базы данных библиотека должна сделать резервную копию)

База данных библиотеки полное физическое резервное копирование (для этого после операции страхования)
Блок подделки данных (блок данных, Commit все подлог), а также изменить разрешение с дд

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

Обратите внимание, что это может решить только эту проблему, не может восстановить повреждения основного файла, так что если у вас есть резервное копирование или резервное копирование и восстановление лучше.

Случай III: повреждение тост таблицы

missing chunk number x for toast value x in pg_toast_x

Связанный с конкретной таблицей тостом искажением данных таблиц

Решение цитируется: http://m.2cto.com/database/201802/720718.html

1, позиционирование тосты, какие таблицы в вопросе:

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. На данный момент, тостов проблема решается через, после решен, ведение базы данных или полный индекс восстановления.

На самом деле, вообще говоря, база данных не будут идти добровольно представленными в соответствии архивировать или операцию валь Postgres отката транзакции, я был в этой среде из-за отсутствие архивирования, данные может быть удалена только вручную путаница.

Наконец, я хочу сказать, что во многих случаях, потому что нет никакого надежного резервного копирования и привести ко многим проблемам, рекомендуется, чтобы каждый, независимо от того, какая ситуация, резервная первая, проверьте подпорку не очень важно!

Перепечатано из:

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