Quorum Queues Replace Mirrored Queues in RabbitMQ: What Changes for Durability

Production queues that survive a network partition without losing messages is the real problem. With classic mirrored queues, a split-brain could acknowledge a write on a minority of nodes and later lose it. RabbitMQ’s answer is quorum queues, which use Raft consensus to make durability explicit.

The takeaway: a quorum queue only acknowledges a publish after a majority of replicas have fsynced the entry to disk. That changes failure semantics, latency, and operations.

Why mirrored queues were retired

Classic mirrored queues replicated messages asynchronously to slaves. A write could be acknowledged by the master before slaves persisted it, and during a partition the cluster could elect a new master on the minority side. Messages accepted there could be lost when the partition healed.

Quorum queues are the default and recommended replicated type since RabbitMQ 3.9, GA in 3.10. Classic mirrored queues are deprecated and removed in 4.0. Quorum queues support all AMQP 0.9.1 features except transient/exclusive queues and per-message TTL. Queue-level TTL works.

How Raft replication works in practice

Each quorum queue is a Raft group implemented via the Ra library. A queue has an odd number of replicas, typically 3 or 5. One replica is leader, the rest are followers.

A publish is appended to the Raft log on the leader, replicated to followers, and committed only when a majority N/2+1 have persisted it to disk. The broker then sends a publisher confirm. This majority rule prevents split-brain and gives predictable durability during partitions.

Data is stored in per-queue segment files, not the shared msg_store. That isolates disk usage per queue and makes recovery more granular. The broker tracks message positions in the Raft log for efficient redelivery after restarts.

Operational knobs matter. Use queue-master-locator=min-masters to spread leadership and avoid hot nodes. Monitor rabbitmq_queue_quorum_status and rabbitmq_quorum_queue_storage_bytes for leader, follower sync status and growth.

Configuration trade-offs: latency vs durability

Write latency rises because each replica fsyncs. The cost is higher than classic queues and higher than mirrored queues, but tail latency is more predictable. Throughput scales with quorum size, but so does disk I/O.

Disk I/O is critical. Each replica fsyncs on every write. Slow disks increase commit time and can trigger leader elections and throughput collapse. SSDs and low-latency storage are expected for production quorum queues.

A minimum of 3 nodes is required for fault tolerance. A 2-node cluster cannot maintain a majority if one node fails. Queue deletion is synchronous via Raft; deleting large queues can briefly pause the cluster.

Worked example: durable quorum queue with at-least-once delivery

Version check first. Run on any node as an OS user with rabbitmqctl permissions:

rabbitmqctl status | grep 'RabbitMQ'

Expect a version >= 3.9.0 for GA quorum queues.

Declare a durable quorum queue. Using rabbitmqadmin:

rabbitmqadmin declare queue name=my.orders durable=true arguments='{"x-queue-type":"quorum"}'

Verify type:

rabbitmqctl list_queues name type master_node synchronised_slave_nodes

Look for type quorum and a non-empty synchronised_slave_nodes list for the leader.

Publisher side: enable publisher confirms on the channel, e.g., channel.confirmSelect() in the Java client. Publish messages with a persistent delivery mode. A confirm is sent only after majority commit.

Consumer side: use manual acknowledgements. Acknowledge only after successful processing. On failure, nack with requeue=true to let the leader redeliver from the Raft log.

This pattern gives at-least-once delivery across broker restarts and partitions as long as a majority of replicas remains available. Exactly-once still requires consumer-side idempotency keys; deduplication is not built-in.

Limitations to plan for

As of 3.13, quorum queues do not support per-message TTL or priority queues. They cannot be used with exclusive or transient queues. Memory footprint is larger due to Raft log and in-memory index.

Cross-cluster replication is not native to quorum queues. Use Federation or Shovel for multi-site.

Migration from mirrored queues requires shovel or re-publish. There is no in-place conversion.

Actionable checks

Before rollout, confirm quorum health in staging: stop a follower node, publish, verify availability; stop the leader, verify a new election completes and publishing resumes. Check disk latency and fsync times on all nodes. Set alerts on quorum status and storage bytes per queue.

If you need strong durability guarantees under partitions, quorum queues are the supported path. Accept the write latency and disk requirements, and design clients for confirms and manual acks.