summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/html/logical-replication-architecture.html
blob: 02d7aa62d81bb79a27b82eaa8ee6804fd4e1b761 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!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>31.7. 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="31.6. Restrictions" /><link rel="next" href="logical-replication-monitoring.html" title="31.8. 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">31.7. Architecture</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="logical-replication-restrictions.html" title="31.6. Restrictions">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="logical-replication.html" title="Chapter 31. Logical Replication">Up</a></td><th width="60%" align="center">Chapter 31. Logical Replication</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="logical-replication-monitoring.html" title="31.8. 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">31.7. 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">31.7.1. Initial Snapshot</a></span></dt></dl></div><p>
   Logical replication starts by copying a snapshot of the data on the
   publisher database.  Once that is done, changes on the publisher are sent
   to the subscriber as they occur in real time.  The subscriber applies data
   in the order in which commits were made on the publisher so that
   transactional consistency is guaranteed for the publications within any
   single subscription.
  </p><p>
   Logical replication is built with an architecture similar to physical
   streaming replication (see <a class="xref" href="warm-standby.html#STREAMING-REPLICATION" title="27.2.5. Streaming Replication">Section 27.2.5</a>).  It is
   implemented by <code class="literal">walsender</code> and <code class="literal">apply</code>
   processes.  The walsender process starts logical decoding (described
   in <a class="xref" href="logicaldecoding.html" title="Chapter 49. Logical Decoding">Chapter 49</a>) of the WAL and loads the standard
   logical decoding output plugin (<code class="literal">pgoutput</code>).  The plugin
   transforms the changes read
   from WAL to the logical replication protocol
   (see <a class="xref" href="protocol-logical-replication.html" title="55.5. Logical Streaming Replication Protocol">Section 55.5</a>) and filters the data
   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 correct transactional order.
  </p><p>
   The apply process on the subscriber database always runs with
   <a class="link" href="runtime-config-client.html#GUC-SESSION-REPLICATION-ROLE"><code class="varname">session_replication_role</code></a>
   set to <code class="literal">replica</code>. This means that, by default,
   triggers and rules will not fire on a subscriber. Users can optionally choose to
   enable triggers and rules on a table using the
   <a class="link" href="sql-altertable.html" title="ALTER TABLE"><code class="command">ALTER TABLE</code></a> command
   and the <code class="literal">ENABLE TRIGGER</code> and <code class="literal">ENABLE RULE</code>
   clauses.
  </p><p>
   The logical replication apply process currently only fires row triggers,
   not statement triggers.  The initial table synchronization, however, is
   implemented like a <code class="command">COPY</code> command and thus fires both row
   and statement triggers for <code class="command">INSERT</code>.
  </p><div class="sect2" id="LOGICAL-REPLICATION-SNAPSHOT"><div class="titlepage"><div><div><h3 class="title">31.7.1. Initial Snapshot <a href="#LOGICAL-REPLICATION-SNAPSHOT" class="id_link">#</a></h3></div></div></div><p>
     The initial data in existing subscribed tables are snapshotted and
     copied in a parallel instance of a special kind of apply process.
     This process will create its own replication slot and copy the existing
     data.  As soon as the copy is finished the table contents will become
     visible to other backends.  Once existing data is copied, the worker
     enters synchronization mode, which ensures that the table is brought
     up to a synchronized state with the main apply process by streaming
     any changes that happened during the initial data copy using standard
     logical replication.  During this synchronization phase, the changes
     are applied and committed in the same order as they happened on the
     publisher.  Once synchronization is done, control of the
     replication of the table is given back to the main apply process where
     replication continues as normal.
    </p><div class="note"><h3 class="title">Note</h3><p>
      The publication
      <a class="link" href="sql-createpublication.html#SQL-CREATEPUBLICATION-WITH-PUBLISH"><code class="literal">publish</code></a>
      parameter only affects what DML operations will be replicated. The
      initial data synchronization does not take this parameter into account
      when copying the existing table data.
     </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="31.6. Restrictions">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="logical-replication.html" title="Chapter 31. Logical Replication">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="logical-replication-monitoring.html" title="31.8. Monitoring">Next</a></td></tr><tr><td width="40%" align="left" valign="top">31.6. Restrictions </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 16.2 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 31.8. Monitoring</td></tr></table></div></body></html>