DBZ-4603 Remove parameters from config example and link to PG doc
Co-authored-by: Gunnar Morling <gunnar.morling@googlemail.com>
This commit is contained in:
parent
d21e37746a
commit
491c8cec83
@ -2086,12 +2086,12 @@ shared_preload_libraries = 'decoderbufs' // <1>
|
||||
----
|
||||
# REPLICATION
|
||||
wal_level = logical // <1>
|
||||
max_wal_senders = 1 // <2>
|
||||
max_replication_slots = 1 // <3>
|
||||
----
|
||||
<1> instructs the server to use logical decoding with the write-ahead log.
|
||||
<2> instructs the server to use a maximum of `1` separate process for processing WAL changes.
|
||||
<3> instructs the server to allow a maximum of `1` replication slot to be created for streaming WAL changes.
|
||||
<1> Instructs the server to use logical decoding with the write-ahead log.
|
||||
|
||||
Depending on your requirements, you may have to set other PostgreSQL streaming replication parameters when using {prodname}.
|
||||
Examples include `max_wal_senders` and `max_replication_slots` for increasing the number of connectors that can access the sending server concurrently, and `wal_keep_size` for limiting the maximum WAL size which a replication slot will retain.
|
||||
For more information about configuring streaming replication, see the link:https://www.postgresql.org/docs/current/runtime-config-replication.html#RUNTIME-CONFIG-REPLICATION-SENDER[PostgreSQL documentation].
|
||||
|
||||
{prodname} uses PostgreSQL's logical decoding, which uses replication slots.
|
||||
Replication slots are guaranteed to retain all WAL segments required for {prodname} even during {prodname} outages. For this reason, it is important to closely monitor replication slots to avoid too much disk consumption and other conditions that can happen such as catalog bloat if a replication slot stays unused for too long.
|
||||
|
Loading…
Reference in New Issue
Block a user