Barman Model

[Mark Schloss]

Hello,

We are using barman models are part of our switchover process and have an issue with the replication slot that is created. Our scenario is as follows -

1. Primary cluster with one standby
2. Promote standby cluster and have old primary follow the new primary
3. Use barman config-switch to apply model to the barman server configuration (updating conninfo,streaming_conninfo and ssh_command)

After the switchover a barman check confirms barman is operational against the new primary cluster.

To switch back we reverse the steps above and execute barman config-switch with the --reset option to restore the original barman server settings.
Again barman check confirms barman is operational against the original primary cluster.

The issue we see is that the replication slot barman created in the new primary (the original standby cluster) is still present once it has reverted back to the standby role. This causes problems as WAL files accumulate in PGDATA/pg_wal of the standby server.

To resolve this issue we stop the standby cluster, remove the barman replication slot from PGDATA/pg_replslot, restart the standby and wait for a restartpoint to clear the WAL files from the standby. Is this the expected behaviour or have we missed a step?

Regards

Mark 

[Israel Barth]

Hello Mark,

> To resolve this issue we stop the standby cluster, remove the barman replication slot from PGDATA/pg_replslot, restart the standby and wait for a restartpoint to clear the WAL files from the standby. Is this the expected behaviour or have we missed a step?

That's the expected behavior in this case.

Based on your description, you are streaming WALs from the primary to the Barman server using a replication slot.
While Barman is able to create the replication slot in the node it's currently configured to stream WALs from, Barman is not a cluster-aware tool.
The models implementation allows you to integrate Barman with HA tools, but it doesn't do all the homework as Barman is aware of a single node at a given point in time.

So, as part of your automation you should have something like this:

1. Run barman config-switch to point the Barman configuration to the new primary.
2. Run pg_drop_replication_slot in the old primary to drop the slot which is no longer used. This is preferred over the approach you described because:
• It is executed against a running Postgres instance, so no need for restarts.
• The task is performed by Postgres in the way it expects to do that, so it is less error prone.

Best regards,
Israel.

[Mark Schloss]

Thanks Israel. I'll incorporate your suggestion into our process.

Regards

Mark