Я получаю сообщение об ошибке
ERROR: invalid page header in block 411 of relation "t_value_time"
в моей базе данных PostgreSQL. Это происходит на разных машинах. Есть ли способ предотвратить это, или, по крайней мере, сказать, что PSQL игнорирует данные о недопустимом блоке и перемещается?
Я бы скорее потерял данные из блока и попросил его пропустить его, читая остальную часть данных. Есть ли способ сказать PSQL пропустить этот блок?
ПРЕДУПРЕЖДЕНИЕ: вы потеряете некоторые данные!
Нам удалось преодолеть это (разбился 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.
Тот же блок каждый раз?
Из того, что я прочитал, наиболее распространенной причиной недопустимых блоков является аппаратное обеспечение. У Red Hat есть утилита, pg_filedump, которая форматирует "кучи, индексы и управляющие файлы PostgreSQL в удобочитаемую форму". Я не думаю, что они поддерживают версию PostgreSQL, большую, чем 8.4.0, но я могу ошибаться.
Вы хотите доказать, что ваше оборудование хорошо, используя жесткую диагностику диска, RAM и NIC.
Нет простого способа сделать это, но это достаточно просто сделать, просто отредактировав файл данных напрямую (relfilenode записи pg_class дает имя файла).
Просто скопируйте блок из другого места в файле по плохим блокам. В идеале, синтезируйте пустой блок или обновите тот, который вы переписываете, чтобы в нем не было допустимых кортежей.
Как только у вас есть что-то, что не создает эту ошибку, сбросьте таблицу и перезагрузите ее для безопасности.
это почти всегда проблемы с оборудованием. Проверьте и протестируйте RAM, диск, CPU. Удостоверьтесь, что ваша среда хорошая (плохой вход питания может вызвать проблемы, так как может перегреться). Это лучший способ предотвратить это. Лучшим способом решения этой проблемы является восстановление времени от базовой резервной копии.
Если у вас есть подчиненное устройство, установите для hot_standby_feedback значение "on", если это еще не сделано. Сделайте pg_dump и запишите его в /dev/null, чтобы не занимать место. nohup pg_dump db_name -v -f c -f/dev/null & Если дамп успешен, то с вашим ведомым все в порядке. Сделать аварийное переключение Там не будет никакой потери данных.
Еще один способ проверить ваше ведомое устройство - это объяснить select count (*) из table_name; Если это удастся, и если он использует сканирование последовательности, то ваш раб исправен. Возможно, вам не придется рассматривать эту опцию, если она использует сканирование индекса.
Примечание. Это работает, только если ваш мастер подвержен повреждению на уровне хранилища.
Я столкнулся с той же проблемой только сегодня, и я смог ее исправить.