49.8. Поддержка синхронной репликации для логического декодирования
49.8.1. Обзор
Логическое декодирование может использоваться для реализации синхронной репликации с тем же внешним интерфейсом, что и синхронная репликация поверх потоковой репликации. Для этого потоковая передача данных должна происходить через интерфейс потоковой репликации (см. Раздел 49.3). Клиенты такой репликации должны посылать сообщения Обновление состояния резервного сервера (F) (см. Раздел 53.4), как и клиенты потоковой репликации.
Примечание
Синхронная реплика, получающая изменения через логическое декодирование, будет работать в рамках одной базы данных. Так как synchronous_standby_names в настоящее время, напротив, устанавливается на уровне сервера, это означает, что этот подход не будет работать корректно при использовании нескольких баз данных.
49.8.2. Ограничения
В схеме с логической репликацией возможна взаимоблокировка, если транзакция в исключительном режиме заблокирует таблицы каталога (в том числе пользовательские). Пользовательские таблицы каталога описаны в Подразделе 49.6.2. Это происходит, потому что в процессе логического декодирования транзакций при обращении к таблицам каталога они блокируются. Во избежание этого пользователи должны воздерживаться от исключительной блокировки таблиц каталога (в том числе пользовательских). Вызвать такую блокировку могут следующие обстоятельства:
Установление явной блокировки (командой
LOCK) для каталогаpg_classв транзакции.Выполнение
CLUSTERдля каталогаpg_classв транзакции.Выполнение
PREPARE TRANSACTIONпосле командыLOCK, блокирующейpg_class, при работающем логическом декодировании двухфазных транзакций.Выполнение
PREPARE TRANSACTIONпосле командыCLUSTERдляpg_triggerпри работающем логическом декодировании двухфазных транзакций. Это приведёт к взаимоблокировке только в том случае, если у публикуемой таблицы есть триггер.Выполнение
TRUNCATEдля таблицы каталога (в том числе пользовательской) в транзакции.
Заметьте, что эти команды, способные вызвать взаимоблокировку, могут применяться не только к явно указанным выше таблицам системного каталога, но также и к любым другим таблицам каталога (в том числе пользовательским).
49.8. Synchronous Replication Support for Logical Decoding
49.8.1. Overview
Logical decoding can be used to build synchronous replication solutions with the same user interface as synchronous replication for streaming replication. To do this, the streaming replication interface (see Section 49.3) must be used to stream out data. Clients have to send Standby status update (F) (see Section 53.4) messages, just like streaming replication clients do.
Note
A synchronous replica receiving changes via logical decoding will work in the scope of a single database. Since, in contrast to that, synchronous_standby_names currently is server wide, this means this technique will not work properly if more than one database is actively used.
49.8.2. Caveats
In synchronous replication setup, a deadlock can happen, if the transaction has locked [user] catalog tables exclusively. See Section 49.6.2 for information on user catalog tables. This is because logical decoding of transactions can lock catalog tables to access them. To avoid this users must refrain from taking an exclusive lock on [user] catalog tables. This can happen in the following ways:
Issuing an explicit
LOCKonpg_classin a transaction.Perform
CLUSTERonpg_classin a transaction.PREPARE TRANSACTIONafterLOCKcommand onpg_classand allow logical decoding of two-phase transactions.PREPARE TRANSACTIONafterCLUSTERcommand onpg_triggerand allow logical decoding of two-phase transactions. This will lead to deadlock only when published table have a trigger.Executing
TRUNCATEon [user] catalog table in a transaction.
Note that these commands that can cause deadlock apply to not only explicitly indicated system catalog tables above but also to any other [user] catalog table.
