pg_standby
pg_standby — поддерживает создание сервера тёплого резерва PostgreSQL
Синтаксис
pg_standby
[параметр
...] расположение_архива
следующий_файл_wal
каталог_xlog
[файл_перезапуска_wal
]
Описание
Программа pg_standby поддерживает создание сервера в режиме «тёплого резерва». Она предназначена как для непосредственного применения в производственной среде, так и для использования в качестве настраиваемой заготовки, когда требуются специальные модификации.
pg_standby ожидает выполнения команды restore_command
, которая, в свою очередь, нужна для перехода от стандартного восстановления архива к режиму тёплого резерва. Для этого также требуется другая настройка, которая описывается в основном руководстве сервера (см. Раздел 26.2).
Чтобы настроить резервный сервер на использование pg_standby, поместите эту строку в файл конфигурации recovery.conf
:
restore_command = 'pg_standby каталог_архива
%f %p %r'
Здесь каталог_архива
— каталог, из которого должны восстанавливаться сегменты WAL.
Если указывается файл_перезапуска_wal
, обычно с помощью макроса %r
, тогда все файлы WAL, предшествующие указанному, будут удалены из каталога расположение_архива
. Это позволяет сократить число сохраняемых файлов без потери возможности восстановления при перезапуске. Такой вариант использования уместен, когда расположение_архива
указывает на область рабочих файлов конкретного резервного сервера, но не когда расположение_архива
— каталог с архивом WAL для долговременного хранения.
pg_standby рассчитывает на то, что расположение_архива
доступно для чтения пользователю, владеющему серверным процессом. Если указывается файл_перезапуска_wal
(или -k
), каталог расположение_архива
должен быть также доступен для записи.
При отказе ведущего сервера переключение на сервер «тёплого резерва» возможно двумя способами:
- Умное переключение
При умном переключении сервер включается в работу, применив изменения из всех файлов WAL, имеющихся в архиве. В результате никакие данные не теряются, даже если данный резервный сервер отстал, но если применить нужно большое количество изменений WAL, подготовка к работе может быть длительной. Чтобы вызвать умное переключение, создайте файл-триггер, содержащий слово
smart
, либо просто пустой файл.- Быстрое переключение
При быстром переключении сервер включается в работу немедленно. Все ещё не применённые файлы WAL в архиве будут игнорироваться, и все транзакции в этих файлах будут потеряны. Чтобы вызвать быстрое переключение, создайте файл-триггер и запишите в него слово
fast
. Программу pg_standby можно также настроить так, чтобы быстрое переключение происходило автоматически, если за определённое время не появляется новый файл WAL.
Параметры
pg_standby принимает следующие аргументы командной строки:
-c
Применять для восстановления файлов WAL из архива команду
cp
илиcopy
. На данный момент поддерживается только это поведение, так что этот параметр бесполезен.-d
Выводить подробные отладочные сообщения в
stderr
.-k
Удалить файлы из каталога
расположение_архива
, чтобы в нём осталось не больше заданного числа файлов WAL, предшествующих текущему. Ноль (по умолчанию) означает, что не нужно удалять никакие файлы из каталогарасположение_архива
. Этот параметр будет просто игнорироваться, если указанфайл_перезапуска_wal
, так как этот метод более точно определяет правильную точку отсечения архива. Этот параметр считается устаревшим с PostgreSQL 8.3; надёжнее и эффективнее использовать параметрфайл_перезапуска_wal
. При слишком маленьком значении данного параметра могут быть удалены файлы, требующиеся для перезапуска резервного сервера, тогда как при слишком большом будет неэффективно расходоваться место в архиве.-r
макс_повторов
Устанавливает, сколько раз максимум нужно повторять команду copy в случае ошибки (по умолчанию 3). После каждой ошибки программа приостанавливается на
время_задержки
*число_повторов
, так что время ожидания постепенно увеличивается. По умолчанию она ждёт 5, 10, затем 15 секунд, и только потом сообщает резервному серверу об ошибке. Это событие будет воспринято как завершение восстановления, и в результате резервный сервер полностью включится в работу.-s
время_задержки
Задаёт количество секунд (до 60, по умолчанию 5) для паузы между проверками наличия файла WAL в архиве. Значение по умолчанию не обязательно наилучшее; за подробностями обратитесь к Разделу 26.2.
-t
файл_триггер
Указывает файл-триггер, при появлении которого должна начаться отработка отказа. Имя этого файла рекомендуется выбирать по определённой схеме, позволяющей однозначно понять, для какого сервера вызывается отработка отказа, когда таких серверов в одной системе несколько; например,
/tmp/pgsql.trigger.5432
.-V
--version
Вывести версию pg_standby и завершиться.
-w
макс_время_ожидания
Задаёт максимальное время ожидания (в секундах) следующего файла WAL, по истечении которого будет произведено быстрое переключение. При нуле (значении по умолчанию) ожидание бесконечно. Значение по умолчанию не обязательно наилучшее; за подробностями обратитесь к Разделу 26.2.
-?
--help
Вывести справку об аргументах командной строки pg_standby и завершиться.
Замечания
Программа pg_standby предназначена для работы с PostgreSQL 8.2 и новее.
С PostgreSQL, начиная с 8.3, можно использовать макрос %r
, который позволяет pg_standby узнать, какой последний файл нужно сохранять. Для PostgreSQL 8.2, если требуется очищать архив, нужно применять параметр -k
. Этот параметр сохранился и после 8.3, но теперь он считается устаревшим.
PostgreSQL, начиная с 8.4, поддерживает параметр recovery_end_command
. В нём можно задать команду, удаляющую файл-триггер во избежание ошибок.
Программа pg_standby написана на C; её исходный код легко поддаётся модификации (он содержит секции, предназначенные для изменения при надобности)
Примеры
В системах Linux или Unix можно использовать команды:
archive_command = 'cp %p .../archive/%f' restore_command = 'pg_standby -d -s 2 -t /tmp/pgsql.trigger.5442 .../archive %f %p %r 2>>standby.log' recovery_end_command = 'rm -f /tmp/pgsql.trigger.5442'
Предполагается, что каталог архива физически располагается на резервном сервере, так что команда archive_command
обращается к нему по NFS, но для резервного сервера эти файлы локальные (для этого применяется ln
). Эти команды будут:
выводить отладочную информацию в
standby.log
ждать 2 секунды между проверками появления следующего файла WAL
прекращать ожидание, только когда появляется файл-триггер с именем
/tmp/pgsql.trigger.5442
, и выполнить переключение согласно его содержимомуудалять файл-триггер по завершении восстановления
удалять ставшие ненужными файлы из каталога архива
В Windows можно использовать такие команды:
archive_command = 'copy %p ...\\archive\\%f' restore_command = 'pg_standby -d -s 5 -t C:\pgsql.trigger.5442 ...\archive %f %p %r 2>>standby.log' recovery_end_command = 'del C:\pgsql.trigger.5442'
Заметьте, что обратную косую черту нужно дублировать в archive_command
, но не в restore_command
или recovery_end_command
. Эти команды будут:
применять команду
copy
для восстановления файлов WAL из архивавыводить отладочную информацию в
standby.log
ждать 5 секунд между проверками появления следующего файла WAL
прекращать ожидание, только когда появляется файл-триггер с именем
C:\pgsql.trigger.5442
, и выполнить переключение согласно его содержимомуудалять файл-триггер по завершении восстановления
удалять ставшие ненужными файлы из каталога архива
Команда copy
в Windows устанавливает окончательный размер файла до того, как файл будет окончательно скопирован, что обычно сбивает с толку pg_standby. Поэтому pg_standby ждёт время_задержки
после того, как увидит подходящий размер файла. Команда cp
из GNUWin32 устанавливает размер файла, только когда завершает копирование.
Так как в примере для Windows с обеих сторон применяется copy
, любой или оба этих сервера могут обращаться к каталогу архива по сети.
Автор
Саймон Риггс <simon@2ndquadrant.com>