Aiven for PostgreSQL^® now recreates logical replication slots automatically

Failover pain

Your PostgreSQL® cluster’s primary node fails, a new primary replaces it as planned … but the connection to the replication slots is broken, and other systems can no longer read the data from the new primary. For example: if your PostgreSQL® is functioning as long-term storage with Apache Kafka® in the middle serving data in and out, then Kafka can’t read from the new primary without a new replication slot being set up.

It will take a while for you to create and connect to a new logical replication slot. You have two choices in the meantime: either you shut down access to PostgreSQL from elsewhere in the system to avoid new entries being written; or you resync the entire cluster afterwards to avoid entries being dropped.

And you need to do this for every single primary.

But at Aiven, this hassle is now a thing of the past. In December 2022 we rolled out a new feature that automatically recreates logical replication slots in the event of a failover or a controlled switchover for Aiven for PostgreSQL.

Logical replication slots

In PostgreSQL® you can set up a logical replication slot for any downstream subscribers of the server. Having a replication slot causes the subscriber to receive the changes in the data in a database.

The trouble with this setup is that if you rely on replication slots and your primary node goes down, you will end up with either gaps in the data or having to re-read huge chunks of the database.

This is because after a failover or a switchover, you need to recreate the slots and reconnect all the downstream subscribers. If this is done manually, the subscribers will in practice lose whatever is written into the database while the process is ongoing. You can mitigate this with a complete resync of the database, but that causes downtime for the users.

No more gaps or full resync

Aiven for PostgreSQL has now implemented automatic recreation of replication slots for PG clusters. Whenever the primary node of a multi-node cluster goes down, whether in an unplanned failover or a controlled switchover, Aiven automagically recreates the replication slots from the old primary server in the new primary server. For single-node clusters, the replication slots are recreated during a controlled switchover.

This is achieved by creating replication slots from the primary in the standby or a new node which will be promoted as a primary, and synchronizing their positions continually. When a failover or switchover occurs, the standby node already has the same replication slots, and the positions are up to date (up to the accuracy of 5 seconds).

The slots are recreated on a node before it gets promoted as primary and opens connections to replicas or other systems.

Applying automatic recreation of replication slots

Your Aiven for PostgreSQL database will benefit from this new feature the next time the servers are recycled during maintenance (we don’t touch nodes that are already running, to avoid any issues in our customers’ environments). So you’ll lose your replication slots in the next maintenance update for the last time, and then the automatic replication will start to work.

And of course, new services have this new feature from the get-go!

Wrapping up

Managing your Aiven for PostgreSQL cluster just got easier. When a new primary takes over after a switchover or failover, it already has the same replication slots as the old one, and other systems can seamlessly resume reading from it.

For more information about this new feature, see our documentation: Upgrade and failover procedures.

To get the latest news about Aiven and our services, plus a bit of extra around all things open source, subscribe to our monthly newsletter! Daily news about Aiven is available on our LinkedIn and Twitter feeds.

If you just want to find out about our service updates, follow our changelog.