Я какое-то время работал над горячим резервным копированием для 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.
Любой совет будет принята с благодарностью.
источник
Интересно, что я решил это противоположным образом, как это сделал Пол.
Я добавил:
hot_standby = onили, скорее, изменилось
#hot_standby = offна выше. (Это было с использованием 9,5)источник
Я получил это в журналах:
Чтобы исправить бесконечный запуск сервера, сделайте следующее: остановите службу (если существует), уничтожьте процесс 'postgres' (обычно он существует). Запустите это в консоли:
Это связано с тем, что в каталоге xLog есть данные, которые не будут записаны до закрытия службы. А затем при запуске службы он пытается исправить эти данные. Иногда это останавливает запуск и никогда не заканчивается. Команда при чистке убирает эти незафиксированные данные, которые применяют службу, чтобы запускаться только с фиксированными данными. Возможно, некоторые части незафиксированных данных будут потеряны, но сервер базы данных будет работать нормально и может быть доступен приложениям.
источник