New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support HA for logical replication slots #1962
Comments
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
sjuls
added a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 3, 2023
…pg#1962) Signed-off-by: Jakob Schultz-Falk <sjulsbe@gmail.com>
mnencia
pushed a commit
to sjuls/cloudnative-pg
that referenced
this issue
May 16, 2023
…pg#1962) Signed-off-by: Jakob Schultz-Falk <sjulsbe@gmail.com>
Hello, what's the status of this? |
Also looking forward to this for Debezium support |
Is any community contribution needed to move this forward? |
any update? |
Looks like this is not an issue anymore sine the pg_failover_slots extension is the solution: |
@ozen I agree, closing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently CloudNativePG supports HA replication slots for physical replication slots, but ignores logical replication slots. To better support connectors such as debezium which require the replication slot to be available upon connection, it would make sense to extend the current behaviour to also synchronize logical replication slot from the primary to the standby's and advance the LSN in the configured interval.
This would also protect against excessive WAL piling up on a standby risking running out of disk, since the consumer will likely consumer from the primary instance.
Similar comments have been made to issue 13, though the issue seems to have an overall different goal, hence the separate issue I am creating here.
The text was updated successfully, but these errors were encountered: