[docs] Note about replication in managed cloud providers
I've added a note saying that some managed offerings actually replicate the replication slot. I found this information very critical when evaluating reliability of Debezium. I'll look for links in the docs tomorrow. [Patroni](https://patroni.readthedocs.io/en/latest/) also seems to support this feature.
This commit is contained in:
parent
196d24f2be
commit
9f811a6f64
@ -153,6 +153,7 @@ Grzegorz Kołakowski
|
||||
Jacob Gminder
|
||||
Jan Doms
|
||||
Jan Hendrik Dolling
|
||||
Jannik Steinmann
|
||||
Jason Schweier
|
||||
Jiabao Sun
|
||||
Juan Fiallo
|
||||
|
@ -3280,6 +3280,11 @@ As of release 12, PostgreSQL allows logical replication slots _only on primary s
|
||||
Also, replication slots themselves are not propagated to replicas.
|
||||
If the primary server goes down, a new primary must be promoted.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
Some managed PostgresSQL services (AWS RDS and GCP CloudSQL for example) implement replication to a standby via disk replication. This means that the replication slot does get replicated and will remain available after a failover.
|
||||
====
|
||||
|
||||
ifdef::community[]
|
||||
The new primary must have the xref:{link-postgresql-connector}#installing-postgresql-output-plugin[logical decoding plug-in] installed and a replication slot that is configured for use by the plug-in and the database for which you want to capture changes. Only then can you point the connector to the new server and restart the connector.
|
||||
endif::community[]
|
||||
|
Loading…
Reference in New Issue
Block a user