PostgreSQL 9.1 Hot Backup Ошибка: система базы данных запускается

Я какое-то время работал над горячим резервным копированием для Postgres 9.1 и столкнулся с постоянной проблемой. После перезапуска Postgres на подчиненном сервере файл журнала pgstartup и файл ежедневного журнала в каталоге pg_log считываются без ошибок. Однако, когда я пытаюсь войти в базу данных с помощью команды psql, я получаю сообщение об ошибке:

FATAL: система баз данных запускается.

Файл recovery.conf также не превращается в recovery.done. Я тщательно исследовал эту ошибку и постоянно находил один и тот же ответ: база данных не была полностью закрыта до того, как я попытался перезапустить Postgres. Единственный способ перезапустить Postgres - через service postgresql-9.1 restartили /etc/init.d/postgresql-9.1 restart. После того, как я получаю эту ошибку, я убиваю все процессы и снова пытаюсь перезапустить базу данных и все равно получаю ту же ошибку. Я в недоумении, куда идти отсюда и как решить эту проблему. Ниже приведен точный процесс, который я сделал для завершения горячего резервного копирования.

Конфигурации главного сервера:

pg_hba.conf, добавил строку:

репликация хоста postgres IPAddressOfSlaveServer trust

postgresql.conf:

wal_level = hot_standby
max_wal_senders = 5
listen_address = '*'
порт = 5432
max_wal_senders = 5
wal_keep_segments = 32

Конфигурации подчиненного сервера:

postgresql.conf:

hot_standby = вкл

recovery.conf:

standby_mode = вкл
primary_conninfo = host = IPAddressOfMasterServer
порт = 5432
пользователь = postgres
restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'

После настройки обоих серверов

Я переключаюсь на пользователя postgres на главном сервере и запускаю команды:

psql -c "Выбрать pg_start_backup ('label', true);";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data slave: /var/lib/pgsql/9.1/data \
        - исключить postmaster.pid
pgsql -c "select pg_stop_backup ();";

После синхронизации базы данных с подчиненным сервером

Я перезагружаю подчиненный сервер, и запуск не дает сбоя. Файл pgstartup.log гласит:

Успех. Теперь вы можете запустить сервер базы данных, используя:

    /usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
или
    /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l запуск файла журнала

файл журнала текущего дня, postgresql-Thu.log, читает:

Журнал: закрытие
Журнал: система базы данных выключена
Журнал: система базы данных была закрыта в процессе восстановления в 2012-4-10
Журнал: вход в режим ожидания
Журнал: восстановлен файл журнала "logFileName" из архива
Журнал: согласованное состояние восстановления достигнуто в 0 / BF0000B0
Журнал: повтор начинается с 0 / BF000020
Журнал: восстановлен файл журнала "logFileName" из архива
Журнал: неожиданный адрес страницы 0/85000000 в файле журнала 0, сегмент 192, смещение 0
Журнал: неожиданный адрес страницы 0/85000000 в файле журнала 0, сегмент 192, смещение 0
Журнал: потоковая репликация успешно подключена к основной

Я исследовал неожиданный pageaddr и из архивов postgres, насколько я понимаю, это вполне нормально и является одним из ожидаемых способов обнаружения конца WAL.

Любой совет будет принята с благодарностью.

Сообщение «Система базы данных запускается». не указывает на ошибку. Причина, по которой он находится на уровне FATAL, заключается в том, что он всегда попадает в журнал, независимо от настройки log_min_messages:

http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

После rsync вы действительно запускаете то, что показываете ?:

pgsql -c "select pg_stop_backup ();";

Поскольку там, насколько я знаю, нет pgsql исполняемого файла, который оставил бы резервную копию незавершенной, и ведомый никогда не вышел бы из режима восстановления. С другой стороны, может быть, вы действительно запустились psql, потому что в противном случае я не вижу, как ведомый мог регистрировать такие сообщения об успехе, как:

Журнал: согласованное состояние восстановления достигнуто в 0 / BF0000B0

и:

Журнал: потоковая репликация успешно подключена к основной

Вы пытались подключиться к рабу в этот момент? Что произошло?

Упоминаемое вами сообщение «Успех. Теперь вы можете начать ...» генерируется initdb, и его не следует запускать как часть настройки ведомого устройства; так что я думаю, вы можете быть смущены чем-то там. Я также обеспокоен этими явно противоречивыми утверждениями:

Единственный способ, которым я перезапустил Postgres, - это команды перезапуска службы postgresql-9.1 или /etc/init.d/postgresql-9.1. После того, как я получаю эту ошибку, я уничтожаю все процессы и снова пытаюсь перезапустить базу данных ...

Вы пытались остановить службу через служебный скрипт? Что произошло? Это может помочь в понимании журналов, если вы добавляете строки с дополнительной информацией. Мы используем:

log_line_prefix = '[%m] %p %q<%u %d %r> '

recovery.confСценарий выглядит странно. Вы копируете из основного каталога pg_xlog, активного ведомого каталога pg_xlog или из архивного каталога?

У меня были некоторые проблемы с этим, кроме того, что я был на 9.3, а не 9.1. В любом случае, исправление оказалось довольно тривиальным:

postgresql.confФайл был быть скопирован от ведущего к ведомому, и я оставить его без изменений на подчиненном. Я думал, что все, что вам нужно сделать, это добавить recovery.confфайл, и все будет работать (хорошо, что это было сделано, но я не мог войти на реплицированный подчиненный сервер, но он реплицировался).

Я отредактировал postgresql.confфайл раба и:

• закомментировал archive_mode=on
• закомментированная archiveкоманда; и
• закомментировал hot_standby=on

Это сделало это: я смог сделать базу данных сервером только для чтения, готовым принимать запросы только для чтения.

Существует сценарий pg_basebackup, который создаст каталог начальной загрузки для ведомого. Это каталог данных с базой данных в нем. Вам нужно изменить postgresql.confфайл, прежде чем его можно будет использовать в качестве ведомого устройства, как описано, что довольно просто для пост- pg_basebackupскрипта.

Интересно, что я решил это противоположным образом, как это сделал Пол.

Я добавил:

hot_standby = on

или, скорее, изменилось #hot_standby = offна выше. (Это было с использованием 9,5)

Я получил это в журналах:

MSK FATAL:  the database system is starting up

Чтобы исправить бесконечный запуск сервера, сделайте следующее: остановите службу (если существует), уничтожьте процесс 'postgres' (обычно он существует). Запустите это в консоли:

pg_resetxlog.exe -D ../Data -f

Это связано с тем, что в каталоге xLog есть данные, которые не будут записаны до закрытия службы. А затем при запуске службы он пытается исправить эти данные. Иногда это останавливает запуск и никогда не заканчивается. Команда при чистке убирает эти незафиксированные данные, которые применяют службу, чтобы запускаться только с фиксированными данными. Возможно, некоторые части незафиксированных данных будут потеряны, но сервер базы данных будет работать нормально и может быть доступен приложениям.