Как исправить Postgres, чтобы он запускался после внезапного выключения? - PullRequest
Новая
       25

Как исправить Postgres, чтобы он запускался после внезапного выключения?

16 голосов
/ 28 февраля 2009

Из-за внезапного отключения питания сервер PostGres, работающий на моей локальной машине, внезапно отключился. После перезагрузки я попытался перезапустить postgres, и я получаю эту ошибку:

$ pg_ctl -D /usr/local/pgsql/data restart

pg_ctl: PID file "/usr/local/pgsql/data/postmaster.pid" does not exist
Is server running?
starting server anyway
server starting
$:/usr/local/pgsql/data$ LOG:  database system shutdown was interrupted at 2009-02-28 21:06:16 
LOG:  checkpoint record is at 2/8FD6F8D0
LOG:  redo record is at 2/8FD6F8D0; undo record is at 0/0; shutdown FALSE
LOG:  next transaction ID: 0/1888104; next OID: 1711752
LOG:  next MultiXactId: 2; next MultiXactOffset: 3
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  redo starts at 2/8FD6F918
LOG:  record with zero length at 2/8FFD94A8
LOG:  redo done at 2/8FFD9480
LOG:  could not fsync segment 0 of relation 1663/1707047/1707304: No such file or directory
FATAL:  storage sync failed on magnetic disk: No such file or directory
LOG:  startup process (PID 5465) exited with exit code 1
LOG:  aborting startup due to startup process failure

В каталоге данных нет файла postmaster.pid. Что может быть причиной такого поведения и, конечно, каков выход?

Ответы [ 4 ]

19 голосов
/ 02 марта 2009

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

Причиной этого может быть:

  • Вы не выключили аппаратное обеспечение записать кеш на диск, который часто не позволяет операционной системе убедиться, что данные записаны до того, как она сообщит об успешной записи в приложение. Проверьте с

    hdparm -I /dev/sda

    Если он показывает «*» перед «Запись в кэш», то это может иметь место. Источник PostgreSQL имеет программу src / tools / fsync / test_fsync.c, которая проверяет скорость синхронизации данных с диском. Запустите его - если он сообщает все время короче, скажем, за 3 секунды, чем ваш диск лежит на ОС - на дисках со скоростью 7500 об / мин тест 1000 записей в одно и то же место может занять не менее 8 секунд (1000 / (7500 об / мин 60-е годы)) так как писать можно только один раз за маршрут. Вам нужно отредактировать этот test_fsync.c, если ваша база данных находится на другом диске, чем раздел / var / tmp - измените

    #define FSYNC_FILENAME "/var/tmp/test_fsync.out"

    до

    #define FSYNC_FILENAME "/usr/local/pgsql/data/test_fsync.out"

  • Ваш диск неисправен и имеет плохой блок, проверьте с помощью badblocks .

  • У вас плохое ОЗУ, проверьте по memtest86 + не менее 8 часов.

6 голосов
/ 28 февраля 2009

Чтение нескольких похожих сообщений в архивах PostgreSQL список рассылки («сбой синхронизации хранилища на магнитном диске: такого файла нет или каталог "), кажется, указывает, что есть очень серьезное оборудование Беда, намного хуже, чем простой сбой питания. Возможно, вам придется подготовиться к восстановлению из резервных копий.

1 голос
/ 30 апреля 2018

У меня тоже была дБ коррупция, мои действия 

docker run -it --rm -v /path/to/db:/var/lib/postgresql/data postgres:10.3 bash
su - postgres
/usr/lib/postgresql/10/bin/pg_resetwal -D /var/lib/postgresql/data -f
0 голосов
/ 07 августа 2009

Запустите запуск вместо перезапуска. Выполните следующую команду: 

$pg_ctl -D /usr/local/pgsql/data start
...