summaryrefslogtreecommitdiffstats
path: root/doc/src/sgml/html/logical-replication.html
blob: 7cf69c4353e0fbd2e332aae515c9a7f16bbb5cbb (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
<?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>Chapter 31. Logical Replication</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="wal-internals.html" title="30.6. WAL Internals" /><link rel="next" href="logical-replication-publication.html" title="31.1. Publication" /></head><body id="docContent" class="container-fluid col-10"><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">Chapter 31. Logical Replication</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="wal-internals.html" title="30.6. WAL Internals">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="admin.html" title="Part III. Server Administration">Up</a></td><th width="60%" align="center">Part III. Server Administration</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 14.5 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="logical-replication-publication.html" title="31.1. Publication">Next</a></td></tr></table><hr></hr></div><div class="chapter" id="LOGICAL-REPLICATION"><div class="titlepage"><div><div><h2 class="title">Chapter 31. Logical Replication</h2></div></div></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="logical-replication-publication.html">31.1. Publication</a></span></dt><dt><span class="sect1"><a href="logical-replication-subscription.html">31.2. Subscription</a></span></dt><dd><dl><dt><span class="sect2"><a href="logical-replication-subscription.html#LOGICAL-REPLICATION-SUBSCRIPTION-SLOT">31.2.1. Replication Slot Management</a></span></dt></dl></dd><dt><span class="sect1"><a href="logical-replication-conflicts.html">31.3. Conflicts</a></span></dt><dt><span class="sect1"><a href="logical-replication-restrictions.html">31.4. Restrictions</a></span></dt><dt><span class="sect1"><a href="logical-replication-architecture.html">31.5. Architecture</a></span></dt><dd><dl><dt><span class="sect2"><a href="logical-replication-architecture.html#LOGICAL-REPLICATION-SNAPSHOT">31.5.1. Initial Snapshot</a></span></dt></dl></dd><dt><span class="sect1"><a href="logical-replication-monitoring.html">31.6. Monitoring</a></span></dt><dt><span class="sect1"><a href="logical-replication-security.html">31.7. Security</a></span></dt><dt><span class="sect1"><a href="logical-replication-config.html">31.8. Configuration Settings</a></span></dt><dt><span class="sect1"><a href="logical-replication-quick-setup.html">31.9. Quick Setup</a></span></dt></dl></div><p>
  Logical replication is a method of replicating data objects and their
  changes, based upon their replication identity (usually a primary key).  We
  use the term logical in contrast to physical replication, which uses exact
  block addresses and byte-by-byte replication.  PostgreSQL supports both
  mechanisms concurrently, see <a class="xref" href="high-availability.html" title="Chapter 27. High Availability, Load Balancing, and Replication">Chapter 27</a>.  Logical
  replication allows fine-grained control over both data replication and
  security.
 </p><p>
  Logical replication uses a <em class="firstterm">publish</em>
  and <em class="firstterm">subscribe</em> model with one or
  more <em class="firstterm">subscribers</em> subscribing to one or more
  <em class="firstterm">publications</em> on a <em class="firstterm">publisher</em>
  node.  Subscribers pull data from the publications they subscribe to and may
  subsequently re-publish data to allow cascading replication or more complex
  configurations.
 </p><p>
  Logical replication of a table typically starts with taking a snapshot
  of the data on the publisher database and copying that to the subscriber.
  Once that is done, the changes on the publisher are sent 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
  is sometimes referred to as transactional replication.
 </p><p>
  The typical use-cases for logical replication are:

  </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
     Sending incremental changes in a single database or a subset of a
     database to subscribers as they occur.
    </p></li><li class="listitem"><p>
     Firing triggers for individual changes as they arrive on the
     subscriber.
    </p></li><li class="listitem"><p>
     Consolidating multiple databases into a single one (for example for
     analytical purposes).
    </p></li><li class="listitem"><p>
     Replicating between different major versions of PostgreSQL.
    </p></li><li class="listitem"><p>
     Replicating between PostgreSQL instances on different platforms (for
     example Linux to Windows)
    </p></li><li class="listitem"><p>
     Giving access to replicated data to different groups of users.
    </p></li><li class="listitem"><p>
     Sharing a subset of the database between multiple databases.
    </p></li></ul></div><p>
 </p><p>
  The subscriber database behaves in the same way as any other PostgreSQL
  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 an application or by other
  subscribers to the same set of tables, conflicts can arise.
 </p></div><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navfooter"><hr></hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="wal-internals.html" title="30.6. WAL Internals">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="admin.html" title="Part III. Server Administration">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="logical-replication-publication.html" title="31.1. Publication">Next</a></td></tr><tr><td width="40%" align="left" valign="top">30.6. WAL Internals </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 14.5 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 31.1. Publication</td></tr></table></div></body></html>