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:
roldanbob 2022-02-21 06:22:56 -05:00 committed by GitHub
parent d21e37746a
commit 491c8cec83
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -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.