Postgres HA (на основе WAL-доставки) терпит неудачу

Я надеюсь, что кто-нибудь может помочь мне решить проблему с WAL-доставкой и теплым резервом. Моя резервная система успешно работает несколько недель, а потом вдруг начинает искать несуществующие файлы .history. Затем он вылетает, и я не могу успешно перезапустить его без восстановления режима ожидания.

Обе системы работают под управлением CentOS 4.5 и postgres 8.4.1. Они используют NFS для хранения файлов WAL из рабочей среды в резервной.

Соответствующий фрагмент журнала с моими комментариями:

[** Recovery is running normally **]

Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 00000001000000830000005B
WAL file path           : /var/tafkan_backup_from_db1/00000001000000830000005B
Restoring to            : pg_xlog/RECOVERYXLOG
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG"
Keep archive history    : 00000001000000830000004D and later
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
running restore         : OK

Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 00000001000000830000005B
WAL file path           : /var/tafkan_backup_from_db1/00000001000000830000005B
Restoring to            : pg_xlog/RECOVERYXLOG
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/00000001000000830000005B" "pg_xlog/RECOVERYXLOG"
Keep archive history    : 000000000000000000000000 and later
running restore         : OK

[** All of a sudden it starts looks for .history files **]

Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 00000002.history
WAL file path           : /var/tafkan_backup_from_db1/00000002.history
Restoring to            : pg_xlog/RECOVERYHISTORY
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history    : 000000000000000000000000 and later
running restore         :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
not restored
history file not found
Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 00000001.history
WAL file path           : /var/tafkan_backup_from_db1/00000001.history
Restoring to            : pg_xlog/RECOVERYHISTORY
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/00000001.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history    : 000000000000000000000000 and later
running restore         :cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000001.history': No such file or directory
not restored
history file not found

[** I stopped Postgres, renamed recovery.done to recovery.conf, and restarted it. **]

Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 00000002.history
WAL file path           : /var/tafkan_backup_from_db1/00000002.history
Restoring to            : pg_xlog/RECOVERYHISTORY
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/00000002.history" "pg_xlog/RECOVERYHISTORY"
Keep archive history    : 000000000000000000000000 and later
running restore         :cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
cp: cannot stat `/var/tafkan_backup_from_db1/00000002.history': No such file or directory
not restored
history file not found
Trigger file            : /tmp/pgsql.trigger
Waiting for WAL file    : 0000000200000083000000A2
WAL file path           : /var/tafkan_backup_from_db1/0000000200000083000000A2
Restoring to            : pg_xlog/RECOVERYXLOG
Sleep interval          : 2 seconds
Max wait interval       : 0 forever
Command for restore     : cp "/var/tafkan_backup_from_db1/0000000200000083000000A2" "pg_xlog/RECOVERYXLOG"
Keep archive history    : 000000000000000000000000 and later
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...
WAL file not present yet. Checking for trigger file...

[** This file is not present. All WAL files start with 00000001. **]

Любые идеи? Я даже не знаю, что такое файлы .history, и (в основном отличная) документация не очень ясна по этому поводу.

PS. Хотел бы я запускать виртуальные машины, чтобы использовать текст ссылки, а не нужно беспокоиться о любой этой ерунде HA на уровне приложений :-)

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

2010-01-20 03:30:15 EST 4b3a5c63.401b LOG:  restored log file "00000001000000830000005A" from archive
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG:  restored log file "00000001000000830000005B" from archive
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG:  record with zero length at 83/5BFA2FF8
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG:  redo done at 83/5BFA2FAC
2010-01-20 03:30:23 EST 4b3a5c63.401b LOG:  last completed transaction was at log time 2010-01-20 03:28:04.594399-05
2010-01-20 03:30:25 EST 4b3a5c63.401b LOG:  restored log file "00000001000000830000005B" from archive
2010-01-20 03:30:37 EST 4b3a5c63.401b LOG:  selected new timeline ID: 2
2010-01-20 03:30:49 EST 4b3a5c63.401b LOG:  archive recovery complete
2010-01-20 03:30:59 EST 4b3a5c62.4019 LOG:  database system is ready to accept connections

postgresql high-availability log-shipping
person sbleon    schedule 20.01.2010    source источник
comment
привет sbleon, я просто хочу сделать резервную копию файлов WAL в другое место, мне не нужно горячее резервирование, вы можете помочь ??   -  person Anuj Patel    schedule 31.01.2012
comment
@indyaah, проверьте свою версию в отличной документации PostgreSQL.   -  person sbleon    schedule 02.03.2012
comment
спасибо за помощь дружище.!! :D   -  person Anuj Patel    schedule 03.03.2012

Ответы (4)


arrow_upward
1
arrow_downward

Совершенно другим подходом к HA может быть размещение базы данных PG на устройстве DRBD, совместно используемом двумя машинами.

person Bandi-T    schedule 20.01.2010
comment
Спасибо за предложение! Это, вероятно, то, что я сделаю, если не смогу заставить WAL-доставку работать надежно. - person sbleon; 20.01.2010

arrow_upward
1
arrow_downward

Вы использовали свой собственный сценарий/программу восстановления? Если да - пожалуйста, не делайте этого. Используйте pg_standby из вклада PostgreSQL.

В противном случае - просто игнорируйте файлы .history.

person Community    schedule 20.01.2010
comment
Я использую pg_standby. recovery.conf содержит: restore_command = 'pg_standby -l -d -s 2 -t /tmp/pgsql.trigger /var/tafkan_backup_from_db1 %f %p %r 2››standby.log». Я не могу игнорировать файлы .history, потому что, когда pg_standby начинает их искать, происходит сбой восстановления, recovery.conf перемещается в recovery.done, а файлы WAL начинают быстро накапливаться. - person sbleon; 20.01.2010

arrow_upward
1
arrow_downward

Ваша реплицированная копия в какой-то момент попала в сеть. «00000002.history» ищет файл истории для временной шкалы 00000002, тогда как остальные ваши журналы начинаются с 00000001, которая является исходной временной шкалой.

Я бы проверил ваши журналы PostgreSQL прямо перед тем, как он начал искать файл истории, чтобы увидеть, есть ли какие-либо признаки того, что БД подключилась к сети, даже на мгновение.

person Matthew Wood    schedule 21.01.2010
comment
Спасибо, Мэтью. Я добавил некоторые журналы к моему вопросу. Вы правы, что-то заставило его появиться в сети, но я не могу представить, что и почему. - person sbleon; 21.01.2010
comment
Что-то случилось на стороне источника? Запись записи с нулевой длиной 83/5BFA2FF8 выглядит так, как будто это только частичный журнал WAL, который он пытался восстановить. IIRC, когда он сталкивается с недопустимой записью в WAL, он откатывается к последней хорошей записи в этом WAL, а затем подключается к сети, независимо от существования файла триггера. Я бы посмотрел оба системных журнала около 20.01.2010 03:28:04.594399-05 и посмотрел, были ли какие-либо ошибки в Postgres, ОС или сети. - person Matthew Wood; 22.01.2010
comment
Такое поведение имеет смысл. Если Backup видит что-то похожее на сбой основного, он предполагает, что основной умер и что он должен восполнить пробел. Я подозреваю, что здесь может быть проблема с сетью. Я собираюсь посмотреть на этот угол. Спасибо! - person sbleon; 22.01.2010

arrow_upward
1
arrow_downward

Мне удалось решить эту проблему, обновив операционные системы CentOS на двух моих серверах PostgreSQL. Поэтому я думаю, что это был симптом какой-то базовой сетевой ошибки.

person sbleon    schedule 02.08.2011