18.6. Репликация #
Эти параметры управляют поведением встроенных механизмов потоковой репликации (см. Подраздел 25.2.5) и логической репликации (см. Главу 29).
В потоковой репликации один сервер является ведущим, а другие — ведомыми. Ведущий сервер всегда передаёт, а ведомые всегда принимают данные репликации, но когда настроена каскадная репликация (см. Подраздел 25.2.7), ведомые серверы могут быть и передающими. Следующие параметры в основном относятся к передающим и ведомым серверам, хотя некоторые параметры имеют смысл только для ведущего. Все эти параметры могут быть разными в рамках одного кластера, если это требуется.
Для логической репликации публикующие серверы (серверы, выполняющие CREATE PUBLICATION) передают данные репликации подписчикам (серверам, выполняющим CREATE SUBSCRIPTION). Серверы также могут быть публикующими и подписчиками одновременно. Обратите внимание, что в следующих разделах публикующие серверы называются «передающими серверами» или «передатчиками». За дополнительной информацией о параметрах конфигурации логической репликации обратитесь к Разделу 29.11.
18.6.1. Передающие серверы #
Эти параметры можно задать на любом сервере, который передаёт данные репликации одному или нескольким ведомым. Ведущий сервер всегда является передающим, так что на нём они должны задаваться всегда. Роль и значение этих параметров не меняются после того, как ведомый сервер становится ведущим.
max_wal_senders(integer) #Задаёт максимально допустимое число одновременных подключений ведомых серверов или клиентов потокового копирования (т. е. максимальное количество одновременно работающих процессов передачи WAL). Значение по умолчанию —
10. При значении0репликация отключается. В случае неожиданного отключения клиента потоковой передачи слот подключения может оставаться занятым до достижения тайм-аута, так что этот параметр должен быть немного больше максимально допустимого числа клиентов, чтобы отключившиеся клиенты могли переподключиться немедленно. Задать этот параметр можно только при запуске сервера. Чтобы к данному серверу могли подключаться ведомые, уровеньwal_levelдолжен бытьreplicaили выше.Для ведомого сервера значение этого параметра должно быть больше или равно значению на ведущем. В противном случае на ведомом сервере не будут разрешены запросы.
Примечание
При настройке BiHA-кластера этот параметр автоматически изменяется утилитой bihactl. Не рекомендуется изменять этот параметр вручную, так как это может повлиять на нормальную работу кластера. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.
max_replication_slots(integer) #Задаёт максимальное число слотов репликации (см. Подраздел 25.2.6), которое сможет поддерживать сервер. Значение по умолчанию — 10. Этот параметр можно задать только при запуске сервера. Если заданное значение данного параметра будет меньше, чем число уже существующих слотов репликации, сервер не запустится. Чтобы слоты репликации можно было использовать, нужно также установить в
wal_levelуровеньreplicaили выше.Обратите внимание, что этот параметр также применяется на стороне подписчика, но с другим значением.
Примечание
При настройке BiHA-кластера этот параметр автоматически задаётся утилитой bihactl. Не рекомендуется изменять этот параметр вручную, так как это может повлиять на нормальную работу кластера. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.
output_plugin_libraries(string) #Выводит список библиотек из каталога, указанного в параметре dynamic_library_path, которые также являются доверенными для использования в качестве модулей вывода логического декодирования клиентами репликации. Любые запросы на логическое декодирование или репликацию для других библиотек будут отклонены. Ограничение действует для всех пользователей. Значение по умолчанию —
'pgoutput, test_decoding, dbcopies_decoding'.Формат — разделённый запятыми список имён библиотек, и каждое имя в нём должно восприниматься командой
LOAD(но клиенты логического декодирования должны указывать имя плагина, который точно совпадает записи в списке, без изменений регистра или структуры пути). Пробельные символы между именами игнорируются; если в имя нужно включить пробелы или запятые, заключите его в двойные кавычки.Администратор сервера должен удостовериться, что библиотеки, добавленные в этот список, не выдают дополнительных прав не-суперпользователям при загрузке на сервер.
Примечание
При обновлении сервера с версии, в которой отсутствует параметр
output_plugin_libraries, следующий запрос может помочь сформировать список плагинов, необходимых для постоянных слотов логической репликации:SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;
В целях безопасности необходимо тщательно проверить список перед настройкой
output_plugin_libraries.Вышеупомянутый запрос отображает только плагины, которые были успешно добавлены в слоты репликации в какой-то момент в прошлом. Новые отклонённые запросы будут отображаться в журнале с подобным сообщением
ERROR: library "..." may not be used as an output plugin DETAIL: The configuration parameter "output_plugin_libraries" (currently 'pgoutput, test_decoding') does not name this library as a trusted output plugin. HINT: If it is safe for all REPLICATION users to use this library as an output plugin, add it to "output_plugin_libraries" and reload the server configuration.
wal_keep_size(integer) #Задаёт минимальный объём прошлых файлов WAL, который будет сохраняться в каталоге
pg_wal, чтобы ведомый сервер мог выбрать их при потоковой репликации. Если ведомый сервер, подключённый к передающему, отстаёт больше чем наwal_keep_sizeмегабайт, передающий может удалить сегменты WAL, всё ещё необходимые ведомому, и в этом случае соединение репликации прервётся. В результате этого затем также будут прерваны зависимые соединения. (Однако ведомый сервер сможет восстановиться, выбрав этот сегмент из архива, если осуществляется архивация WAL.)Этот параметр задаёт только минимальный объём сегментов, который будет сохраняться в каталоге
pg_wal; для архивации WAL или для восстановления с момента контрольной точки может потребоваться сохранить больше сегментов. Еслиwal_keep_sizeравен нулю (это значение по умолчанию), система не сохраняет никакие дополнительные сегменты для ведомых серверов, поэтому число старых сегментов WAL, доступных для ведомых, зависит от положения предыдущей контрольной точки и состояния архивации WAL. Если это значение задаётся без единиц измерения, оно считается заданным в мегабайтах. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Примечание
При настройке BiHA-кластера этот параметр автоматически изменяется утилитой bihactl. Если значение уже было задано, BiHA использует существующие значение. При необходимости значение можно изменить. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.
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или в командной строке сервера.Примечание
При настройке BiHA-кластера этот параметр автоматически задаётся утилитой bihactl. Если значение уже было задано, BiHA использует существующие значение. При необходимости значение можно изменить. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.
wal_sender_timeout(integer) #Задаёт период времени, по истечении которого прерываются неактивные соединения репликации. Это помогает передающему серверу обнаружить сбой ведомого или разрывы сети. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию — 60 секунд. При значении, равном нулю, тайм-аут отключается.
Если узлы кластера распределены географически, его можно гибко настроить, используя разные значения в разных расположениях. Маленькие значения полезны для более быстрого обнаружения потери ведомого, подключённого по скоростному каналу, а большие — для более надёжного определения состояния ведомого, расположенного в удалённой сети, соединение с которой характеризуется большими задержками.
wal_sender_shutdown_timeout(integer) #Указывает максимальное время, в течение которого сервер при завершении работы ожидает репликации всех данных WAL на принимающую сторону. Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. При значении
-1(по умолчанию), этот контроль длительности отключается.Когда используется репликация, передающий сервер при завершении работы обычно ожидает, пока все данные WAL будут переданы на принимающую сторону. Это помогает поддерживать синхронизацию между передающей и принимающей стороной после завершения работы сервера, что особенно важно при переключении ролей в физической репликации, однако может задержать завершение работы сервера.
Если этот параметр задан, сервер прекращает ожидание и завершает работу по истечении тайм-аута. Это может сократить время остановки, например, когда репликация идёт медленно в сетях с высокой задержкой или когда рабочий процесс применения логической репликации ожидает блокировок. Однако в этом случае после завершения работы передающий и принимающий серверы могут быть рассинхронизированы.
Этот параметр можно задать в строке
primary_conninfoи в предложенииCONNECTIONкомандыCREATE SUBSCRIPTION(например, добавивoptions=-cwal_sender_shutdown_timeout=10sв строку подключения), что позволяет настраивать различные тайм-ауты для каждого соединения репликации. Например, когда одновременно используется физическая и логическая репликация, этот параметр можно отключить для физической репликации (например, для переключения ролей) и включить для логической, чтобы ограничить время завершения работы.walsender_plugin_libraries(string) #Указывает одну или несколько библиотек с пользовательскими командами репликации. Значение должно содержать список имён библиотек, разделённых запятыми.
Когда на сервер Postgres Pro отправляется специальная команда репликации, которая начинается с литерала
'PGPRO_CALL_PLUGIN'и содержит имя пользовательской библиотеки, сервер ищет указанную библиотеку в спискеwalsender_plugin_libraries. Если библиотека присутствует в каталогах библиотек Postgres Pro, сервер ищет указанную команду в этой библиотеке и, если находит, выполняет её. Если библиотека не найдена или указанная команда отсутствует в библиотеке, команда репликации завершается ошибкой.Этот параметр не влияет на вызовы стандартных команд репликации Postgres Pro.
track_commit_timestamp(boolean) #Определяет, будет ли сохраняться время фиксации транзакций. Этот параметр можно задать только при запуске сервера. По умолчанию он имеет значение
off.
18.6.2. Главный сервер #
Эти параметры можно задать на главном/ведущем сервере, который должен передавать данные репликации одному или нескольким ведомым. Заметьте, что помимо этих параметров на ведущем сервере должен быть правильно установлен wal_level, а также может быть включена архивация WAL (см. Подраздел 18.5.3). Значения этих параметров на ведомых серверах не важны, хотя их можно подготовить заранее, на случай, если ведомый сервер придётся сделать ведущим.
synchronous_standby_names(string) #Определяет список ведомых серверов, которые могут поддерживать синхронную репликацию, как описано в Подразделе 25.2.8. Активных синхронных ведомых серверов может быть один или несколько; транзакции, ожидающие фиксации, будут завершаться только после того, как эти ведомые подтвердят получение их данных. Синхронными ведомыми будут те, имена которых указаны в этом списке и которые подключены к ведущему и принимают поток данных в реальном времени (что показывает признак
streamingв представленииpg_stat_replication). Указание нескольких имён ведомых серверов позволяет обеспечить очень высокую степень доступности и защиту от потери данных.Именем ведомого сервера в этом контексте считается значение
application_nameведомого сервера, задаваемое в свойствах подключения. При организации физической репликации оно должно задаваться в строкеprimary_conninfo; по умолчанию это значение параметра cluster_name, если он задан, илиwalreceiverв противном случае. Для логической репликации его можно задать в строке подключения для подписки (по умолчанию это имя подписки). Как задать его для других потребителей потоков репликации, вы можете узнать в их документации.В этом параметре задаётся список резервных серверов одним из следующих способом:
[FIRST]
число_синхронных[MINминимум_синхронных] (резервный_сервер[, ...] ) ANYчисло_синхронных[MINминимум_синхронных] (резервный_сервер[, ...] )резервный_сервер[, ...]Здесь
число_синхронных— это количество синхронных резервных серверов, от которых нужно получить ответ для завершения транзакций,минимум_синхронных— минимальное количество синхронных резервных серверов, которые должны быть подключены к ведущему, чтобы он продолжал подтверждать транзакции, арезервный_сервер— имя резервного сервера.FIRSTиANYопределяют метод выбора синхронных резервных из всех перечисленных серверов. УказаниеMINпозволяет избежать блокировки обслуживающего процесса в случае недоступности нескольких резервных серверов.Ключевое слово
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воспринимаются без учёта регистра. Если такое же имя оказывается у одного из ведомых серверов, егоимя_ведомогонужно заключить в двойные кавычки.Дополнительное указание
MINминимум_синхронныхослабляет требования к резервным серверам, задаваемые указаниямиFIRSTиANY. Если ведущий сервер теряет соединение с одним или несколькими синхронными резервными, он будет продолжать подтверждать транзакции, пока количество подключённых к нему резервных не меньше, чемминимум_синхронных. После восстановления соединения поведение ведущего сервера зависит от параметра synchronous_standby_gap.Третья форма использовалась в Postgres Pro до версии 9.6 и по-прежнему поддерживается. По сути она равнозначна первой с
FIRSTичислом_синхронным, равным 1. Например,FIRST 1 (s1, s2)иs1, s2действуют одинаково: в качестве синхронного ведомого выбирается либоs1, либоs2.Специальному элементу
*соответствует имя любого ведомого.Уникальность имён ведомых серверов не контролируется. В случае дублирования имён более приоритетным будет один из серверов с подходящим именем, хотя какой именно, не определено.
Примечание
Каждое
имя_ведомогодолжно задаваться в виде допустимого идентификатора SQL, кроме*. При необходимости его можно заключать в кавычки. Но заметьте, что идентификаторыимя_ведомогосравниваются с именами приложений без учёта регистра, независимо от того, заключены ли они в кавычки или нет.Если имена синхронных ведомых серверов не определены, синхронная репликация не включается и фиксируемые транзакции не будут ждать репликации. Это поведение по умолчанию. Даже когда синхронная репликация включена, для отдельных транзакций можно отключить ожидание репликации, задав для параметра synchronous_commit значение
localилиoff.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.Примечание
При настройке BiHA-кластера этот параметр хранится в файле
pg_biha/biha.confи управляется только через BiHA. Параметр нельзя изменить с помощью ALTER SYSTEM. Попытка изменить параметр вручную приведёт к ошибке. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.synchronous_standby_gap(integer) #Задаёт граничный разрыв в данных WAL между ведущим сервером и синхронными резервными серверами, в килобайтах. Положительное значение позволяет минимизировать время простоя ведущего сервера при синхронной репликации. Если отставание резервного сервера от ведущего превышает заданное значение, ведущий сервер считает резервный сервер асинхронным. Как только отставание сокращается до заданного, ведущий сервер считает резервный сервер синхронным. Подробнее об этом рассказывается в Подразделе 25.2.8.1.
Значение по умолчанию — 0, то есть обслуживающий процесс всегда блокируется, пока синхронный резервный воспроизводит данные WAL.
synchronized_standby_slots(string) #Разделённый запятыми список имён слотов резервных серверов потоковой репликации, которых будут ожидать логические передающие WAL процессы. Эти процессы будут отправлять декодированные изменения модулям только после того, как указанные слоты репликации подтвердят получение WAL. Это гарантирует, что слоты отработки отказа логической репликации не будут использовать изменения до тех пор, пока эти изменения не будут получены и сброшены на соответствующие физические резервные серверы. Если подключение логической репликации предназначено для переключения на физический резервный сервер после повышения статуса резервного сервера, в списке должен быть указан слот физической репликации для резервного сервера. Обратите внимание, что логическая репликация не будет продолжена, если слоты, указанные в
synchronized_standby_slots, не существуют или аннулированы. Кроме того, функции управления репликациейpg_replication_slot_advance,pg_logical_slot_get_changesиpg_logical_slot_peek_changesпри использовании со слотами логической отработки отказов будут блокироваться до тех пор, пока все физические слоты, указанные вsynchronized_standby_slots, не подтвердят получение WAL.Резервные серверы, соответствующие слотам физической репликации в
synchronized_standby_slots, должны установитьsync_replication_slots = true, чтобы получать изменения слотов отработки отказа логической репликации от ведущего сервера.
18.6.3. Ведомые серверы #
Эти параметры управляют поведением ведомого сервера, который будет получать данные репликации. На ведущем сервере они не играют никакой роли.
primary_conninfo(string) #Указывает строку подключения резервного сервера к передающему. Формат строки описан в Подразделе 33.1.1. Вместо опущенных параметров подключения используются соответствующие переменные окружения (см. Раздел 33.15). Если же и переменные не установлены, используются значения по умолчанию.
В строке подключения должно задаваться имя (или адрес) передающего сервера, а также номер порта, если он отличается от подразумеваемого по умолчанию резервным. Также в ней указывается имя пользователя, соответствующее роли с необходимыми правами на передающем сервере (см. Подраздел 25.2.5.1). Если сервер осуществляет аутентификацию по паролю, дополнительно потребуется задать пароль. Его можно указать как в строке
primary_conninfo, так и отдельно, в файле~/.pgpassна резервном сервере (для базы данныхreplication).Для синхронизации слотов репликации (см. Подраздел 48.2.3) также необходимо указать допустимое имя
dbnameв строкеprimary_conninfo. Оно используется только для синхронизации слотов и игнорируется при потоковой передаче.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера. Если значение данного параметра меняется во время работы процесса-приёмника WAL, этому процессу посылается сигнал для отключения, и ожидается, что он перезапустится с новым значением (если только определена непустая строкаprimary_conninfo). Этот параметр оказывает влияние только при работе сервера в режиме ведомого.Примечание
При настройке BiHA-кластера этот параметр хранится в файле
pg_biha/biha.confи управляется только через BiHA. Параметр нельзя изменить с помощью ALTER SYSTEM. Попытка изменить параметр вручную приведёт к ошибке.primary_slot_name(string) #Дополнительно задаёт заранее созданный слот, который будет использоваться при подключении к передающему серверу по протоколу потоковой репликации для управления освобождением ресурсов вышестоящего узла (см. Подраздел 25.2.6). Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера. Если значение данного параметра меняется во время работы процесса-приёмника WAL, этому процессу посылается сигнал для отключения, и ожидается, что он перезапустится с новым значением. Этот параметр не действует, если строкаprimary_conninfoне определена или сервер работает не в режиме ведомого.Примечание
При настройке BiHA-кластера этот параметр хранится в файле
pg_biha/biha.confи управляется только через BiHA. Параметр нельзя изменить с помощью ALTER SYSTEM. Попытка изменить параметр вручную приведёт к ошибке. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.hot_standby(boolean) #Определяет, можно ли будет подключаться к серверу и выполнять запросы в процессе восстановления, как описано в Разделе 25.4. Значение по умолчанию —
on(подключения разрешаются). Задать этот параметр можно только при запуске сервера. Данный параметр играет роль только в режиме ведомого сервера или при восстановлении архива.Примечание
При настройке BiHA-кластера этот параметр используется со значением по умолчанию. Не рекомендуется изменять параметр вручную, так как это может повлиять на нормальную работу кластера. За подробной информацией о параметрах Postgres Pro, которые используются и изменяются решением BiHA, обратитесь к Конфигурация Postgres Pro.
max_standby_archive_delay(integer) #В режиме горячего резерва этот параметр определяет, как долго должен ждать ведомый сервер, прежде чем отменять запросы, конфликтующие с очередными изменениями в WAL, как описано в Подразделе 25.4.2. Задержка
max_standby_archive_delayприменяется при обработке данных WAL, считываемых из архива (не текущих данных). Если это значение задаётся без единиц измерения, оно считается заданным в миллисекундах. Значение по умолчанию равно 30 секундам. При значении, равном -1, ведомый может ждать завершения конфликтующих запросов неограниченное время. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Заметьте, что параметр
max_standby_archive_delayопределяет не максимальное время, которое отводится для выполнения каждого запроса, а максимальное общее время, за которое должны быть применены изменения из одного сегмента WAL. Таким образом, если один запрос привёл к значительной задержке при обработке сегмента WAL, остальным конфликтующим запросам будет отведено гораздо меньше времени.max_standby_streaming_delay(integer) #В режиме горячего резерва этот параметр определяет, как долго должен ждать ведомый сервер, прежде чем отменять запросы, конфликтующие с очередными изменениями в WAL, как описано в Подразделе 25.4.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. В этом сообщении передаются следующие позиции в журнале предзаписи: позиция изменений записанных, изменений, сохранённых на диске, и изменений применённых. Значение параметра определяет максимальный интервал между сообщениями. Сообщения о состоянии передаются при каждом продвижении позиций записанных или сохранённых на диске изменений, или с интервалом, заданным этим параметром, если он имеет ненулевое значение. В некоторых случаях сообщения о состоянии отправляются без учёта данного параметра; например, когда завершается обработка существующего WAL или когда переменнаяsynchronous_commitимеет значениеremote_apply. Таким образом, последняя переданная позиция применённых изменений может немного отставать от фактической в текущий момент. Если это значение задаётся без единиц измерения, оно считается заданным в секундах. Значение по умолчанию равно 10 секундам. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.hot_standby_feedback(boolean) #Определяет, будет ли сервер горячего резерва сообщать ведущему или вышестоящему ведомому о запросах, которые он выполняет в данный момент. Это позволяет исключить необходимость отмены запросов, вызванную очисткой записей, но при некоторых типах нагрузки это может приводить к раздуванию базы данных на ведущем сервере. Эти сообщения о запросах будут отправляться не чаще, чем раз в интервал, задаваемый параметром
wal_receiver_status_interval. Значение данного параметра по умолчанию —off. Задать этот параметр можно только вpostgresql.confили в командной строке при запуске сервера.Если используется каскадная репликация, сообщения о запросах передаются выше, пока в итоге не достигнут ведущего сервера. На промежуточных серверах эта информация больше никак не задействуется.
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.
Задержка добавляется, как только восстанавливаемая база данных достигает согласованного состояния, и исключается, когда ведущий сервер переключается в режим основного. После переключения ведущий сервер завершает восстановление незамедлительно.
Записи WAL должны храниться на резервном сервере, пока они не будут применены. Таким образом, чем больше задержка, тем больший объём файлов WAL необходимо накапливать, и тем больше дискового пространства потребуется для каталога
pg_walна ведомом сервере.Данный параметр предназначен для применения в конфигурациях с потоковой репликацией; однако если он задан, он будет учитываться во всех случаях, кроме восстановления после сбоя. Задержка, устанавливаемая этим параметром, влияет и на работу механизма
hot_standby_feedback, что может привести к раздуванию базы на главном сервере; использовать данный параметр при включении этого механизма следует с осторожностью.Предупреждение
Этот параметр влияет на синхронную репликацию, когда
synchronous_commitимеет значениеremote_apply; каждыйCOMMITбудет ждать подтверждения применения.Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.sync_replication_slots(boolean) #Позволяет физическому резервному серверу синхронизировать слоты логической репликации для отработки отказа с ведущим сервером, чтобы подписчики логической репликации могли возобновить репликацию с нового ведущего сервера после отработки отказа.
По умолчанию отключён. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.
18.6.4. Подписчики #
Эти параметры управляют поведением подписчика логической репликации. На публикующем сервере они не играют роли. За подробностями обратитесь к Разделу 29.11.
max_replication_slots(integer) #Указывает, сколько источников репликации (см. Главу 49) можно отслеживать одновременно, по сути ограничивая количество подписок на логическую репликацию, которые могут быть созданы на сервере. Если установленное значение будет меньше, чем текущее количество отслеживаемых источников репликации (показываемое в pg_replication_origin_status), сервер не запустится. Значение параметра
max_replication_slotsдолжно быть не менее числа подписок, добавляемого подписчику, плюс некоторый резерв для синхронизации таблиц.Обратите внимание, что этот параметр также применяется на стороне передающего сервера, но с другим значением.
max_logical_replication_workers(integer) #Задаёт максимально возможное число рабочих процессов логической репликации. В это число входят как ведущие и параллельные рабочие процессы, применяющие изменения, так и процессы, синхронизирующие таблицы.
Рабочие процессы логической репликации берутся из пула, контролируемого параметром
max_worker_processes.Значение по умолчанию — 4. Этот параметр можно задать только при запуске сервера.
max_sync_workers_per_subscription(integer) #Максимальное число рабочих процессов, выполняющих синхронизацию, для одной подписки. Этот параметр управляет степенью распараллеливания копирования начальных данных в процессе инициализации подписки или при добавлении новых таблиц.
В настоящее время одну таблицу может обрабатывать только один рабочий процесс синхронизации.
Рабочие процессы синхронизации берутся из пула, контролируемого параметром
max_logical_replication_workers.Значение по умолчанию — 2. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.max_parallel_apply_workers_per_subscription(integer) #Максимальное число параллельных рабочих процессов, применяющих изменения, для одной подписки. Этот параметр управляет степенью распараллеливания для потоковой передачи незавершённых транзакций с параметром подписки
streaming = parallel.Рабочие процессы применения изменений берутся из пула, контролируемого параметром
max_logical_replication_workers.Значение по умолчанию — 2. Задать этот параметр можно только в
postgresql.confили в командной строке при запуске сервера.
18.6. Replication #
These settings control the behavior of the built-in streaming replication feature (see Section 25.2.5), and the built-in logical replication feature (see Chapter 29).
For streaming replication, servers will be either a primary or a standby server. Primaries can send data, while standbys are always receivers of replicated data. When cascading replication (see Section 25.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 primary server. Settings may vary across the cluster without problems if that is required.
For logical replication, publishers (servers that do CREATE PUBLICATION) replicate data to subscribers (servers that do CREATE SUBSCRIPTION). Servers can also be publishers and subscribers at the same time. Note, the following sections refer to publishers as "senders". For more details about logical replication configuration settings refer to Section 29.11.
18.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 primary is always a sending server, so these parameters must always be set on the primary. The role and meaning of these parameters does not change after a standby becomes the primary.
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 primary server. Otherwise, queries will not be allowed in the standby server.
Note
When setting up the BiHA cluster, this parameter is modified by bihactl automatically. It is not recommended to modify it manually, since normal operation of the cluster may be affected. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.
max_replication_slots(integer) #Specifies the maximum number of replication slots (see Section 25.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.Note that this parameter also applies on the subscriber side, but with a different meaning.
Note
When setting up the BiHA cluster, this parameter is set by bihactl automatically. It is not recommended to modify it manually, since normal operation of the cluster may be affected. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.
output_plugin_libraries(string) #Lists the libraries installed in dynamic_library_path that are also trusted for use as logical output plugins by replication clients. Any logical decoding or replication requests for other libraries will be refused. All users are subject to this restriction. The default is
'pgoutput, test_decoding, dbcopies_decoding'.The format is a comma-separated list of library names, where each name is interpreted as for the
LOADcommand (but logical decoding clients must specify a plugin name that exactly matches an entry in the list, without variations in case or path structure). Whitespace between entries is ignored; surround a library name with double quotes if you need to include whitespace or commas in the name.It is the responsibility of the server administrator to ensure that libraries added to this list do not unintentionally give additional privileges to non-superusers when they are loaded into the server.
Note
When updating the server from a version that does not have the
output_plugin_librariesparameter, the following query can help construct the list of plugins that are required by all persistent logical replication slots:SELECT DISTINCT plugin FROM pg_replication_slots WHERE plugin IS NOT NULL;
Review the list carefully for safety before adjusting
output_plugin_libraries.The above query can only display plugins which were successfully added to replication slots at some point in the past. Newly refused requests will appear in the logs with a message similar to
ERROR: library "..." may not be used as an output plugin DETAIL: The configuration parameter "output_plugin_libraries" (currently 'pgoutput, test_decoding') does not name this library as a trusted output plugin. HINT: If it is safe for all REPLICATION users to use this library as an output plugin, add it to "output_plugin_libraries" and reload the server configuration.
wal_keep_size(integer) #Specifies the minimum size of past WAL files 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.Note
When setting up the BiHA cluster, this parameter is modified by bihactl automatically. If the value has already been set, BiHA uses the existing one. You can modify the value if required. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.
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.Note
When setting up the BiHA cluster, this parameter is set by bihactl automatically. If the value has already been set, BiHA uses the existing one. You can modify the value if required. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.
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.
wal_sender_shutdown_timeout(integer) #Specifies the maximum time the server waits during shutdown for all WAL data to be replicated to the receiver. If this value is specified without units, it is taken as milliseconds. A value of
-1(the default) disables the timeout mechanism.When replication is in use, the sending server normally waits until all WAL data has been transferred to the receiver before completing shutdown. This helps keep sender and receiver in sync after shutdown, which is especially important for physical replication switchovers, but it can delay shutdown.
If this parameter is set, the server stops waiting and completes shutdown when the timeout expires. This can shorten shutdown time, for example, when replication is slow on high-latency networks or when a logical replication apply worker is blocked waiting for locks. However, in this case the sender and receiver may be out of sync after shutdown.
This parameter can be set in
primary_conninfoand in theCONNECTIONclause ofCREATE SUBSCRIPTION(for example, includeoptions=-cwal_sender_shutdown_timeout=10sin the connection string), allowing different timeouts per replication connection. For example, when both physical and logical replication are used, it can be disabled for physical replication (e.g., for switchovers) while enabled for logical replication to limit shutdown time.walsender_plugin_libraries(string) #Specifies one or more libraries with custom replication commands. The value must be a comma-separated list of library names.
When a special replication command starting with the
'PGPRO_CALL_PLUGIN'literal and followed by a custom library name is sent to the Postgres Pro server, the server looks for the specified library in thewalsender_plugin_librarieslist. If the library is found in the Postgres Pro library directories, the server searches for the specified command in the library and executes it if present. If the library is not found, or if a certain command is not present in the library, the replication command fails.This parameter does not affect calls to standard Postgres Pro replication commands.
track_commit_timestamp(boolean) #Record commit time of transactions. This parameter can only be set at server start. The default value is
off.
18.6.2. Primary Server #
These parameters can be set on the 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 primary server, and optionally WAL archiving can be enabled as well (see Section 18.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 primary.
synchronous_standby_names(string) #Specifies a list of standby servers that can support synchronous replication, as described in Section 25.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[MINnum_sync_min] (standby_name[, ...] ) ANYnum_sync[MINnum_sync_min] (standby_name[, ...] )standby_name[, ...]where
num_syncis the number of synchronous standbys that transactions need to wait for replies from,num_sync_minis the minimum number of synchronous standbys that must be connected to the primary server for it to continue confirming transactions, andstandby_nameis the name of a standby server.FIRSTandANYspecify the method to choose synchronous standbys from the listed servers.MINallows to avoid the backend blocking if some of the standbys are temporarily unavailable.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 optional
MINnum_sync_minsetting relaxes the standby requirements specified byFIRSTandANY. If the primary loses connection to one or more synchronous standbys, it continues confirming transactions while at leastnum_sync_minstandby servers are available. Once the connection is restored, the behavior of the primary server depends on the synchronous_standby_gap setting.The third syntax was used before Postgres Pro 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.Note
When setting up the BiHA cluster, this parameter is stored in the
pg_biha/biha.conffile and is managed by BiHA only. You cannot modify the parameter using ALTER SYSTEM. An attempt to change the parameter manually returns an error. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.synchronous_standby_gap(integer) #Specifies the WAL data gap between the primary server and its synchronous standbys, in kilobytes. Setting this parameter to a positive value allows to minimize the primary server downtime when using synchronous replication. If a standby lags behind the primary for more than the specified gap, the primary server considers the standby as asynchronous. Once the standby reaches the specified gap, the primary considers the standby as synchronous. See Section 25.2.8.1 for details.
The default value is 0, which means that the backend is always blocked while a synchronous standby replays WAL data.
synchronized_standby_slots(string) #A comma-separated list of streaming replication standby server slot names that logical WAL sender processes will wait for. Logical WAL sender processes will send decoded changes to plugins only after the specified replication slots confirm receiving WAL. This guarantees that logical replication failover slots do not consume changes until those changes are received and flushed to corresponding physical standbys. If a logical replication connection is meant to switch to a physical standby after the standby is promoted, the physical replication slot for the standby should be listed here. Note that logical replication will not proceed if the slots specified in the
synchronized_standby_slotsdo not exist or are invalidated. Additionally, the replication management functionspg_replication_slot_advance,pg_logical_slot_get_changes, andpg_logical_slot_peek_changes, when used with logical failover slots, will block until all physical slots specified insynchronized_standby_slotshave confirmed WAL receipt.The standbys corresponding to the physical replication slots in
synchronized_standby_slotsmust configuresync_replication_slots = trueso they can receive logical failover slot changes from the primary.
18.6.3. Standby Servers #
These settings control the behavior of a standby server that is to receive replication data. Their values on the primary 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.15) 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 25.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).For replication slot synchronization (see Section 48.2.3), it is also necessary to specify a valid
dbnamein theprimary_conninfostring. This will only be used for slot synchronization. It is ignored for streaming.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.Note
When setting up the BiHA cluster, this parameter is stored in the
pg_biha/biha.conffile and is managed by BiHA only. You cannot modify the parameter using ALTER SYSTEM. An attempt to change the parameter manually returns an error.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 25.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.Note
When setting up the BiHA cluster, this parameter is stored in the
pg_biha/biha.conffile and is managed by BiHA only. You cannot modify the parameter using ALTER SYSTEM. An attempt to change the parameter manually returns an error. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.hot_standby(boolean) #Specifies whether or not you can connect and run queries during recovery, as described in Section 25.4. 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.Note
When setting up the BiHA cluster, this parameter is used with the default value. It is not recommended to modify it manually, since normal operation of the cluster may be affected. For more information about Postgres Pro parameters used and modified by BiHA, see Postgres Pro Configuration.
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 25.4.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 25.4.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 as often as specified by this parameter if set to a non-zero value. There are additional cases where updates are sent while ignoring this parameter; for example, when processing of the existing WAL completes or whensynchronous_commitis set toremote_apply. 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. 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.
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 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 number of times an infrastructure is accessed is taken into account.
In logical replication, this parameter also limits how often a failing replication apply worker will be respawned.
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 primary. 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 primary 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 primary 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.
WAL records must be kept on the standby until they are ready to be applied. Therefore, longer delays will result in a greater accumulation of WAL files, increasing disk space requirements for the standby's
pg_waldirectory.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 primary; 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.sync_replication_slots(boolean) #It enables a physical standby to synchronize logical failover slots from the primary server so that logical subscribers can resume replication from the new primary server after failover.
It is disabled by default. This parameter can only be set in the
postgresql.conffile or on the server command line.
18.6.4. Subscribers #
These settings control the behavior of a logical replication subscriber. Their values on the publisher are irrelevant. See Section 29.11 for more details.
max_replication_slots(integer) #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 to a lower value than the current number of tracked replication origins (reflected in pg_replication_origin_status) will prevent the server from starting.
max_replication_slotsmust be set to at least the number of subscriptions that will be added to the subscriber, plus some reserve for table synchronization.Note that this parameter also applies on a sending server, but with a different meaning.
max_logical_replication_workers(integer) #Specifies maximum number of logical replication workers. This includes leader apply workers, parallel 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.max_parallel_apply_workers_per_subscription(integer) #Maximum number of parallel apply workers per subscription. This parameter controls the amount of parallelism for streaming of in-progress transactions with subscription parameter
streaming = parallel.The parallel apply 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.