begriffs open source - ai-pg/blob - full-docs/txt/logical-replication-architecture.txt

   1
   2 29.9. Architecture #
   3
   4    29.9.1. Initial Snapshot
   5
   6    Logical replication is built with an architecture similar to physical
   7    streaming replication (see Section 26.2.5). It is implemented by
   8    walsender and apply processes. The walsender process starts logical
   9    decoding (described in Chapter 47) of the WAL and loads the standard
  10    logical decoding output plugin (pgoutput). The plugin transforms the
  11    changes read from WAL to the logical replication protocol (see
  12    Section 54.5) and filters the data according to the publication
  13    specification. The data is then continuously transferred using the
  14    streaming replication protocol to the apply worker, which maps the data
  15    to local tables and applies the individual changes as they are
  16    received, in correct transactional order.
  17
  18    The apply process on the subscriber database always runs with
  19    session_replication_role set to replica. This means that, by default,
  20    triggers and rules will not fire on a subscriber. Users can optionally
  21    choose to enable triggers and rules on a table using the ALTER TABLE
  22    command and the ENABLE TRIGGER and ENABLE RULE clauses.
  23
  24    The logical replication apply process currently only fires row
  25    triggers, not statement triggers. The initial table synchronization,
  26    however, is implemented like a COPY command and thus fires both row and
  27    statement triggers for INSERT.
  28
  29 29.9.1. Initial Snapshot #
  30
  31    The initial data in existing subscribed tables are snapshotted and
  32    copied in parallel instances of a special kind of apply process. These
  33    special apply processes are dedicated table synchronization workers,
  34    spawned for each table to be synchronized. Each table synchronization
  35    process will create its own replication slot and copy the existing
  36    data. As soon as the copy is finished the table contents will become
  37    visible to other backends. Once existing data is copied, the worker
  38    enters synchronization mode, which ensures that the table is brought up
  39    to a synchronized state with the main apply process by streaming any
  40    changes that happened during the initial data copy using standard
  41    logical replication. During this synchronization phase, the changes are
  42    applied and committed in the same order as they happened on the
  43    publisher. Once synchronization is done, control of the replication of
  44    the table is given back to the main apply process where replication
  45    continues as normal.
  46
  47 Note
  48
  49    The publication publish parameter only affects what DML operations will
  50    be replicated. The initial data synchronization does not take this
  51    parameter into account when copying the existing table data.
  52
  53 Note
  54
  55    If a table synchronization worker fails during copy, the apply worker
  56    detects the failure and respawns the table synchronization worker to
  57    continue the synchronization process. This behaviour ensures that
  58    transient errors do not permanently disrupt the replication setup. See
  59    also wal_retrieve_retry_interval.