database/postgres
database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-04-29 13:56:47 +03:00
Code

doc: Add info about replication slot management

Browse Source 
Add some more information about managing replication slots associated
with logical replication subscriptions.
This commit is contained in:
Peter Eisentraut 2017-05-09 10:25:26 -04:00
parent 013c1178fd
commit ab178bb2f4
1 changed files with 60 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
doc/src/sgml/logical-replication.sgml
View File

@ -204,6 +204,66 @@
target table can have additional columns not provided by the published
table. Those will be filled with their default values.
</para>
<sect2 id="logical-replication-subscription-slot">
<title>Replication Slot Management</title>
<para>
As mentioned earlier, each (active) subscription receives changes from a
replication slot on the remote (publishing) side. Normally, the remote
replication slot is created automatically when the subscription is created
using <command>CREATE SUBSCRIPTION</command> and it is dropped
automatically when the subscription is dropped using <command>DROP
SUBSCRIPTION</command>. In some situations, however, it can be useful or
necessary to manipulate the subscription and the underlying replication
slot separately. Here are some scenarios:
<itemizedlist>
<listitem>
<para>
When creating a subscription, the replication slot already exists. In
that case, the subscription can be created using the <literal>NOCREATE
SLOT</literal> option to associate with the existing slot.
</para>
</listitem>
<listitem>
<para>
When creating a subscription, the remote host is not reachable or in an
unclear state. In that case, the subscription can be created using
the <literal>NOCONNECT</literal> option. The remote host will then not
be contacted at all. This is what <application>pg_dump</application>
uses. The remote replication slot will then have to be created
manually before the subscription can be activated.
</para>
</listitem>
<listitem>
<para>
When dropping a subscription, the replication slot should be kept.
This could be useful when the subscriber database is being moved to a
different host and will be activated from there. In that case,
disassociate the slot from the subscription using <command>ALTER
SUBSCRIPTION</command> before attempting to drop the subscription.
</para>
</listitem>
<listitem>
<para>
When dropping a subscription, the remote host is not reachable. In
that case, disassociate the slot from the subscription
using <command>ALTER SUBSCRIPTION</command> before attempting to drop
the subscription. If the remote database instance no longer exists, no
further action is then necessary. If, however, the remote database
instance is just unreachable, the replication slot should then be
dropped manually; otherwise it would continue to reserve WAL and might
eventually cause the disk to fill up. Such cases should be carefully
investigated.
</para>
</listitem>
</itemizedlist>
</para>
</sect2>
</sect1>
<sect1 id="logical-replication-conflicts">