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

   1
   2 Chapter 29. Logical Replication
   3
   4    Table of Contents
   5
   6    29.1. Publication
   7
   8         29.1.1. Replica Identity
   9
  10    29.2. Subscription
  11
  12         29.2.1. Replication Slot Management
  13         29.2.2. Examples: Set Up Logical Replication
  14         29.2.3. Examples: Deferred Replication Slot Creation
  15
  16    29.3. Logical Replication Failover
  17    29.4. Row Filters
  18
  19         29.4.1. Row Filter Rules
  20         29.4.2. Expression Restrictions
  21         29.4.3. UPDATE Transformations
  22         29.4.4. Partitioned Tables
  23         29.4.5. Initial Data Synchronization
  24         29.4.6. Combining Multiple Row Filters
  25         29.4.7. Examples
  26
  27    29.5. Column Lists
  28
  29         29.5.1. Examples
  30
  31    29.6. Generated Column Replication
  32    29.7. Conflicts
  33    29.8. Restrictions
  34    29.9. Architecture
  35
  36         29.9.1. Initial Snapshot
  37
  38    29.10. Monitoring
  39    29.11. Security
  40    29.12. Configuration Settings
  41
  42         29.12.1. Publishers
  43         29.12.2. Subscribers
  44
  45    29.13. Upgrade
  46
  47         29.13.1. Prepare for Publisher Upgrades
  48         29.13.2. Prepare for Subscriber Upgrades
  49         29.13.3. Upgrading Logical Replication Clusters
  50
  51    29.14. Quick Setup
  52
  53    Logical replication is a method of replicating data objects and their
  54    changes, based upon their replication identity (usually a primary key).
  55    We use the term logical in contrast to physical replication, which uses
  56    exact block addresses and byte-by-byte replication. PostgreSQL supports
  57    both mechanisms concurrently, see Chapter 26. Logical replication
  58    allows fine-grained control over both data replication and security.
  59
  60    Logical replication uses a publish and subscribe model with one or more
  61    subscribers subscribing to one or more publications on a publisher
  62    node. Subscribers pull data from the publications they subscribe to and
  63    may subsequently re-publish data to allow cascading replication or more
  64    complex configurations.
  65
  66    When logical replication of a table typically starts, PostgreSQL takes
  67    a snapshot of the table's data on the publisher database and copies it
  68    to the subscriber. Once complete, changes on the publisher since the
  69    initial copy are sent continually to the subscriber. The subscriber
  70    applies the data in the same order as the publisher so that
  71    transactional consistency is guaranteed for publications within a
  72    single subscription. This method of data replication is sometimes
  73    referred to as transactional replication.
  74
  75    The typical use-cases for logical replication are:
  76      * Sending incremental changes in a single database or a subset of a
  77        database to subscribers as they occur.
  78      * Firing triggers for individual changes as they arrive on the
  79        subscriber.
  80      * Consolidating multiple databases into a single one (for example for
  81        analytical purposes).
  82      * Replicating between different major versions of PostgreSQL.
  83      * Replicating between PostgreSQL instances on different platforms
  84        (for example Linux to Windows)
  85      * Giving access to replicated data to different groups of users.
  86      * Sharing a subset of the database between multiple databases.
  87
  88    The subscriber database behaves in the same way as any other PostgreSQL
  89    instance and can be used as a publisher for other databases by defining
  90    its own publications. When the subscriber is treated as read-only by
  91    application, there will be no conflicts from a single subscription. On
  92    the other hand, if there are other writes done either by an application
  93    or by other subscribers to the same set of tables, conflicts can arise.