19.6. Репликация
Эти параметры управляют поведением встроенного механизма потоковой репликации (см. Подраздел 26.2.5). Когда он применяется, один сервер является ведущим, а другие — ведомыми. Ведущий сервер всегда передаёт, а ведомые всегда принимают данные репликации, но когда настроена каскадная репликация (см. Подраздел 26.2.7), ведомые серверы могут быть и передающими. Следующие параметры в основном относятся к передающим и ведомым серверам, хотя некоторые параметры имеют смысл только для ведущего. Все эти параметры могут быть разными в рамках одного кластера, если это требуется.
19.6.1. Передающие серверы
Эти параметры можно задать на любом сервере, который передаёт данные репликации одному или нескольким ведомым. Ведущий сервер всегда является передающим, так что на нём они должны задаваться всегда. Роль и значение этих параметров не меняются после того, как ведомый сервер становится ведущим.
max_wal_senders(integer)Задаёт максимально допустимое число одновременных подключений ведомых серверов или клиентов потокового копирования (т. е. максимальное количество одновременно работающих процессов передачи WAL). Значение по умолчанию —
10. При значении0репликация отключается. В случае неожиданного отключения клиента потоковой передачи слот подключения может оставаться занятым до достижения тайм-аута, так что этот параметр должен быть немного больше максимально допустимого числа клиентов, чтобы отключившиеся клиенты могли переподключиться немедленно. Задать этот параметр можно только при запуске сервера. Чтобы к данному серверу могли подключаться ведомые, уровеньwal_levelдолжен бытьreplicaили выше.Для ведомого сервера значение этого параметра должно быть больше или равно значению на ведущем. В противном случае на ведомом сервере не будут разрешены запросы.
max_replication_slots(integer)Задаёт максимальное число слотов репликации (см. Подраздел 26.2.6), которое сможет поддерживать сервер. Значение по умолчанию — 10. Этот параметр можно задать только при запуске сервера. Если заданное значение данного параметра будет меньше, чем число уже существующих слотов репликации, сервер не запустится. Чтобы слоты репликации можно было использовать, нужно также установить в
wal_levelуровеньreplicaили выше.На стороне подписчика указывает, сколько источников репликации (см. Главу 49) можно отслеживать одновременно, по сути ограничивая количество подписок на логическую репликацию, которые могут быть созданы на сервере. Если установленное значение будет меньше, чем текущее количество отслеживаемых источников репликации (показываемое в pg_replication_origin_status, а не в pg_replication_origin), сервер не запустится.
wal_keep_size(integer)Задаёт минимальный объём прошлых сегментов журнала, который будет сохраняться в каталоге
pg_wal, чтобы ведомый сервер мог выбрать их при потоковой репликации. Если ведомый сервер, подключённый к передающему, отстаёт больше чем наwal_keep_sizeмегабайт, передающий может удалить сегменты WAL, всё ещё необходимые ведомому, и в этом случае соединение репликации прервётся. В результате этого затем также будут прерваны зависимые соединения. (Однако ведомый сервер сможет восстановиться, выбрав этот сегмент из архива, если осуществляется архивация WAL.)Этот параметр задаёт только минимальный объём сегментов, который будет сохраняться в каталоге
pg_wal; для архивации WAL или для восстановления с момента контрольной точки может потребоваться сохранить больше сегментов. Еслиwal_keep_sizeравен нулю (это значение по умолчанию), система не сохраняет никакие дополнительные сегменты для ведомых серверов, поэтому число старых сегментов WAL, доступных для ведомых, зависит от положения предыдущей контрольной точки и состояния архивации WAL. Если это значение задаётся без единиц измерения, оно считается заданным в мегабайтах. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.max_slot_wal_keep_size(integer)Задаёт максимальный размер файлов WAL, который может оставаться в каталоге
pg_walдля слотов репликации после выполнения контрольной точки. Со значениемmax_slot_wal_keep_size, равным -1 (по умолчанию), для слотов репликации может сохраняться неограниченный объём файлов WAL. При неотрицательном значении, если позиция restart_lsn для слота репликации отстаёт от текущего LSN более чем на заданное количество мегабайт, использующий этот слот ведомый сервер может лишиться возможности продолжить репликацию вследствие удаления нужных ему файлов WAL. Доступность WAL для слотов репликации показывается в представлении pg_replication_slots. Если это значение указано без единиц измерения, оно считается заданным в мегабайтах. Данный параметр можно задать только в файлеpostgresql.confили в командной строке сервера.wal_sender_timeout(integer)Задаёт период времени, по истечении которого прерываются неактивные соединения репликации. Это помогает передающему серверу обнаружить сбой ведомого или разрывы сети. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию — 60 секунд. При значении, равном нулю, тайм-аут отключается.
Если узлы кластера распределены географически, его можно гибко настроить, используя разные значения в разных расположениях. Маленькие значения полезны для более быстрого обнаружения потери ведомого, подключённого по скоростному каналу, а большие — для более надёжного определения состояния ведомого, расположенного в удалённой сети, соединение с которой характеризуется большими задержками.
track_commit_timestamp(boolean)Определяет, будет ли сохраняться время фиксации транзакций. Этот параметр можно задать только при запуске сервера. По умолчанию он имеет значение
off.
19.6.2. Главный сервер
Эти параметры можно задать на главном/ведущем сервере, который должен передавать данные репликации одному или нескольким ведомым. Заметьте, что помимо этих параметров на ведущем сервере должен быть правильно установлен wal_level, а также может быть включена архивация WAL (см. Подраздел 19.5.3). Значения этих параметров на ведомых серверах не важны, хотя их можно подготовить заранее, на случай, если ведомый сервер придётся сделать ведущим.
synchronous_standby_names(string)Определяет список ведомых серверов, которые могут поддерживать синхронную репликацию, как описано в Подразделе 26.2.8. Активных синхронных ведомых серверов может быть один или несколько; транзакции, ожидающие фиксации, будут завершаться только после того, как эти ведомые подтвердят получение их данных. Синхронными ведомыми будут те, имена которых указаны в этом списке и которые подключены к ведущему и принимают поток данных в реальном времени (что показывает признак
streamingв представленииpg_stat_replication). Указание нескольких имён ведомых серверов позволяет обеспечить очень высокую степень доступности и защиту от потери данных.Именем ведомого сервера в этом контексте считается значение
application_nameведомого сервера, задаваемое в свойствах подключения. При организации физической репликации оно должно задаваться в строкеprimary_conninfo; по умолчанию это значение параметра cluster_name, если он задан, илиwalreceiverв противном случае. Для логической репликации его можно задать в строке подключения для подписки (по умолчанию это имя подписки). Как задать его для других потребителей потоков репликации, вы можете узнать в их документации.Этот параметр принимает список ведомых серверов в одной из следующих форм:
[FIRST]
число_синхронных(имя_ведомого[, ...] ) ANYчисло_синхронных(имя_ведомого[, ...] )имя_ведомого[, ...]здесь
число_синхронных— число синхронных ведомых серверов, от которых необходимо дожидаться ответов для завершения транзакций, аимя_ведомого— имя ведомого сервера. СловаFIRSTиANYзадают метод выбора синхронных ведомых из перечисленных серверов.Ключевое слово
FIRST, в сочетании счислом_синхронных, выбирает синхронную репликацию на основе приоритетов, когда транзакции фиксируются только после того, как их записи в WAL реплицируются начисло_синхронныхведомых серверов, выбираемых согласно приоритетам. Например, со значениемFIRST 3 (s1, s2, s3, s4)для фиксации транзакции необходимо дождаться ответа от трёх наиболее приоритетных из серверовs1,s2,s3иs4. Ведомые серверы, имена которых идут в этом списке первыми, будут иметь больший приоритет и будут считаться синхронными. Серверы, следующие в списке за ними, будут считаться потенциальными синхронными. Если один из текущих синхронных серверов по какой-то причине отключается, он немедленно будет заменён следующим сервером с наибольшим приоритетом. Ключевое словоFIRSTможет быть опущено.Ключевое слово
ANY, в сочетании счислом_синхронных, выбирает синхронную репликацию на основе кворума, когда транзакции фиксируются только после того, как их записи в WAL реплицируются на как минимумчисло_синхронныхперечисленных серверов. Например, со значениемANY 3 (s1, s2, s3, s4)для фиксации транзакции необходимо дождаться ответа от как минимум трёх из серверовs1,s2,s3иs4.Ключевые слова
FIRSTиANYвоспринимаются без учёта регистра. Если такое же имя оказывается у одного из ведомых серверов, егоимя_ведомогонужно заключить в двойные кавычки.Третья форма использовалась в PostgreSQL до версии 9.6 и по-прежнему поддерживается. По сути она равнозначна первой с
FIRSTичислом_синхронным, равным 1. Например,FIRST 1 (s1, s2)иs1, s2действуют одинаково: в качестве синхронного ведомого выбирается либоs1, либоs2.Специальному элементу
*соответствует имя любого ведомого.Уникальность имён ведомых серверов не контролируется. В случае дублирования имён более приоритетным будет один из серверов с подходящим именем, хотя какой именно, не определено.
Примечание
Каждое
имя_ведомогодолжно задаваться в виде допустимого идентификатора SQL, кроме*. При необходимости его можно заключать в кавычки. Но заметьте, что идентификаторыимя_ведомогосравниваются с именами приложений без учёта регистра, независимо от того, заключены ли они в кавычки или нет.Если имена синхронных ведомых серверов не определены, синхронная репликация не включается и фиксируемые транзакции не будут ждать репликации. Это поведение по умолчанию. Даже когда синхронная репликация включена, для отдельных транзакций можно отключить ожидание репликации, задав для параметра synchronous_commit значение
localилиoff.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.vacuum_defer_cleanup_age(integer)Задаёт число транзакций, на которое будет отложена очистка старых версий строк при
VACUUMи изменениях HOT. По умолчанию это число равно нулю, то есть старые версии строк могут удаляться сразу, как только перестанут быть видимыми в открытых транзакциях. Это значение можно сделать ненулевым на ведущем сервере, работающем с серверами горячего резерва, как описано в Разделе 26.5. В результате увеличится время, в течение которого будут успешно выполняться запросы на ведомом сервере без конфликтов из-за ранней очистки строк. Однако ввиду того, что эта отсрочка определяется числом записывающих транзакций, выполняющихся на ведущем сервере, сложно предсказать, каким будет дополнительное время отсрочки на ведомом сервере. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.В качестве альтернативы этому параметру можно также рассмотреть
hot_standby_feedbackна ведомом сервере.Этот параметр не предотвращает очистку старых строк, которые достигли возраста, заданного параметром
old_snapshot_threshold.
19.6.3. Ведомые серверы
Эти параметры управляют поведением ведомого сервера, который будет получать данные репликации. На ведущем сервере они не играют никакой роли.
primary_conninfo(string)Указывает строку подключения резервного сервера к передающему. Формат строки описан в Подразделе 33.1.1. Вместо опущенных параметров подключения используются соответствующие переменные окружения (см. Раздел 33.14). Если же и переменные не установлены, используются значения по умолчанию.
В строке подключения должно задаваться имя (или адрес) передающего сервера, а также номер порта, если он отличается от подразумеваемого по умолчанию ведущим. Также в ней указывается имя пользователя, соответствующее роли с необходимыми правами на передающем сервере (см. Подраздел 26.2.5.1). Если сервер осуществляет аутентификацию по паролю, дополнительно потребуется задать пароль. Его можно указать как в строке
primary_conninfo, так и отдельно, в файле~/.pgpassна резервном сервере (для базы данныхreplication). В строкеprimary_conninfoимя базы данных задавать не нужно.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера. Если значение данного параметра меняется во время работы процесса-приёмника WAL, этому процессу посылается сигнал для отключения, и ожидается, что он перезапустится с новым значением (если только определена непустая строкаprimary_conninfo). Этот параметр оказывает влияние только при работе сервера в режиме ведомого.primary_slot_name(string)Дополнительно задаёт заранее созданный слот, который будет использоваться при подключении к передающему серверу по протоколу потоковой репликации для управления освобождением ресурсов вышестоящего узла (см. Подраздел 26.2.6). Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера. Если значение данного параметра меняется во время работы процесса-приёмника WAL, этому процессу посылается сигнал для отключения, и ожидается, что он перезапустится с новым значением. Этот параметр не действует, если строкаprimary_conninfoне определена или сервер работает не в режиме ведомого.promote_trigger_file(string)Указывает триггерный файл, при появлении которого завершается работа в режиме ведомого. Даже если это значение не установлено, существует возможность назначить ведомый сервер ведущим с помощью команды
pg_ctl promoteили функцииpg_promote(). Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.hot_standby(boolean)Определяет, можно ли будет подключаться к серверу и выполнять запросы в процессе восстановления, как описано в Разделе 26.5. Значение по умолчанию —
on(подключения разрешаются). Задать этот параметр можно только при запуске сервера. Данный параметр играет роль только в режиме ведомого сервера или при восстановлении архива.max_standby_archive_delay(integer)В режиме горячего резерва этот параметр определяет, как долго должен ждать ведомый сервер, прежде чем отменять запросы, конфликтующие с очередными изменениями в WAL, как описано в Подразделе 26.5.2. Задержка
max_standby_archive_delayприменяется при обработке данных WAL, считываемых из архива (не текущих данных). Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию равно 30 секундам. При значении, равном -1, ведомый может ждать завершения конфликтующих запросов неограниченное время. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Заметьте, что параметр
max_standby_archive_delayопределяет не максимальное время, которое отводится для выполнения каждого запроса, а максимальное общее время, за которое должны быть применены изменения из одного сегмента WAL. Таким образом, если один запрос привёл к значительной задержке при обработке сегмента WAL, остальным конфликтующим запросам будет отведено гораздо меньше времени.max_standby_streaming_delay(integer)В режиме горячего резерва этот параметр определяет, как долго должен ждать ведомый сервер, прежде чем отменять запросы, конфликтующие с очередными изменениями в WAL, как описано в Подразделе 26.5.2. Задержка
max_standby_streaming_delayприменяется при обработке данных WAL, поступающих при потоковой репликации. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию равно 30 секундам. При значении, равном -1, ведомый может ждать завершения конфликтующих запросов неограниченное время. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Заметьте, что параметр
max_standby_streaming_delayопределяет не максимальное время, которое отводится для выполнения каждого запроса, а максимальное общее время, за которое должны быть применены изменения из WAL после получения от главного сервера. Таким образом, если один запрос привёл к значительной задержке, остальным конфликтующим запросам будет отводиться гораздо меньше времени, пока резервный сервер не догонит главный.wal_receiver_create_temp_slot(boolean)Определяет, должен ли процесс-приёмник WAL создавать временный слот репликации на удалённом сервере в случаях, когда постоянный слот репликации не настроен (не задан в primary_slot_name). По умолчанию этот параметр отключён. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера. Если значение данного параметра меняется во время работы процесса-приёмника WAL, этому процессу посылается сигнал для отключения, и ожидается, что он перезапустится с новым значением.wal_receiver_status_interval(integer)Определяет минимальную частоту, с которой процесс, принимающий WAL на ведомом сервере, будет сообщать о состоянии репликации ведущему или вышестоящему ведомому, где это состояние можно наблюдать в представлении
pg_stat_replication. В этом сообщении передаются следующие позиции в журнале предзаписи: позиция изменений записанных, изменений, сохранённых на диске, и изменений применённых. Значение параметра определяет максимальный интервал между сообщениями. Сообщения о состоянии передаются при каждом продвижении позиций записанных или сохранённых на диске изменений, но с промежутком не больше, чем заданный этим параметром. Таким образом, последняя переданная позиция применённых изменений может немного отставать от фактической в текущий момент. Если это значение задаётся без единиц измерения, оно считается заданным в секундах. Значение по умолчанию равно 10 секундам. При нулевом значении этого параметра передача состояния полностью отключается. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.hot_standby_feedback(boolean)Определяет, будет ли сервер горячего резерва сообщать ведущему или вышестоящему ведомому о запросах, которые он выполняет в данный момент. Это позволяет исключить необходимость отмены запросов, вызванную очисткой записей, но при некоторых типах нагрузки это может приводить к раздуванию базы данных на ведущем сервере. Эти сообщения о запросах будут отправляться не чаще, чем раз в интервал, задаваемый параметром
wal_receiver_status_interval. Значение данного параметра по умолчанию —off. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Если используется каскадная репликация, сообщения о запросах передаются выше, пока в итоге не достигнут ведущего сервера. На промежуточных серверах эта информация больше никак не задействуется.
Этот параметр не переопределяет поведение
old_snapshot_threshold, установленное на ведущем сервере; снимок на ведомом сервере, имеющий возраст больше заданного указанным параметром на ведущем, может стать недействительным, что приведёт к отмене транзакций на ведомом. Это объясняется тем, что предназначениеold_snapshot_thresholdзаключается в указании абсолютного ограничения времени, в течение которого могут накапливаться мёртвые строки, которое иначе могло бы нарушаться из-за конфигурации ведомого.wal_receiver_timeout(integer)Задаёт период времени, по истечении которого прерываются неактивные соединения репликации. Это помогает принимающему ведомому серверу обнаружить сбой ведущего или разрыв сети. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию — 60 секунд. При значении, равном нулю, тайм-аут отключается. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.wal_retrieve_retry_interval(integer)Определяет, сколько ведомый сервер должен ждать поступления данных WAL из любых источников (потоковая репликация, локальный
pg_walили архив WAL), прежде чем повторять попытку получения WAL. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию — 5 секунд. Задать этот параметр можно только вpostgresql.confили в командной строке сервера.Этот параметр полезен в конфигурациях, когда для узла в схеме восстановления нужно регулировать время ожидания новых данных WAL. Например, при восстановлении архива можно ускорить реакцию на появление нового файла WAL, уменьшив значение этого параметра. В системе с низкой активностью WAL увеличение этого параметра приведёт к сокращению числа запросов, необходимых для отслеживания архивов WAL, что может быть полезно в облачных окружениях, где учитывается число обращений к инфраструктуре.
recovery_min_apply_delay(integer)По умолчанию ведомый сервер восстанавливает записи WAL передающего настолько быстро, насколько это возможно. Иногда полезно иметь возможность задать задержку при копировании данных, например, для устранения ошибок, связанных с потерей данных. Этот параметр позволяет отложить восстановление на заданное время. Например, если установить значение
5min, ведомый сервер будет воспроизводить фиксацию транзакции не раньше, чем через 5 минут (судя по его системным часам) после времени фиксации, сообщённого ведущим. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию равно нулю, то есть задержка не добавляется.Возможна ситуация, когда задержка репликации между серверами превышает значение этого параметра. В этом случае дополнительная задержка не добавляется. Заметьте, что задержка вычисляется как разница между меткой времени, записанной в WAL на ведущем сервере, и текущим временем на ведомом. Запаздывание передачи, связанное с задержками в сети или каскадной репликацией, может существенно сократить реальное время ожидания. Если время на главном и ведомом сервере не синхронизировано, это может приводить к применению записей ранее ожидаемого, однако это не очень важно, потому что полезные значения этого параметра намного больше, чем обычно бывает разница во времени между двумя серверами.
Задержка применяется лишь для записей WAL, представляющих фиксацию транзакций. Остальные записи проигрываются незамедлительно, так как их эффект не будет заметен до применения соответствующей записи о фиксации транзакции, благодаря правилам видимости MVCC.
Задержка добавляется, как только восстанавливаемая база данных достигает согласованного состояния, и исключается, когда ведущий сервер переключается в режим основного. После переключения ведущий сервер завершает восстановление незамедлительно.
Данный параметр предназначен для применения в конфигурациях с потоковой репликацией; однако если он задан, он будет учитываться во всех случаях, кроме восстановления после сбоя. Задержка, устанавливаемая этим параметром, влияет и на работу механизма
hot_standby_feedback, что может привести к раздуванию базы на главном сервере; использовать данный параметр при включении этого механизма следует с осторожностью.Предупреждение
Этот параметр влияет на синхронную репликацию, когда
synchronous_commitимеет значениеremote_apply; каждыйCOMMITбудет ждать подтверждения применения.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.
19.6.4. Подписчики
Эти параметры управляют поведением подписчика логической репликации. На публикующем сервере они не играют роли.
Заметьте, что параметры конфигурации wal_receiver_timeout, wal_receiver_status_interval и wal_retrieve_retry_interval также воздействуют на рабочие процессы логической репликации.
max_logical_replication_workers(int)Задаёт максимально возможное число рабочих процессов логической репликации. В это число входят и рабочие процессы, применяющие изменения, и процессы, синхронизирующие таблицы.
Рабочие процессы логической репликации берутся из пула, контролируемого параметром
max_worker_processes.Значение по умолчанию — 4. Этот параметр можно задать только при запуске сервера.
max_sync_workers_per_subscription(integer)Максимальное число рабочих процессов, выполняющих синхронизацию, для одной подписки. Этот параметр управляет степенью распараллеливания копирования начальных данных в процессе инициализации подписки или при добавлении новых таблиц.
В настоящее время одну таблицу может обрабатывать только один рабочий процесс синхронизации.
Рабочие процессы синхронизации берутся из пула, контролируемого параметром
max_logical_replication_workers.Значение по умолчанию — 2. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.
19.6. Replication
These settings control the behavior of the built-in streaming replication feature (see Section 26.2.5). Servers will be either a master or a standby server. Masters can send data, while standbys are always receivers of replicated data. When cascading replication (see Section 26.2.7) is used, standby servers can also be senders, as well as receivers. Parameters are mainly for sending and standby servers, though some parameters have meaning only on the master server. Settings may vary across the cluster without problems if that is required.
19.6.1. Sending Servers
These parameters can be set on any server that is to send replication data to one or more standby servers. The master is always a sending server, so these parameters must always be set on the master. The role and meaning of these parameters does not change after a standby becomes the master.
max_wal_senders(integer)Specifies the maximum number of concurrent connections from standby servers or streaming base backup clients (i.e., the maximum number of simultaneously running WAL sender processes). The default is
10. The value0means replication is disabled. Abrupt disconnection of a streaming client might leave an orphaned connection slot behind until a timeout is reached, so this parameter should be set slightly higher than the maximum number of expected clients so disconnected clients can immediately reconnect. This parameter can only be set at server start. Also,wal_levelmust be set toreplicaor higher to allow connections from standby servers.When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server.
max_replication_slots(integer)Specifies the maximum number of replication slots (see Section 26.2.6) that the server can support. The default is 10. This parameter can only be set at server start. Setting it to a lower value than the number of currently existing replication slots will prevent the server from starting. Also,
wal_levelmust be set toreplicaor higher to allow replication slots to be used.On the subscriber side, specifies how many replication origins (see Chapter 49) can be tracked simultaneously, effectively limiting how many logical replication subscriptions can be created on the server. Setting it a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status, not pg_replication_origin) will prevent the server from starting.
wal_keep_size(integer)Specifies the minimum size of past log file segments kept in the
pg_waldirectory, in case a standby server needs to fetch them for streaming replication. If a standby server connected to the sending server falls behind by more thanwal_keep_sizemegabytes, the sending server might remove a WAL segment still needed by the standby, in which case the replication connection will be terminated. Downstream connections will also eventually fail as a result. (However, the standby server can recover by fetching the segment from archive, if WAL archiving is in use.)This sets only the minimum size of segments retained in
pg_wal; the system might need to retain more segments for WAL archival or to recover from a checkpoint. Ifwal_keep_sizeis zero (the default), the system doesn't keep any extra segments for standby purposes, so the number of old WAL segments available to standby servers is a function of the location of the previous checkpoint and status of WAL archiving. If this value is specified without units, it is taken as megabytes. This parameter can only be set in thepostgresql.conffile or on the server command line.max_slot_wal_keep_size(integer)Specify the maximum size of WAL files that replication slots are allowed to retain in the
pg_waldirectory at checkpoint time. Ifmax_slot_wal_keep_sizeis -1 (the default), replication slots may retain an unlimited amount of WAL files. Otherwise, if restart_lsn of a replication slot falls behind the current LSN by more than the given size, the standby using the slot may no longer be able to continue replication due to removal of required WAL files. You can see the WAL availability of replication slots in pg_replication_slots. If this value is specified without units, it is taken as megabytes. This parameter can only be set in thepostgresql.conffile or on the server command line.wal_sender_timeout(integer)Terminate replication connections that are inactive for longer than this amount of time. This is useful for the sending server to detect a standby crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism.
With a cluster distributed across multiple geographic locations, using different values per location brings more flexibility in the cluster management. A smaller value is useful for faster failure detection with a standby having a low-latency network connection, and a larger value helps in judging better the health of a standby if located on a remote location, with a high-latency network connection.
track_commit_timestamp(boolean)Record commit time of transactions. This parameter can only be set at server start. The default value is
off.
19.6.2. Master Server
These parameters can be set on the master/primary server that is to send replication data to one or more standby servers. Note that in addition to these parameters, wal_level must be set appropriately on the master server, and optionally WAL archiving can be enabled as well (see Section 19.5.3). The values of these parameters on standby servers are irrelevant, although you may wish to set them there in preparation for the possibility of a standby becoming the master.
synchronous_standby_names(string)Specifies a list of standby servers that can support synchronous replication, as described in Section 26.2.8. There will be one or more active synchronous standbys; transactions waiting for commit will be allowed to proceed after these standby servers confirm receipt of their data. The synchronous standbys will be those whose names appear in this list, and that are both currently connected and streaming data in real-time (as shown by a state of
streamingin thepg_stat_replicationview). Specifying more than one synchronous standby can allow for very high availability and protection against data loss.The name of a standby server for this purpose is the
application_namesetting of the standby, as set in the standby's connection information. In case of a physical replication standby, this should be set in theprimary_conninfosetting; the default is the setting of cluster_name if set, elsewalreceiver. For logical replication, this can be set in the connection information of the subscription, and it defaults to the subscription name. For other replication stream consumers, consult their documentation.This parameter specifies a list of standby servers using either of the following syntaxes:
[FIRST]
num_sync(standby_name[, ...] ) ANYnum_sync(standby_name[, ...] )standby_name[, ...]where
num_syncis the number of synchronous standbys that transactions need to wait for replies from, andstandby_nameis the name of a standby server.FIRSTandANYspecify the method to choose synchronous standbys from the listed servers.The keyword
FIRST, coupled withnum_sync, specifies a priority-based synchronous replication and makes transaction commits wait until their WAL records are replicated tonum_syncsynchronous standbys chosen based on their priorities. For example, a setting ofFIRST 3 (s1, s2, s3, s4)will cause each commit to wait for replies from three higher-priority standbys chosen from standby serverss1,s2,s3ands4. The standbys whose names appear earlier in the list are given higher priority and will be considered as synchronous. Other standby servers appearing later in this list represent potential synchronous standbys. If any of the current synchronous standbys disconnects for whatever reason, it will be replaced immediately with the next-highest-priority standby. The keywordFIRSTis optional.The keyword
ANY, coupled withnum_sync, specifies a quorum-based synchronous replication and makes transaction commits wait until their WAL records are replicated to at leastnum_synclisted standbys. For example, a setting ofANY 3 (s1, s2, s3, s4)will cause each commit to proceed as soon as at least any three standbys ofs1,s2,s3ands4reply.FIRSTandANYare case-insensitive. If these keywords are used as the name of a standby server, itsstandby_namemust be double-quoted.The third syntax was used before PostgreSQL version 9.6 and is still supported. It's the same as the first syntax with
FIRSTandnum_syncequal to 1. For example,FIRST 1 (s1, s2)ands1, s2have the same meaning: eithers1ors2is chosen as a synchronous standby.The special entry
*matches any standby name.There is no mechanism to enforce uniqueness of standby names. In case of duplicates one of the matching standbys will be considered as higher priority, though exactly which one is indeterminate.
Note
Each
standby_nameshould have the form of a valid SQL identifier, unless it is*. You can use double-quoting if necessary. But note thatstandby_names are compared to standby application names case-insensitively, whether double-quoted or not.If no synchronous standby names are specified here, then synchronous replication is not enabled and transaction commits will not wait for replication. This is the default configuration. Even when synchronous replication is enabled, individual transactions can be configured not to wait for replication by setting the synchronous_commit parameter to
localoroff.This parameter can only be set in the
postgresql.conffile or on the server command line.vacuum_defer_cleanup_age(integer)Specifies the number of transactions by which
VACUUMand HOT updates will defer cleanup of dead row versions. The default is zero transactions, meaning that dead row versions can be removed as soon as possible, that is, as soon as they are no longer visible to any open transaction. You may wish to set this to a non-zero value on a primary server that is supporting hot standby servers, as described in Section 26.5. This allows more time for queries on the standby to complete without incurring conflicts due to early cleanup of rows. However, since the value is measured in terms of number of write transactions occurring on the primary server, it is difficult to predict just how much additional grace time will be made available to standby queries. This parameter can only be set in thepostgresql.conffile or on the server command line.You should also consider setting
hot_standby_feedbackon standby server(s) as an alternative to using this parameter.This does not prevent cleanup of dead rows which have reached the age specified by
old_snapshot_threshold.
19.6.3. Standby Servers
These settings control the behavior of a standby server that is to receive replication data. Their values on the master server are irrelevant.
primary_conninfo(string)Specifies a connection string to be used for the standby server to connect with a sending server. This string is in the format described in Section 33.1.1. If any option is unspecified in this string, then the corresponding environment variable (see Section 33.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 sending 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 sending server (see Section 26.2.5.1). A password needs to be provided too, if the sender 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 parameter can only be set in the
postgresql.conffile or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting (except ifprimary_conninfois an empty string). This setting has no effect if the server is not in standby mode.primary_slot_name(string)Optionally specifies an existing replication slot to be used when connecting to the sending server via streaming replication to control resource removal on the upstream node (see Section 26.2.6). This parameter can only be set in the
postgresql.conffile or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting. This setting has no effect ifprimary_conninfois not set or the server is not in standby mode.promote_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 promoteor callingpg_promote(). This parameter can only be set in thepostgresql.conffile or on the server command line.hot_standby(boolean)Specifies whether or not you can connect and run queries during recovery, as described in Section 26.5. The default value is
on. This parameter can only be set at server start. It only has effect during archive recovery or in standby mode.max_standby_archive_delay(integer)When Hot Standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in Section 26.5.2.
max_standby_archive_delayapplies when WAL data is being read from WAL archive (and is therefore not current). If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in thepostgresql.conffile or on the server command line.Note that
max_standby_archive_delayis not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply any one WAL segment's data. Thus, if one query has resulted in significant delay earlier in the WAL segment, subsequent conflicting queries will have much less grace time.max_standby_streaming_delay(integer)When Hot Standby is active, this parameter determines how long the standby server should wait before canceling standby queries that conflict with about-to-be-applied WAL entries, as described in Section 26.5.2.
max_standby_streaming_delayapplies when WAL data is being received via streaming replication. If this value is specified without units, it is taken as milliseconds. The default is 30 seconds. A value of -1 allows the standby to wait forever for conflicting queries to complete. This parameter can only be set in thepostgresql.conffile or on the server command line.Note that
max_standby_streaming_delayis not the same as the maximum length of time a query can run before cancellation; rather it is the maximum total time allowed to apply WAL data once it has been received from the primary server. Thus, if one query has resulted in significant delay, subsequent conflicting queries will have much less grace time until the standby server has caught up again.wal_receiver_create_temp_slot(boolean)Specifies whether the WAL receiver process should create a temporary replication slot on the remote instance when no permanent replication slot to use has been configured (using primary_slot_name). The default is off. This parameter can only be set in the
postgresql.conffile or on the server command line. If this parameter is changed while the WAL receiver process is running, that process is signaled to shut down and expected to restart with the new setting.wal_receiver_status_interval(integer)Specifies the minimum frequency for the WAL receiver process on the standby to send information about replication progress to the primary or upstream standby, where it can be seen using the
pg_stat_replicationview. The standby will report the last write-ahead log location it has written, the last position it has flushed to disk, and the last position it has applied. This parameter's value is the maximum amount of time between reports. Updates are sent each time the write or flush positions change, or at least as often as specified by this parameter. Thus, the apply position may lag slightly behind the true position. If this value is specified without units, it is taken as seconds. The default value is 10 seconds. Setting this parameter to zero disables status updates completely. This parameter can only be set in thepostgresql.conffile or on the server command line.hot_standby_feedback(boolean)Specifies whether or not a hot standby will send feedback to the primary or upstream standby about queries currently executing on the standby. This parameter can be used to eliminate query cancels caused by cleanup records, but can cause database bloat on the primary for some workloads. Feedback messages will not be sent more frequently than once per
wal_receiver_status_interval. The default value isoff. This parameter can only be set in thepostgresql.conffile or on the server command line.If cascaded replication is in use the feedback is passed upstream until it eventually reaches the primary. Standbys make no other use of feedback they receive other than to pass upstream.
This setting does not override the behavior of
old_snapshot_thresholdon the primary; a snapshot on the standby which exceeds the primary's age threshold can become invalid, resulting in cancellation of transactions on the standby. This is becauseold_snapshot_thresholdis intended to provide an absolute limit on the time which dead rows can contribute to bloat, which would otherwise be violated because of the configuration of a standby.wal_receiver_timeout(integer)Terminate replication connections that are inactive for longer than this amount of time. This is useful for the receiving standby server to detect a primary node crash or network outage. If this value is specified without units, it is taken as milliseconds. The default value is 60 seconds. A value of zero disables the timeout mechanism. This parameter can only be set in the
postgresql.conffile or on the server command line.wal_retrieve_retry_interval(integer)Specifies how long the standby server should wait when WAL data is not available from any sources (streaming replication, local
pg_walor WAL archive) before trying again to retrieve WAL data. If this value is specified without units, it is taken as milliseconds. The default value is 5 seconds. This parameter can only be set in thepostgresql.conffile or on the server command line.This parameter is useful in configurations where a node in recovery needs to control the amount of time to wait for new WAL data to be available. For example, in archive recovery, it is possible to make the recovery more responsive in the detection of a new WAL log file by reducing the value of this parameter. On a system with low WAL activity, increasing it reduces the amount of requests necessary to access WAL archives, something useful for example in cloud environments where the amount of times an infrastructure is accessed is taken into account.
recovery_min_apply_delay(integer)By default, a standby server restores WAL records from the sending server 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 specified amount of time. 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. If this value is specified without units, it is taken as milliseconds. The default is zero, adding no delay.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 except crash recovery.
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.This parameter can only be set in the
postgresql.conffile or on the server command line.
19.6.4. Subscribers
These settings control the behavior of a logical replication subscriber. Their values on the publisher are irrelevant.
Note that wal_receiver_timeout, wal_receiver_status_interval and wal_retrieve_retry_interval configuration parameters affect the logical replication workers as well.
max_logical_replication_workers(int)Specifies maximum number of logical replication workers. This includes both apply workers and table synchronization workers.
Logical replication workers are taken from the pool defined by
max_worker_processes.The default value is 4. This parameter can only be set at server start.
max_sync_workers_per_subscription(integer)Maximum number of synchronization workers per subscription. This parameter controls the amount of parallelism of the initial data copy during the subscription initialization or when new tables are added.
Currently, there can be only one synchronization worker per table.
The synchronization workers are taken from the pool defined by
max_logical_replication_workers.The default value is 2. This parameter can only be set in the
postgresql.conffile or on the server command line.