pg_standby
pg_standby — поддерживает создание сервера тёплого резерва PostgreSQL
Синтаксис
pg_standby [параметр...] расположение_архива следующий_файл_wal каталог_wal [файл_перезапуска_wal]
Описание
Программа pg_standby поддерживает создание сервера в режиме «тёплого резерва». Она предназначена как для непосредственного применения в производственной среде, так и для использования в качестве настраиваемой заготовки, когда требуются специальные модификации.
pg_standby ожидает выполнения команды restore_command, которая, в свою очередь, нужна для перехода от стандартного восстановления архива к режиму тёплого резерва. Для этого также требуется другая настройка, которая описывается в основном руководстве сервера (см. Раздел 26.2).
Чтобы настроить резервный сервер на использование pg_standby, поместите эту строку в его файл конфигурации postgresql.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, любой или оба этих сервера могут обращаться к каталогу архива по сети.
Автор
Саймон Риггс <[email protected]>