-
Notifications
You must be signed in to change notification settings - Fork 198
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
Barman - check server returns wrong results for Replication Slot #1024
Comments
Can't really say why you are getting that error based on the little information here. It's not clear what backup method you are using, although it looks like it's rsync based on the ssh_command, and we are not sure the role of each of the two nodes live-db and backup-db. I suggest looking at the output from |
I will prepare that, once our backup is done and I can revert my local changes. Yes it's using rsync, from standby db. live-db is the primary, which is active, and is really remote (ping 20-30ms) I dug a bit into the outputs generated from fetch_remote_status and it is never connecting to the primary_conninfo and only uses the conninfo to extract the barman check results, there it can't find the replication_slot, since it doesn't exist. |
Which version did you upgrade to? |
|
|
As you see in the barman diagnose the replication_slot is reported as none. but if I do:
|
I was able to reproduce it locally. We'll do some investigation and come back |
@martinmarques Have you had any progress with that? Do you know another workaround than editing the postgres.py file? I might not have been clear on the impact, the bug breaks the backup functionality and no backups can be started! |
This will be fixed in the next release |
The fix for this issue was released yesterday |
Thanks, will try! |
Hi,
I have a configuration that sets the following variables:
The issue is that the check server always return that the replication slot is not created, even though receive-wal (started through barman cron) is active:
I also have verified the replication slot on the main db, and it's active and working with exactly the same name.
I tracked it down I think to the change of primary_conninfo (I upgraded from 2.11). I changed a bit in postgres.py:~1709
and also added the function:
This allows the check to finish successfully. Can someone take a more detailed look?
The text was updated successfully, but these errors were encountered: