26.3. Параметры резервного сервера
- standby_mode(- boolean)
- Указывает, является ли сервер PostgreSQL резервным или нет. Если параметр установлен в - on, то сервер не прекратит восстановление по окончании последнего архивного файла WAL, а продолжит попытки извлечения новых сегментов WAL посредством команды- restore_commandи/или через подключение к ведущему, как указано в параметре- primary_conninfo.
- primary_conninfo(- string)
- Указывает строку подключения ведомого сервера к ведущему. Строка описана в формате согласно Подраздел 31.1.1. Вместо опущенных параметров подключения используются соответствующие переменные окружения (см. Раздел 31.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, что может привести к раздуванию базы на главном сервере; сочетание этих параметров требует осторожности.