- Logical replication sends the changes on the publisher to the subscriber as
+ Logical replication sends changes on the publisher 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
- Firing triggers for individual changes as they are incoming to
+ Firing triggers for individual changes as they arrive on the
subscriber.
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 application or other
- subscribers to the same set of tables conflicts can arise.
+ 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.
Publication
- A publication object can be defined on any physical
+ A publication can be defined on any physical
replication master. The node where a publication is defined is referred to
as publisher. A publication is a set of changes
- generated from a group of tables, and might also be described as a change
- set or replication set. Each publication exists in only one database.
+ generated from a table or a group of tables, and might also be described as
+ a change set or replication set. Each publication exists in only one database.
- Publications can choose to limit the changes they produce to show
+ Publications can choose to limit the changes they produce to
any combination of INSERT, UPDATE, and
- DELETE in a similar way to the way triggers are fired by
+ DELETE, similar to how triggers are fired by
particular event types. If a table without a REPLICA
IDENTITY is added to a publication that
replicates UPDATE or DELETE
A publication is created using the
- command and may be later altered or dropped using corresponding commands.
+ command and may later be altered or dropped using corresponding commands.
A subscription is the downstream side of logical
replication. The node where a subscription is defined is referred to as
- the subscriber. Subscription defines the connection
+ the subscriber. A subscription defines the connection
to another database and set of publications (one or more) to which it wants
- to be subscribed.
+ to subscribe.
A subscriber node may have multiple subscriptions if desired. It is
possible to define multiple subscriptions between a single
- publisher-subscriber pair, in which case extra care must be taken to ensure
+ publisher-subscriber pair, in which case care must be taken to ensure
that the subscribed publication objects don't overlap.
- Subscriptions are not dumped by pg_dump by default but
- can be requested using the command-line
- option .
+ Subscriptions are not dumped by pg_dump by default, but
+ this can be requested using the command-line
+ option .
- The schema definitions are not replicated and the published tables must
- exist on the subsriber for replication to work. Only regular tables may be
+ The schema definitions are not replicated, and the published tables must
+ exist on the subscriber. Only regular tables may be
the target of replication. For example, you can't replicate to a view.
Conflicts
- The logical replication behaves similarly to normal DML operations in that
+ Logical replication behaves similarly to normal DML operations in that
the data will be updated even if it was changed locally on the subscriber
- node. If the incoming data violates any constraints the replication will
+ node. If incoming data violates any constraints the replication will
stop. This is referred to as a conflict. When
replicating UPDATE or DELETE
operations, missing data will not produce a conflict and such operations
transaction that conflicts with the existing data. The transaction can be
skipped by calling the
pg_replication_origin_advance() function with
- a
node_name corresponding to the subscription name
.- The current position of origins can be seen in the
+ a
node_name corresponding to the subscription name
,+ and a position. The current position of origins can be seen in the
pg_replication_origin_status system view.
Logical replication is built with an architecture similar to physical
streaming replication (see ). It is
- implemented by walsender
and the apply
- processes. The walsender starts logical decoding (described
+ implemented by walsender
and apply
+ processes. The walsender process starts logical decoding (described
in ) of the WAL and loads the standard
logical decoding plugin (pgoutput). The plugin transforms the changes read
from WAL to the logical replication protocol
according to the publication specification. The data is then continuously
transferred using the streaming replication protocol to the apply worker,
which maps the data to local tables and applies the individual changes as
- they are received in exact transactional order.
+ they are received, in correct transactional order.
Monitoring
- Because logical replication is based on similar architecture as
- physical streaming replication
- the monitoring on a publication node is very similar to monitoring of
+ Because logical replication is based on a similar architecture as
+ physical streaming replication,
+ the monitoring on a publication node is similar to monitoring of a
physical replication master
(see ).
Security
- Logical replication connections occur in the same way as physical streaming
- replication. It requires access to be specifically given using
+ Logical replication connections occur in the same way as with physical streaming
+ replication. It requires access to be explicitly given using
pg_hba.conf. The role used for the replication
connection must have the REPLICATION attribute. This
gives a role access to both logical and physical replication.
On the publisher side, wal_level must be set to
logical, and max_replication_slots
- has to be set to at least the number of subscriptions expected to connect.
+ must be set to at least the number of subscriptions expected to connect.
And max_wal_senders should be set to at least the same
as max_replication_slots plus the number of physical replicas
that are connected at the same time.
The subscriber also requires the max_replication_slots
to be set. In this case it should be set to at least the number of
subscriptions that will be added to the subscriber.
- max_logical_replication_workers has to be set to at
+ max_logical_replication_workers must be set to at
least the number of subscriptions. Additionally the
max_worker_processes may need to be adjusted to
accommodate for replication workers, at least
projects / postgresql.git / commitdiff