Postgresql error PANIC: не удалось найти действительную запись контрольной точки

Ответ 1

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

pg_resetxlog DATADIR 

Если журнал транзакций поврежден, вы увидите сообщение типа:

Сервер базы данных не был закрыт чисто. Сброс журнал транзакций может привести к потере данных. Если вы хотите продолжить в любом случае, используйте -f, чтобы заставить reset.

Затем вы можете следовать инструкциям и запускать с помощью -f для принудительного обновления:

pg_resetxlog -f DATADIR 

Это должно reset журнал транзакций, однако он может оставить вашу базу данных в неопределенном состоянии, как описано в документации PostgreSQL на pg_resetxlog:

Если pg_resetxlog жалуется, что он не может определить действительные данные для pg_control, вы можете заставить его действовать в любом случае, указав переключатель -f (force). В этом случае допустимые значения будут заменены отсутствующими данными. Можно ожидать, что большинство полей будут совпадать, но может понадобиться ручная помощь для следующего идентификатора OID, следующего идентификатора транзакции и эпохи, следующего идентификатора мультизависимости и смещения, а также полей начального адреса WAL. Эти поля могут быть установлены с использованием переключателей, обсуждаемых ниже. Если вы не можете определить правильные значения для всех этих полей, -f все еще можно использовать, но восстановленная база данных должна обрабатываться с еще большим подозрением, чем обычно: немедленный сброс и перезагрузка необходимы. Не выполняйте какие-либо операции по модификации данных в базе данных до того, как вы сбросите, так как любое такое действие скорее всего ухудшит коррупцию.

Ответ 2

Я запускаю 9.1.7, и я нашел следующее успешно:

/usr/lib/postgresql/9.1/bin/pg_resetxlog -f /var/lib/postgresql/9.1/main

Конечным аргументом команды pg_resetxlog должно быть местоположение на диске, где postgres хранит данные вашей базы данных.

Ответ 3

Как указано , pg_resetxlog не должен запускаться. Ответы, которые относятся к этому, являются плохим советом. Предполагая, что ошибка произошла в контексте экземпляра копирования/репликации, ссылка обеспечивает более краткий способ копирования/репликации с помощью pg_basebackup

Ответ 4

Вы продолжаете архивирование? Если вы резервное копирование в то время, вы можете найти более разумным для удаления backup_label. pg_resetxlog - серьезная вещь.

Ответ 5

так же, как и запись в журнале: не удалось найти действительную запись контрольной точки. Постеры не могут найти правильный WAL в каталоге $PGDATA/pg_xlog/. Попробуйте использовать pg_resetxlog