26.3. Параметры резервного сервера

standby_mode (boolean)

Указывает, является ли сервер Postgres Pro резервным или нет. Если параметр установлен в on, то сервер не прекратит восстановление по окончании последнего архивного файла WAL, а продолжит попытки извлечения новых сегментов WAL посредством команды restore_command и/или через подключение к ведущему, как указано в параметре primary_conninfo.

primary_conninfo (string)

Указывает строку подключения ведомого сервера к ведущему. Строка описана в формате согласно Подраздел 33.1.1. Вместо опущенных параметров подключения используются соответствующие переменные окружения (см. Раздел 33.14). Если же какие-то переменные не установлены, то используются значения по умолчанию.

Строка может содержать имя (или адрес) основного сервера и порт подключения. Также можно указать необходимого пользователя на ведущем сервере с требуемыми привилегиями (см. Подраздел 25.2.5.1). Если настроена аутентификация по паролю, то его также необходимо указать. Пароль можно указать как в строке подключения primary_conninfo, так и в файле ~/.pgpass ведомого сервера (в качестве имени базы данных используйте replication). Не указывайте имя базы данных среди параметров подключения primary_conninfo.

Этот параметр не действует, если standby_mode имеет значение off.

primary_slot_name (string)

Дополнительно указывает заранее созданный слот при потоковой репликации для контроля очистки ресурсов подключённого узла (см. Подраздел 25.2.6). Этот параметр не действует, если не указана строка подключения primary_conninfo.

trigger_file (string)

Указывает триггерный файл, наличие которого завершает работу в режиме резервирования. Даже если это значение не установлено, существует возможность назначить резервный сервер основным с помощью команды pg_ctl promote. Этот параметр не действует, если параметр standby_mode имеет значение off.

recovery_min_apply_delay (integer)

По умолчанию ведомый сервер восстанавливает записи WAL ведущего настолько быстро, насколько это возможно. Иногда полезно иметь возможность задать задержку при копировании данных, например, для устранения ошибок, связанных с потерей данных. Параметр позволяет задать эту задержку, указав период времени в миллисекундах (по умолчанию) или иных единицах измерения. Например, если установить значение 5min, ведомый сервер будет воспроизводить фиксацию транзакции не раньше, чем через 5 минут (судя по его системным часам) после времени фиксации, сообщённого ведущим.

Возможна ситуация, когда задержка репликации между серверами превышает значение этого параметра. В этом случае дополнительная задержка не добавляется. Заметьте, что задержка вычисляется как разница между меткой времени, записанной в WAL на ведущем сервере, и текущим временем на резервном. Запаздывание передачи, связанное с задержками в сети или каскадной репликацией, может существенно сократить реальное время ожидания. Если время на главном и резервном сервере не синхронизировано, это может приводить к применению записей ранее ожидаемого, однако это не очень важно, потому что полезные значения этого параметра намного превышают типичное расхождение во времени между двумя серверами.

Задержка применяется лишь для записей WAL, представляющих фиксацию транзакций. Остальные записи проигрываются незамедлительно, так как их эффект не будет заметен до применения соответствующей записи о фиксации транзакции, благодаря правилам видимости MVCC.

Задержка добавляется, как только восстанавливаемая база данных достигает согласованного состояния, и исключается, когда резервный сервер переключается в режим основного. С момента переключения резервный сервер завершает восстановление незамедлительно.

Данный параметр предназначен для применения в конфигурациях с потоковой репликацией; однако, если он задан, он будет учитываться в любых случаях. Задержка, устанавливаемая этим параметром, распространяется и на сообщения hot_standby_feedback, что может привести к раздуванию базы на главном сервере; сочетание этих параметров требует осторожности.

Предупреждение

Этот параметр влияет на синхронную репликацию, когда synchronous_commit имеет значение remote_apply; каждый COMMIT будет ждать подтверждения применения.