27.3. Параметры резервного сервера
standby_mode(boolean)Указывает, является ли сервер Postgres Pro резервным или нет. Если параметр установлен в
on, то сервер не прекратит восстановление по окончании последнего архивного файла WAL, а продолжит попытки извлечения новых сегментов WAL посредством командыrestore_commandи/или через подключение к ведущему, как указано в параметреprimary_conninfo.primary_conninfo(string)Указывает строку подключения ведомого сервера к ведущему. Строка описана в формате согласно Подраздел 32.1.1. Вместо опущенных параметров подключения используются соответствующие переменные окружения (см. Раздел 32.14). Если же какие-то переменные не установлены, то используются значения по умолчанию.
Строка может содержать имя (или адрес) основного сервера и порт подключения. Также можно указать необходимого пользователя на ведущем сервере с требуемыми привилегиями (см. Подраздел 26.2.5.1). Если настроена аутентификация по паролю, то его также необходимо указать. Пароль можно указать как в строке подключения
primary_conninfo, так и в файле~/.pgpassведомого сервера (в качестве имени базы данных используйтеreplication). Не указывайте имя базы данных среди параметров подключенияprimary_conninfo.Этот параметр не действует, если
standby_modeимеет значениеoff.primary_slot_name(string)Дополнительно задаёт заранее созданный слот, который будет использоваться при подключении к ведущему по протоколу потоковой репликации для управления освобождением ресурсов вышестоящего узла (см. Подраздел 26.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будет ждать подтверждения применения.
27.3. Standby Server Settings
standby_mode(boolean)Specifies whether to start the Postgres Pro server as a standby. If this parameter is
on, the server will not stop recovery when the end of archived WAL is reached, but will keep trying to continue recovery by fetching new WAL segments usingrestore_commandand/or by connecting to the primary server as specified by theprimary_conninfosetting.primary_conninfo(string)Specifies a connection string to be used for the standby server to connect with the primary. This string is in the format described in Section 32.1.1. If any option is unspecified in this string, then the corresponding environment variable (see Section 32.14) is checked. If the environment variable is not set either, then defaults are used.
The connection string should specify the host name (or address) of the primary server, as well as the port number if it is not the same as the standby server's default. Also specify a user name corresponding to a suitably-privileged role on the primary (see Section 26.2.5.1). A password needs to be provided too, if the primary demands password authentication. It can be provided in the
primary_conninfostring, or in a separate~/.pgpassfile on the standby server (usereplicationas the database name). Do not specify a database name in theprimary_conninfostring.This setting has no effect if
standby_modeisoff.primary_slot_name(string)Optionally specifies an existing replication slot to be used when connecting to the primary via streaming replication to control resource removal on the upstream node (see Section 26.2.6). This setting has no effect if
primary_conninfois not set.trigger_file(string)Specifies a trigger file whose presence ends recovery in the standby. Even if this value is not set, you can still promote the standby using
pg_ctl promote. This setting has no effect ifstandby_modeisoff.recovery_min_apply_delay(integer)By default, a standby server restores WAL records from the primary as soon as possible. It may be useful to have a time-delayed copy of the data, offering opportunities to correct data loss errors. This parameter allows you to delay recovery by a fixed period of time, measured in milliseconds if no unit is specified. For example, if you set this parameter to
5min, the standby will replay each transaction commit only when the system time on the standby is at least five minutes past the commit time reported by the master.It is possible that the replication delay between servers exceeds the value of this parameter, in which case no delay is added. Note that the delay is calculated between the WAL time stamp as written on master and the current time on the standby. Delays in transfer because of network lag or cascading replication configurations may reduce the actual wait time significantly. If the system clocks on master and standby are not synchronized, this may lead to recovery applying records earlier than expected; but that is not a major issue because useful settings of this parameter are much larger than typical time deviations between servers.
The delay occurs only on WAL records for transaction commits. Other records are replayed as quickly as possible, which is not a problem because MVCC visibility rules ensure their effects are not visible until the corresponding commit record is applied.
The delay occurs once the database in recovery has reached a consistent state, until the standby is promoted or triggered. After that the standby will end recovery without further waiting.
This parameter is intended for use with streaming replication deployments; however, if the parameter is specified it will be honored in all cases.
hot_standby_feedbackwill be delayed by use of this feature which could lead to bloat on the master; use both together with care.Warning
Synchronous replication is affected by this setting when
synchronous_commitis set toremote_apply; everyCOMMITwill need to wait to be applied.
