PostgreSQL: неверный заголовок страницы в блоке

Question

В моей базе данных PostgreSQL появляется ошибка

ERROR:  invalid page header in block 411 of relation "t_value_time"

.Это происходит на разных машинах.Есть ли способ предотвратить это или, по крайней мере, сказать PSQL игнорировать данные в недействительном блоке и двигаться дальше?Чтение остальных данных.Есть ли способ сказать PSQL пропустить этот блок?

Answer 1

ВНИМАНИЕ: Вы потеряете некоторые данные!

Нам удалось преодолеть это (сбой DEV VM), выполнив:

database=# SET zero_damaged_pages = on;
SET
database=# VACUUM FULL damaged_table;
WARNING: invalid page header in block xxx of relation base/yyy/zzz; zeroing out page
[..]
REINDEX TABLE damaged_table;

Исправить через pwkg.ork .

Answer 2

Каждый раз один и тот же блок?

Из того, что я прочитал, наиболее распространенной причиной неправильных блоков является аппаратное обеспечение.Red Hat имеет утилиту pg_filedump , которая форматирует «кучу, индекс и управляющие файлы PostgreSQL в удобочитаемую форму».Я не думаю, что они поддерживают какую-либо версию PostgreSQL, превышающую 8.4.0, но я могу ошибаться.

Вы хотите доказать, что ваше оборудование хорошо, используя жесткую, тщательную диагностику диска, ОЗУ и NIC.

Answer 3

Нет простого способа сделать это, но это достаточно просто сделать, просто отредактировав файл данных напрямую (relfilenode записи pg_class дает имя файла).

Просто скопируйте блок из другого места файла поверх поврежденного блока. В идеале синтезируйте пустой блок или обновите тот, который вы перезаписываете, чтобы в нем не было допустимых кортежей.

Как только вы получите что-то, что не приводит к этой ошибке, сбросьте таблицу и перезагрузите ее для безопасности.

Answer 4

Если у вас есть подчиненное устройство, установите для hot_standby_feedback значение «on», если это еще не сделано.Сделайте pg_dump и запишите его в / dev / null, чтобы не занимать место.nohup pg_dump db_name -v -Fc -f / dev / null & Если дамп успешен, то с вашим ведомым все в порядке.Сделать аварийное переключениеПотери данных не будет.

Еще один способ проверки вашего ведомого устройства - объяснить выбор счетчика (*) из table_name;Если это удастся, и если он использует сканирование последовательности, то ваш раб исправен.Возможно, вам не придется рассматривать эту опцию, если она использует сканирование индекса.

Примечание. Это работает, только если ваш мастер подвержен повреждению уровня хранилища.

Я столкнулся с той же проблемой только сегодня и смог ее исправить.

Answer 5

это почти всегда проблемы с оборудованием между прочим. Проверьте и протестируйте RAM, диск, процессор. Убедитесь, что ваше окружение хорошее (плохая потребляемая мощность может вызвать проблемы, а также перегрев) Это лучший способ предотвратить это. Лучший способ решить эту проблему - восстановление на момент времени из базовой резервной копии.