Chapter 31. Logical Replication

Table of Contents

31.1. Publication
31.2. Subscription
31.2.1. Replication Slot Management
31.2.2. Examples - Setup Logical Replication
31.2.3. Examples - Deferred Replication Slot Creation
31.3. Row Filters
31.3.1. Row Filter Rules
31.3.2. Expression Restrictions
31.3.3. UPDATE Transformations
31.3.4. Partitioned Tables
31.3.5. Initial Data Synchronization
31.3.6. Combining Multiple Row Filters
31.3.7. Examples
31.4. Column Lists
31.4.1. Combining Multiple Column Lists
31.4.2. Examples
31.5. Conflicts
31.6. Restrictions
31.7. Architecture
31.7.1. Initial Snapshot
31.8. Monitoring
31.9. Security
31.10. Configuration Settings
31.11. Quick Setup

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.

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:

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.