отладка Postgres 9.0.1 таблицы повреждения - PullRequest
Новая
       20

отладка Postgres 9.0.1 таблицы повреждения

0 голосов
/ 14 апреля 2011

У меня есть база данных 9.0.1 с двумя поврежденными таблицами (одна таблица имеет 20 строк, а другая 140). Таблицы кажутся хорошими для операций чтения / выбора, но обновление определенных строк в таблице приводит к сообщениям об ошибках: 

update media set updated_at = now() at time zone 'UTC';

ОШИБКА: не удалось прочитать блок 2 в файле "base / 16384/16485": только чтение 0 из 8192 байтов 

update media_status set updated_at = now() at time zone 'UTC';

2011-04-14 00:15:15 UTC ОШИБКА: не удалось прочитать блок 3 в файле «base / 16384/16543»: только чтение 0 из 8192 байтов
2011-04-14 00:15:15 UTC ЗАЯВЛЕНИЕ: обновить набор media_status updated_at = now () в часовом поясе UTC;

Изучение поврежденных файлов в файловой системе (linux), они не равны нулю: Базы / 16384/16485 -rwx ------ 1 postgres postgres 16384 2011-04-07 09:43 base / 16384/16485

Я выполнил команду «вакуум (FULL, VERBOSE)», и повреждение (или, по крайней мере, ошибки при обновлении) исчезло. Ожидается ли, что команда «вакуума (FULL)» может / могла бы исправить повреждение таблицы? Предоставляет ли это какие-либо подсказки относительно того, что могло произойти?

Есть ли способ определить, как / когда могло произойти это повреждение?

Я подозреваю, что это могло произойти во время резервного копирования на уровне файловой системы (т.е. pg_start_backup (), tar -czf ..., pg_stop_backup ()), поскольку я выполнял резервное копирование и перемещал базу данных в другую систему. После восстановления файлов и запуска postgres я начал получать эти ошибки. Я пытался восстановить несколько раз с одним и тем же архивом tar с одинаковыми результатами (на разных системах).

Спасибо, Dan

1 Ответ

1 голос
/ 14 апреля 2011

Трудно сделать однозначное заявление об этой ситуации, но я бы исследовал уровень хранения.Короткие чтения, такие как сообщение об ошибке, обычно указывают на то, что «не может произойти» в локальном, обычно подключенном хранилище.Поэтому, если у вас есть SAN, NAS, NFS, некоторая нетривиальная конфигурация RAID или что-то еще интересное, проверьте журналы или счетчики ошибок там.

Если файлы есть, то это означает, что это не повреждениевнутри PostgreSQL.

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

Тот факт, что VACUUM FULLИсправлено это было, вероятно, только потому, что это полностью переписывало таблицу в новые файлы, поэтому все, что вызывало сбои со старыми файлами, исчезло.

...