pg_standby

pg_standby — поддерживает создание сервера тёплого резерва PostgreSQL

Синтаксис

pg_standby [параметр...] расположение_архива следующий_файл_wal каталог_xlog [файл_перезапуска_wal]

Описание

Программа pg_standby поддерживает создание сервера в режиме «тёплого резерва». Она предназначена как для непосредственного применения в производственной среде, так и для использования в качестве настраиваемой заготовки, когда требуются специальные модификации.

pg_standby ожидает выполнения команды restore_command, которая, в свою очередь, нужна для перехода от стандартного восстановления архива к режиму тёплого резерва. Для этого также требуется другая настройка, которая описывается в основном руководстве сервера (см. Раздел 25.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 в архиве. Значение по умолчанию не обязательно наилучшее; за подробностями обратитесь к Разделу 25.2.

-t файл_триггер

Указывает файл-триггер, при появлении которого должна начаться отработка отказа. Имя этого файла рекомендуется выбирать по определённой схеме, позволяющей однозначно понять, для какого сервера вызывается отработка отказа, когда таких серверов в одной системе несколько; например, /tmp/pgsql.trigger.5432.

-V
--version

Вывести версию pg_standby и завершиться.

-w макс_время_ожидания

Задаёт максимальное время ожидания (в секундах) следующего файла WAL, по истечении которого будет произведено быстрое переключение. При нуле (значении по умолчанию) ожидание бесконечно. Значение по умолчанию не обязательно наилучшее; за подробностями обратитесь к Разделу 25.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, любой или оба этих сервера могут обращаться к каталогу архива по сети.

Автор

Саймон Риггс

См. также

pg_archivecleanup