pg_standby
Синтаксис
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 | Уровень выше | pg_test_fsync |