From Mnesia to Khepri

Why does this plugin exist?

With Khepri, minority nodes continue running during a network partition but the underlying Raft protocol prevents any diverging changes to happen thus protecting the data integrity. Existing connections stay open, and in certain cases – for example, with exclusive Classic Queues where both the publisher and consumer are connected to the same minority node – applications can still send and receive messages. All quorum queues on the other hand will stop processing messages and depend on the clients to time out any outstanding requests and reconnect to another – hopefully – working node.

Some users may not want this behaviour. They prefer the old approach from Mnesia’s pause minority mode, where minority nodes are stopped entirely, forcing applications to reconnect to a node in the majority group.

The Seventh State PauseR plugin exists to bring that option back.

Operation during partitions	Default Khepri (no plugin)	With PauseR Plugin
Existing client connections	Stay open	Closed
New client connections	Accepted	Blocked
Load balancer health checks	Load balancer considers the node healthy	Load balancer takes the node out of the active pool
Publish/consume on pre-declared Classic Queues (local producer & consumer)	Possible	Not possible
Declare new queues (any type)	Rejected	Rejected

How it works

Once enabled, the plugin starts automatically with the RabbitMQ cluster. It regularly checks the cluster state.

Every check interval (default: 5 seconds, configurable via seven_pauser.check_interval), the plugin determines whether the local node is part of the minority group during a partition.

If the node is in the minority, the plugin suspends all protocol listeners, closes existing connections, and blocks any new ones. This prevents applications from sending or receiving messages on the minority node. Management listeners such as the HTTP API and Management UI remain available for monitoring and administration.

When the node rejoins the majority, the plugin enables protocol listeners again and allows new client connections as normal.

This behaviour mimics Mnesia’s old pause minority mode in terms of isolating minority nodes, but instead of stopping the node entirely, it keeps the node running and only performs the necessary actions – closing existing AMQP connections and preventing new ones. This way the recovery can be much quicker than with the original pause minority handling which needed the node to start up and reinitialise all queues.

Default Khepri behaviour

By default, RabbitMQ with Khepri does not “pause” minority nodes the way Mnesia once did. Instead, a node in the minority partition continues running, but with some important nuances.

• Any existing client connections stay alive.
• The node will still accept new connections.
• Applications can even continue to publish and consume locally on pre-declared Classic Queues, as long as both the producer or consumer are on the same node.
• However, attempts to declare new queues of any type will be rejected.

This behaviour is normally safe: Raft ensures that data remains consistent across the cluster, even if some nodes temporarily operate in isolation. The difference is that minority nodes are not stopped outright – they keep running but with restrictions that prevent data inconsistency.

This can be useful if the partition is short-lived (e.g. a couple of seconds) and the network quickly restores, because applications can continue operating locally without disruption.

However, in longer partitions the experience can be less predictable. Minority nodes may appear alive, but they cannot actually function. Messaging operations such as publishing and consuming may not work at all, which means applications often end up waiting for timeouts before failing over. In worse cases, clients may keep retrying the same minority node over and over.

For teams that prefer a stricter and more immediate response – taking minority nodes out of service right away instead of letting them linger in this unusable state – the plugin provides a better option.

In summary

Khepri uses the Raft consensus algorithm, which ensures data consistency and handles network partitions safely without stopping any nodes. For environments that use Quorum Queues – also built on Raft – the same level of safety and resilience applies. Data consistency is maintained by design.

This plugin brings back the pause minority behaviour for RabbitMQ clusters running with Khepri. If your use case calls for taking minority nodes out of service during a partition, this plugin gives you that option.