begriffs open source - ai-pg/blob - full-docs/src/sgml/html/logical-replication-architecture.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>29.9. Architecture</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="logical-replication-restrictions.html" title="29.8. Restrictions" /><link rel="next" href="logical-replication-monitoring.html" title="29.10. Monitoring" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">29.9. Architecture</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="logical-replication-restrictions.html" title="29.8. Restrictions">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="logical-replication.html" title="Chapter 29. Logical Replication">Up</a></td><th width="60%" align="center">Chapter 29. Logical Replication</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="logical-replication-monitoring.html" title="29.10. Monitoring">Next</a></td></tr></table><hr /></div><div class="sect1" id="LOGICAL-REPLICATION-ARCHITECTURE"><div class="titlepage"><div><div><h2 class="title" style="clear: both">29.9. Architecture <a href="#LOGICAL-REPLICATION-ARCHITECTURE" class="id_link">#</a></h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="logical-replication-architecture.html#LOGICAL-REPLICATION-SNAPSHOT">29.9.1. Initial Snapshot</a></span></dt></dl></div><p>
   3    Logical replication is built with an architecture similar to physical
   4    streaming replication (see <a class="xref" href="warm-standby.html#STREAMING-REPLICATION" title="26.2.5. Streaming Replication">Section 26.2.5</a>).  It is
   5    implemented by <code class="literal">walsender</code> and <code class="literal">apply</code>
   6    processes.  The walsender process starts logical decoding (described
   7    in <a class="xref" href="logicaldecoding.html" title="Chapter 47. Logical Decoding">Chapter 47</a>) of the WAL and loads the standard
   8    logical decoding output plugin (<code class="literal">pgoutput</code>).  The plugin
   9    transforms the changes read
  10    from WAL to the logical replication protocol
  11    (see <a class="xref" href="protocol-logical-replication.html" title="54.5. Logical Streaming Replication Protocol">Section 54.5</a>) and filters the data
  12    according to the publication specification.  The data is then continuously
  13    transferred using the streaming replication protocol to the apply worker,
  14    which maps the data to local tables and applies the individual changes as
  15    they are received, in correct transactional order.
  16   </p><p>
  17    The apply process on the subscriber database always runs with
  18    <a class="link" href="runtime-config-client.html#GUC-SESSION-REPLICATION-ROLE"><code class="varname">session_replication_role</code></a>
  19    set to <code class="literal">replica</code>. This means that, by default,
  20    triggers and rules will not fire on a subscriber. Users can optionally choose to
  21    enable triggers and rules on a table using the
  22    <a class="link" href="sql-altertable.html" title="ALTER TABLE"><code class="command">ALTER TABLE</code></a> command
  23    and the <code class="literal">ENABLE TRIGGER</code> and <code class="literal">ENABLE RULE</code>
  24    clauses.
  25   </p><p>
  26    The logical replication apply process currently only fires row triggers,
  27    not statement triggers.  The initial table synchronization, however, is
  28    implemented like a <code class="command">COPY</code> command and thus fires both row
  29    and statement triggers for <code class="command">INSERT</code>.
  30   </p><div class="sect2" id="LOGICAL-REPLICATION-SNAPSHOT"><div class="titlepage"><div><div><h3 class="title">29.9.1. Initial Snapshot <a href="#LOGICAL-REPLICATION-SNAPSHOT" class="id_link">#</a></h3></div></div></div><p>
  31      The initial data in existing subscribed tables are snapshotted and
  32      copied in parallel instances of a special kind of apply process.
  33      These special apply processes are dedicated table synchronization
  34      workers, spawned for each table to be synchronized.  Each table
  35      synchronization process will create its own replication slot and
  36      copy the existing data.  As soon as the copy is finished the table
  37      contents will become visible to other backends.  Once existing data
  38      is copied, the worker enters synchronization mode, which ensures
  39      that the table is brought up to a synchronized state with the main
  40      apply process by streaming any changes that happened during the
  41      initial data copy using standard logical replication.  During this
  42      synchronization phase, the changes are applied and committed in the same
  43      order as they happened on the publisher.  Once synchronization is done,
  44      control of the replication of the table is given back to the main apply
  45      process where replication continues as normal.
  46     </p><div class="note"><h3 class="title">Note</h3><p>
  47       The publication
  48       <a class="link" href="sql-createpublication.html#SQL-CREATEPUBLICATION-PARAMS-WITH-PUBLISH"><code class="literal">publish</code></a>
  49       parameter only affects what DML operations will be replicated. The
  50       initial data synchronization does not take this parameter into account
  51       when copying the existing table data.
  52      </p></div><div class="note"><h3 class="title">Note</h3><p>
  53       If a table synchronization worker fails during copy, the apply worker
  54       detects the failure and respawns the table synchronization worker to
  55       continue the synchronization process. This behaviour ensures that
  56       transient errors do not permanently disrupt the replication setup. See
  57       also <a class="link" href="runtime-config-replication.html#GUC-WAL-RETRIEVE-RETRY-INTERVAL"><code class="varname">wal_retrieve_retry_interval</code></a>.
  58      </p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="logical-replication-restrictions.html" title="29.8. Restrictions">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="logical-replication.html" title="Chapter 29. Logical Replication">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="logical-replication-monitoring.html" title="29.10. Monitoring">Next</a></td></tr><tr><td width="40%" align="left" valign="top">29.8. Restrictions </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 18.0 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 29.10. Monitoring</td></tr></table></div></body></html>