Postgresql 中文操作指南

49.8. Synchronous Replication Support for Logical Decoding #

49.8.1. Overview #

可以利用逻辑解码为 streaming replication构建与同步复制具有相同用户界面的 synchronous replication解决方案。为此，必须使用流复制界面（请参阅 Section 49.3）来流出数据。客户端必须发送 Standby status update (F)（请参阅 Section 55.4）消息，就像流复制客户端一样执行的操作。

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 55.4) messages, just like streaming replication clients do.

Note

通过逻辑解码接收更改的同步副本将在单个数据库的范围内工作。而与之相反，synchronous_standby_names 目前是服务器范围内的，这意味着如果同时使用多个数据库，此技术将无法正常工作。

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 #

在同步复制设置中，如果事务排他锁定 [用户] 目录表，可能会发生死锁。有关用户目录表的详细信息，请参阅 Section 49.6.2。这是因为事务的逻辑解码可以锁定目录表以访问它们。为了避免这种情况，用户必须避免对 [用户] 目录表进行排他锁定。这可以通过以下方式实现：

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:

请注意，这些可能导致死锁的命令不仅适用于上述明确指示的系统目录表，还适用于任何其他 [用户] 目录表。

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.