RabbitMQ partition handling: pause_minority vs autoheal vs ignore

When a RabbitMQ cluster splits across a network fault, the broker cannot keep every node writable without risking divergent state, and it cannot keep every node consistent without taking some nodes out of service. The cluster_partition_handling setting in rabbitmq.conf is where you decide, in advance, which one gives: availability, or data.

Most teams set this once during cluster setup and never test what it does. Then a real partition happens at 3 a.m. and they discover their choice the hard way: autoheal restarts nodes and drops non-replicated messages, pause_minority freezes nodes that might be serving most of your clients, and ignore lets both sides accept writes and silently discards one side’s state when the network heals. None of these is a bug. They are the documented behavior you opted into.

This guide covers the three classic strategies: what each one does during and after a partition, what it costs, how quorum queues change the picture, and how to test your choice before the network tests it for you.

What cluster_partition_handling actually controls

A network partition means cluster nodes can no longer reach each other over the Erlang distribution link (default port 25672). Detection is not instant: RabbitMQ relies on Erlang’s net_ticktime heartbeat (default 60 seconds). With default settings, ticks are exchanged every 15 seconds (net_ticktime/4) and a peer is declared down after four consecutive missed ticks, so detection takes roughly a minute. During that window you are partitioned but RabbitMQ has not noticed yet.

Once detected, each node records the event. You can see it via the Management API (GET /api/nodes, the partitions array on each node) or with rabbitmq-diagnostics cluster_status. What happens next is determined entirely by cluster_partition_handling:

# Check the configured partition handling mode
rabbitmqctl eval 'application:get_env(rabbit, cluster_partition_handling).'

The strategy governs two moments: what nodes do while the partition is ongoing (keep serving, or stop), and how the cluster reconciles when connectivity returns (who wins, and whose data survives).

One scoping note: the setting controls recovery of cluster metadata and node membership. Message data safety additionally depends on queue type. Quorum queues use Raft and will not accept writes without a majority, regardless of this setting. Classic queues have no such protection, which is where the real data-loss exposure lives.

The three strategies

flowchart TD
    P[Network partition detected] --> S{cluster_partition_handling}
    S -->|pause_minority| PM[Minority-side nodes pause
stop serving clients]
    S -->|autoheal| AH[Winning side picked:
most clients, then most nodes]
    S -->|ignore| IG[Both sides keep running
and accepting writes]
    PM --> PM2[On heal: paused nodes resume
data safe, availability lost during partition]
    AH --> AH2[Losing side restarts
non-replicated messages on it are lost]
    IG --> IG2[On heal: one side's state discarded
silent message loss]

pause_minority

While the partition is ongoing, each node checks whether it can still see a majority of cluster nodes. Nodes that cannot pause themselves and stop serving clients entirely. The majority side continues operating normally.

• Data safety: good. Only the majority side accepts work, so there is no divergent state to reconcile. On heal, paused nodes resume and rejoin.
• Availability cost: real. Every node on the minority side is fully out of service for the duration of the partition. If your clients are spread across both sides, those on the minority side are down, not degraded.
• The 2-node trap: in a 2-node cluster, a partition means neither node sees a majority, so both nodes pause. A single network blip takes the whole cluster offline. Do not use pause_minority with two nodes.
• Blind spots: pause_minority decides based on what a node can no longer see. Partitions caused by VM suspend/resume can produce asymmetric views where the suspended node never observes the rest of the cluster vanish, and the mechanism does not engage as expected.

Choose this when consistency matters more than availability and you run at least three nodes, so a majority exists after any single failure domain is lost.

autoheal

Both sides keep running during the partition. When connectivity returns, the cluster picks a winning partition: the side with the most connected clients, tie-broken by the most nodes, and beyond that chosen in an unspecified way. All nodes on the losing side restart and rejoin the winner’s state.

• Data safety: lossy by design. Any messages on the restarted nodes that were not replicated elsewhere are gone.
• Availability cost: the restart itself causes brief unavailability on losing-side nodes, and clients connected there get dropped. The restart is how autoheal resolves divergence, not a side effect you can avoid.
• Winner selection risk: “most clients” is not necessarily “the side with your important queues.” If a load balancer kept most clients pinned to what becomes the losing side, that side still loses. You do not control the winner; the connection count does.

Choose this when availability during the partition matters more than losing a bounded amount of non-replicated message data, and when your queues are quorum queues (which refuse minority writes anyway), so the residual exposure is small.

ignore

RabbitMQ does nothing. Both sides keep running and accepting writes for the entire partition. Classic queue state diverges: each side accumulates messages the other side does not know about. When the partition heals, the nodes rejoin and one side’s divergent state is discarded.

• Data safety: worst of the three. Writes accepted on the discarded side are lost silently. There is no error, no alarm, and no log message that itemizes what vanished. If both sides were accepting publishes into the same classic queue, one side’s messages simply cease to exist.
• Availability cost: none during the partition. That is the entire appeal.
• Manual reconciliation: healing is not automatic in any meaningful sense. The operator’s job is to notice the partition, stop publishers on one side to bound the divergence, and fix the network fault. If you are running ignore, the on-call engineer is the partition handling strategy.

