Тип: | string |
Контекст: | sighup |
Перезапуск: | false |
Определяет список ведомых серверов, которые могут поддерживать синхронную репликацию, как описано в 6. Активных синхронных ведомых серверов может быть один или несколько; транзакции, ожидающие фиксации, будут завершаться только после того, как эти ведомые подтвердят получение их данных. Синхронными ведомыми будут те, имена которых указаны в этом списке и которые подключены к ведущему и принимают поток данных в реальном времени (что показывает признак streaming
в представлении pg_stat_replication
). Указание нескольких имён ведомых серверов позволяет обеспечить очень высокую степень доступности и защиту от потери данных.
Именем ведомого сервера в этом контексте считается значение application_name этого сервера, задаваемое в свойствах подключения. При организации физической репликации оно задаётся в строке primary_conninfo
в recovery.conf (по умолчанию — 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
воспринимаются без учёта регистра. Если такое же имя оказывается у одного из ведомых серверов, его имя_ведомого нужно заключить в двойные кавычки.
Третья форма использовалась в &project; до версии 9.6 и по-прежнему поддерживается. По сути она равнозначна первой с FIRST
и числом_синхронным, равным 1. Например, FIRST 1 (s1, s2)
и s1, s2
действуют одинаково: в качестве синхронного ведомого выбирается либо s1
, либо s2
.
Специальному элементу *
соответствует любой сервер.
Уникальность имён ведомых серверов не контролируется. В случае дублирования имён более приоритетным будет один из серверов с подходящим именем, хотя какой именно, не определено.
Каждое имя_ведомого должно задаваться в виде допустимого идентификатора SQL, кроме *
. При необходимости его можно заключать в кавычки. Но заметьте, что идентификаторы имя_ведомого сравниваются с именами приложений без учёта регистра, независимо от того, заключены ли они в кавычки или нет.
Если имена синхронных ведомых серверов не определены, синхронная репликация не включается и фиксируемые транзакции не будут ждать репликации. Это поведение по умолчанию. Даже когда синхронная репликация включена, для отдельных транзакций можно отключить ожидание репликации, задав для параметра synchronous_commit значение local
или off
.
Задать этот параметр можно только в postgresql.conf или в командной строке при запуске сервера.
Рекомендации [EN]
На StackOverflow
На pgsql-hackers
- Allow logical failover slots to wait on synchronous replication
- Resetting synchronous_standby_names can wait for CHECKPOINT to finish
- RE: Resetting synchronous_standby_names can wait for CHECKPOINT to finish
- Re: logical decoding and replication of sequences, take 2
- Re: speed up a logical replica setup