You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: cluster-managed replication slots for High Availability (cloudnative-pg#740)
Introduce the concept of cluster-managed replication slots, starting with
high availability clusters. This feature automatically manages physical
replication slots for each hot standby replica in the High Availability
cluster, both in the primary and the standby.
We are introducing these two terms:
- "Primary HA slot": a physical replication slot whose lifecycle is entirely
managed by the current primary of the cluster and whose purpose is to map to
a specific standby in streaming replication. Such a slot lives on the primary
only.
- "Standby HA slot": a physical replication slot for a standby whose lifecycle is
entirely managed by another standby in the cluster, based on the content of
the `pg_replication_slots` view in the primary, and updated at regular
intervals using `pg_replication_slot_advance()`.
This feature is controlled through the following options:
- `.spec.replicationSlots.highAvailability.enabled`: if true, the feature is
enabled (`false` is the default)
- `.spec.replicationSlots.highAvailability.slotPrefix`: the prefix that
identifies replication slots managed by the operator for this feature
(default: `_cnpg_`)
- `.spec.replicationSlots.updateInterval`: how often the standby synchronizes
the position of the local copy of the replication slots with the position on
the current primary, expressed in seconds (default: 30)
IMPORTANT: this capability requires PostgreSQL 11 or higher, as it relies on
the `pg_replication_slot_advance()` administration function to directly
manipulate the position of a replication slot. In PostgreSQL 11, enabling
replication slots if initially disabled, or conversely disabling them if
initially enabled, will require a rolling update of the cluster (due to the
presence of the `recovery.conf` file that is only read at startup).
Closescloudnative-pg#8
ABOUT REPLICATION SLOTS IN POSTGRESQL: replication slots are a native
PostgreSQL feature introduced in 9.4 that provides an automated way to ensure
that the primary does not remove WAL segments until all the attached streaming
replication clients have received them, and that the primary does not remove
rows which could cause a recovery conflict even when the standby is
(temporarily) disconnected. A replication slot exists solely on the instance
that created it, and PostgreSQL does not replicate it on the standby servers.
As a result, after a failover or a switchover, the new primary does not contain
the replication slot from the old primary. This can create problems for the
streaming replication clients that were connected to the old primary and have
lost their slot. More information at:
https://www.postgresql.org/docs/current/warm-standby.html#STREAMING-REPLICATION-SLOTS
Signed-off-by: Marco Nenciarini <marco.nenciarini@enterprisedb.com>
Signed-off-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Signed-off-by: Jitendra Wadle <jitendra.wadle@enterprisedb.com>
Signed-off-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
Signed-off-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Signed-off-by: Jaime Silvela <jaime.silvela@enterprisedb.com>
Signed-off-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Signed-off-by: Tao Li <tao.li@enterprisedb.com>
Signed-off-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Signed-off-by: Philippe Scorsolini <philippe.scorsolini@enterprisedb.com>
Co-authored-by: Niccolò Fei <niccolo.fei@enterprisedb.com>
Co-authored-by: Jitendra Wadle <jitendra.wadle@enterprisedb.com>
Co-authored-by: Jonathan Gonzalez V <jonathan.gonzalez@enterprisedb.com>
Co-authored-by: Jaime Silvela <jaime.silvela@enterprisedb.com>
Co-authored-by: Armando Ruocco <armando.ruocco@enterprisedb.com>
Co-authored-by: Gabriele Bartolini <gabriele.bartolini@enterprisedb.com>
Co-authored-by: Tao Li <tao.li@enterprisedb.com>
Co-authored-by: Leonardo Cecchi <leonardo.cecchi@enterprisedb.com>
Co-authored-by: Philippe Scorsolini <philippe.scorsolini@enterprisedb.com>
0 commit comments