Choose this only if you have a deliberate, tested manual recovery procedure and your queue types (quorum queues) already prevent divergent writes for the data you care about.

Summary table

How quorum queues change the equation

Everything above about divergent writes applies to classic queues. Quorum queues replicate via Raft and require a majority of members to commit. In a partition, the minority side’s quorum queues reject writes (queue state shows minority in the Management API), no matter which partition handling strategy you configured.

With quorum queues, ignore and autoheal lose most of their data-loss teeth for the queues that matter, and pause_minority becomes largely redundant for write safety, since Raft already refuses minority writes. The remaining question the strategy answers is node-level: do minority nodes keep serving consumers and non-replicated traffic, or not.

The practical recommendation: run quorum queues for anything you cannot afford to lose, then pick the partition strategy based on availability preference rather than data safety. If you are still running classic queues for important data, no partition handling strategy will save you; pause_minority is the least bad option.

What changed in RabbitMQ 4.3.0

RabbitMQ 4.3.0 (April 2026) removed Mnesia as a metadata store and with it the entire partition handling subsystem. Cluster metadata now lives in Khepri, which is Raft-based, so partition recovery follows Raft semantics: the majority side continues, the minority side cannot commit, and rejoining nodes catch up via log replication. There is no winning-partition election and no node restart on heal.

The cluster_partition_handling keys are still accepted in rabbitmq.conf for backwards compatibility but have no effect. If you are on 4.3.0 or later, this article’s strategy comparison describes the world you upgraded away from; remove the keys from your config when convenient. If you are on 3.x or 4.0 through 4.2.x with the default metadata store, everything above still applies. With Khepri as the metadata store (fully supported since 4.0, the default since 4.2.0), the partition handling strategies are likewise unused: they were a Mnesia-era mechanism.

Signals to watch in production

Two correlations matter most during a partition event. First, partitions non-empty plus zero cluster-link traffic between the same peers confirms a real network fault rather than a GC-induced false positive (a GC pause longer than the tick interval can trigger transient partition detection that self-heals, which is why you require the condition to persist before paging). Second, node uptime resets plus a connection churn spike tell you autoheal fired, which means you should go check what non-replicated data was on the restarted nodes.

Testing your choice before the network does

Teams set the strategy and never exercise it. A partition handling mode you have not tested is a guess. A minimal test plan:

• Document the current mode: run the application:get_env(rabbit, cluster_partition_handling) check on every node and record it. Confirm all nodes agree.
• Induce a partition in staging: block the Erlang distribution port (default 25672) between nodes with firewall rules. Do not just stop a node; a stopped node is a failure, not a partition.
• Wait past detection: detection is not immediate (see the net_ticktime discussion above). Observe what your monitoring reports during the window before RabbitMQ reacts.
• Publish during the partition: send test messages to nodes on both sides, tagged so you can tell which side accepted them. After healing, verify which messages survived. This is the step that makes ignore and autoheal data loss concrete instead of theoretical.
• Measure client behavior: watch what happens to connections on paused or restarted nodes, and how your clients’ reconnect logic treats the survivors. A partition test that only watches the broker misses half the incident.
• Write down the expected timeline: detection delay, strategy action, heal behavior, and the reconciliation steps an operator must perform. Put it in the runbook next to the partition alert.

Do this per strategy candidate, not just for the one currently configured. The point is to pick the tradeoff deliberately.

How Netdata helps

• Netdata collects per-node status from the RabbitMQ Management API, so a split cluster shows up as a cross-node signal, not as a set of per-node dashboards that each look green.
• Queue state is tracked per queue, so quorum queues dropping into minority are visible alongside the partition event on the same timeline.
• Node uptime is charted, making autoheal restarts obvious: an uptime reset on a subset of nodes immediately after a partition event tells you which side lost.
• Erlang run queue and scheduler pressure are collected per second, which helps you distinguish real partitions from GC- or CPU-induced heartbeat timeouts before you start a recovery procedure.
• Connection counts and churn rates on the same dashboard let you see the client impact of paused or restarted nodes and size the reconnect wave hitting the survivors.

Related guides

• RabbitMQ channel leak and churn: the channel-per-message anti-pattern
• RabbitMQ connection blocked / blocking: publishers frozen by a resource alarm
• RabbitMQ connection in flow state: credit-based backpressure explained
• RabbitMQ connection storm: reconnect loops, FD pressure, and CPU spent on handshakes
• RabbitMQ consumer timeout: delivery acknowledgement timed out and the channel is closed
• RabbitMQ consumer_utilisation low: consumers attached but not keeping up
• RabbitMQ consumers connected but not acknowledging: the consumer black hole
• RabbitMQ disk free limit alarm: free disk space insufficient and publishing halted
• RabbitMQ disk_free_limit at the default 50MB: the production footgun
• RabbitMQ file descriptor exhaustion: fd_used near fd_total and refused connections
• RabbitMQ flow control vs resource alarms: the two throttling mechanisms operators confuse
• RabbitMQ head message age: the queue latency that depth alone cannot show