barman icon indicating copy to clipboard operation
barman copied to clipboard

How to backup after switchover is performed without any manual changes in configuration file?

Open r-chauhan16 opened this issue 2 years ago • 2 comments

Hi

After the switchover to standby via repmgr. BARMAN complains about the below error. How do I overcome this?? Ideally as per the enhancement, after switchover when conninfo is pointing to primary, it should ignore primary_conninfo parameter.

It was working fine with version 3.2.0.

BARMAN version 3.3 Error: PostgreSQL server is standby: FAILED (conninfo should point to a standby server if primary_conninfo is set) Primary server is not a standby: FAILED (primary_conninfo should point to a primary server, not a standby) Primary and standby have same system ID: OK

Barman configuration [ams] description = "ams server config" ssh_command = ssh postgres@host1 -q conninfo = host=host2 user=barman port=5438 dbname=plw_ams password=***** backup_options = concurrent_backup backup_method = postgres #archiver = on

streaming_archiver = on slot_name = barman create_slot = auto streaming_conninfo = host=host1 user=streamuser port=5438 dbname=plw_ams password=****** path_prefix=/usr/pgsql-14/bin primary_conninfo = host=host1 user=barman port=5438 dbname=plw_ams password=****

r-chauhan16 avatar Feb 01 '23 17:02 r-chauhan16

Hi - unfortunately until #704 (or something similar which solves the same problem) is implemented it will be necessary to update the Barman configuration following a failover so that conninfo points to a standby and primary_conninfo points to the new primary.

As a workaround you could leave primary_conninfo unset - if you do this then Barman will wait for a WAL switch to occur on the primary rather than triggering one itself. As long as the workload is busy enough so that WAL switches occur naturally then backups will still complete.

Note: The check logic did not change between 3.2.0 and 3.3.0, however a bug involving the re-use of a PostgreSQL connection was fixed - it is possible that the reason this appeared to work in 3.2.0 was a side-effect of that connection re-use.

mikewallace1979 avatar Feb 02 '23 13:02 mikewallace1979