Помилка гарячого резервного копіювання PostgreSQL 9.1: система баз даних запускається


16

Я працюю над гарячою резервною копією для 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

postgresql.conf:

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

Конфігурації підлеглого сервера:

postgresql.conf:

hot_standby = увімкнено

recovery.conf:

standby_mode = увімкнено
primar_conninfo = хост = IPAddressOfMasterServer
порт = 5432
user = postgres
Resto_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "% p"'

Після налаштування обох серверів

Я переходжу на користувача postgres на головному сервері і запускаю команди:

psql -c "Виберіть pg_start_backup ('label", правда); ";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data slave: /var/lib/pgsql/9.1/data \
        --виключити postmaster.pid
pgsql -c "вибрати 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" з архіву
Журнал: несподіваний pageaddr 0/85000000 у файлі журналу 0, сегмент 192, зміщення 0
Журнал: несподіваний pageaddr 0/85000000 у файлі журналу 0, сегмент 192, зміщення 0
Журнал: поточна реплікація успішно підключена до основного

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

Будь-яка порада буде дуже вдячна.

Відповіді:


11

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

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

Після rsync ви справді запускали те, що показуєте ?:

pgsql -c "вибрати pg_stop_backup ();"

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

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

і:

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

Ви намагалися в цей момент підключитися до раба? Що трапилось?

Повідомлення "Успіх. Тепер ви можете почати ..." генерується повідомленням initdb, яке не слід запускати як частину налаштування раба; тому я думаю, що вас там може щось збентежити. Мене також турбують такі, очевидно, суперечливі твердження:

Єдиний спосіб перезапустити Postgres - це через перезапуск служби postgresql-9.1 або /etc/init.d/ команд перезапуску /etc/init.d/postgresql-9.1. Після отримання цієї помилки я вбиваю всі процеси і знову намагаюся перезапустити базу даних ...

Ви намагалися зупинити послугу через сервісний скрипт? Що трапилось? Це може допомогти зрозуміти журнали, якщо ви встановите рядки з додатковою інформацією. Ми використовуємо:

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

recovery.confСценарій виглядає дивно. Ви копіюєте з головного каталогу pg_xlog, активного каталогу pg_xlog ведучого або з каталогу архівів?


8

У мене були і деякі проблеми з цим, за винятком того, що я був на 9.3, а не на 9.1. У всякому разі, виправлення виявилося досить тривіальним:

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

Я відредагував postgresql.confфайл раба і:

  • прокоментував archive_mode=on
  • прокоментував archiveкоманду; і
  • прокоментував hot_standby=on

Це зробило це: я зміг змусити базу даних бути сервером лише для читання, готовим приймати запити лише для читання.

Існує скрипт, який називається, pg_basebackupщо створить каталог завантаження для підлеглого. Це каталог даних із базою даних у ньому. Вам потрібно змінити postgresql.confфайл, перш ніж його можна використовувати як ведений, як описано, щось досить просте для публікації pg_basebackupсценарію.


1
Коли ви пишете "commented out hot_standby = on" Я припускаю, що ви маєте на увазі "видалили позначку # -comment раніше, щоб фактично включити hot_standby" :) Якщо не в hot_standby, db завжди буде "запускатися" по дизайну (це тепло в режимі очікування, готовий до відмови, але не запитуючи). Зауважте, що якщо ви створили дамп базового резервного копіювання, не маючи wal_level = hot_standby на ведучому, а потім увімкнувши hot_stanby на підлеглому, вам доведеться повторно демпінгувати і повторно запускати slave db для hot_standby, щоб встати і працювати. В іншому випадку ви отримаєте деякі фатальні помилки.
Фредерік Струк-Шьонинг

hot_standby = увімкнено, він повинен бути там
Абхілаш Мішра

7

Цікаво, що я вирішив це навпаки так, як це робив Павло.

Я додав:

hot_standby = on

або, скоріше, змінили #hot_standby = offвище. (Для цього було використано 9,5)


1

Я отримав це в журналах:

MSK FATAL:  the database system is starting up

Щоб виправити нескінченний запуск сервера, зробіть це: Зупиніть службу (якщо вона існує), введіть процес "postgres" (зазвичай він існує). Запустіть це в консолі:

pg_resetxlog.exe -D ../Data -f

Ця команда з'являється через те, що в каталозі xLog є дані, які не повинні бути записані перед тим, як послуга була закрита. А потім при запуску служби він намагається виправити ці дані. Іноді воно замикає запуск і ніколи не закінчується. Команда вгорі очистити ці нефіксовані дані, які застосовують послугу для запуску лише з фіксованих даних. Можливо, деякі частини нефіксованих даних будуть втрачені, але сервер баз даних буде працювати нормально і доступ до них можна отримати за допомогою додатків.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.