Postgresql 中文操作指南

Chapter 31. Logical Replication

Table of Contents

逻辑复制是一种复制数据对象及其更改的方法，它基于其复制标识（通常是主键）。我们使用术语逻辑与物理复制相对，物理复制使用确切的块地址和逐字节复制。PostgreSQL 同时支持这两种机制，请参阅 Chapter 27 。逻辑复制允许对数据复制和安全性进行细粒度控制。

Logical replication is a method of replicating data objects and their changes, based upon their replication identity (usually a primary key). We use the term logical in contrast to physical replication, which uses exact block addresses and byte-by-byte replication. PostgreSQL supports both mechanisms concurrently, see Chapter 27. Logical replication allows fine-grained control over both data replication and security.

逻辑复制使用 publish 和 subscribe 模型，其中一个或多个 subscribers 订阅一个或多个 publications 在 publisher 节点上。订阅者从其订阅的发布中提取数据，并且随后可能会重新发布数据以允许级联复制或更复杂的配置。

Logical replication uses a publish and subscribe model with one or more subscribers subscribing to one or more publications on a publisher node. Subscribers pull data from the publications they subscribe to and may subsequently re-publish data to allow cascading replication or more complex configurations.

表的逻辑复制通常从获取发布者数据库上的数据快照并将其复制到订阅者开始。完成此操作后，发布者上的更改将实时发送给订阅者。订阅者以与发布者相同的顺序应用数据，以便为单个订阅中的发布保证事务一致性。此数据复制方法有时称为事务复制。

Logical replication of a table typically starts with taking a snapshot of the data on the publisher database and copying that to the subscriber. Once that is done, the changes on the publisher are sent to the subscriber as they occur in real-time. The subscriber applies the data in the same order as the publisher so that transactional consistency is guaranteed for publications within a single subscription. This method of data replication is sometimes referred to as transactional replication.

逻辑复制的典型用例是：

The typical use-cases for logical replication are:

订阅者数据库的行为与任何其他 PostgreSQL 实例相同，并且可以通过定义其自己的发布使其用作其他数据库的发布者。当应用程序将订阅者视为只读时，单个订阅就不会产生冲突。另一方面，如果应用程序或同一组表的其他订阅者进行了其他写入，则可能会出现冲突。

The subscriber database behaves in the same way as any other PostgreSQL instance and can be used as a publisher for other databases by defining its own publications. When the subscriber is treated as read-only by application, there will be no conflicts from a single subscription. On the other hand, if there are other writes done either by an application or by other subscribers to the same set of tables, conflicts can arise.