Why Queue Replication Matters
In a plain RabbitMQ cluster, a classic queue lives on exactly one node, so if that node crashes, every unconsumed message on the queue becomes unavailable until the node recovers, and if the node's disk is lost, those messages are gone permanently. Both mirrored classic queues (legacy) and quorum queues (current) solve this by replicating queue contents across multiple nodes, so the queue remains available and durable even if the minority of replicas fail. RabbitMQ deprecated mirrored queues starting in version 3.9 and removed them entirely in 4.0, making quorum queues the standard mechanism for high-availability queues.
Cricket analogy: It's like a team relying on a single wicketkeeper's scorebook as the only record of a match; if he's injured mid-game the record is lost, whereas having three official scorers keeping synchronized books means the record survives any one scorer stepping away.
Classic Mirrored Queues (Legacy, Removed in 4.0)
Classic mirrored queues worked by designating one node as the master and replicating every operation to slave mirrors on other nodes using a policy that matched queue names to an ha-mode such as all or exactly N nodes. The fundamental problem was that mirroring used asynchronous replication without a proper consensus protocol, so during network partitions or master failures it was possible to lose messages or, worse, end up with inconsistent state between mirrors that had to be manually reconciled. This unreliability, combined with poor performance under high mirror counts, led the RabbitMQ team to deprecate and eventually remove classic mirroring in favor of quorum queues.
Cricket analogy: It's like a team maintaining backup scorebooks by having assistants copy the main scorer's entries after the fact, without any formal cross-check protocol — if the main scorer makes an error or a copy lags behind, the backups can silently diverge from the truth.
Quorum Queues and Raft Consensus
Quorum queues replace mirroring with the Raft consensus algorithm: a queue is backed by a group of replicas, one elected as leader, and every message enqueue must be acknowledged by a quorum (a majority) of replicas before it is confirmed to the publisher. This guarantees that as long as a majority of replicas are alive, the queue keeps working correctly with no data loss, and a leader failure triggers an automatic, safe leader election among the remaining replicas rather than relying on best-effort async copying. You declare a quorum queue by setting the x-queue-type argument to quorum, and RabbitMQ recommends an odd number of replicas (typically 3 or 5) since Raft quorums are majority-based.
Cricket analogy: It's like the third umpire decision system requiring a majority of review angles to confirm an out before it's given, rather than trusting a single camera's asynchronous feed — a decision only stands once a quorum of evidence agrees.
# Declare a quorum queue with 3 replicas via rabbitmqadmin or a client library
rabbitmqadmin declare queue name=orders.quorum \
durable=true \
arguments='{"x-queue-type":"quorum"}'
# Equivalent in Python using pika
import pika
conn = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
ch = conn.channel()
ch.queue_declare(
queue='orders.quorum',
durable=True,
arguments={'x-queue-type': 'quorum'}
)Quorum queues are always durable and do not support the exclusive or auto-delete flags used by some classic queue patterns. They also hold the entire message body in memory during normal operation more aggressively than classic queues, so plan memory capacity accordingly for high-throughput quorum queue workloads.
As of RabbitMQ 4.0, classic mirrored queues (ha-mode policies) have been removed entirely. If you're running an older cluster with mirrored queues, migrate to quorum queues before upgrading to 4.0, since the upgrade will refuse to proceed with mirrored queue policies still in place.
- Classic queues live on a single node and are lost if that node fails permanently.
- Classic mirrored queues (ha-mode policies) used async replication and were removed in RabbitMQ 4.0.
- Quorum queues use the Raft consensus algorithm, requiring majority acknowledgment for each enqueue.
- A quorum queue survives the loss of a minority of its replicas with no data loss.
- Declare quorum queues with the x-queue-type: quorum argument, typically with 3 or 5 replicas.
- Leader election among replicas is automatic and safe, unlike best-effort mirror promotion.
- Quorum queues are always durable and don't support exclusive or auto-delete semantics.
Practice what you learned
1. What consensus algorithm do RabbitMQ quorum queues use?
2. As of which RabbitMQ version were classic mirrored queues (ha-mode) completely removed?
3. How is a quorum queue declared using client arguments?
4. Why does RabbitMQ recommend an odd number of quorum queue replicas, such as 3 or 5?
Was this page helpful?
You May Also Like
RabbitMQ Clustering Basics
Learn how RabbitMQ nodes join together to form a cluster, how metadata and queue state are shared, and what happens when nodes fail.
RabbitMQ Performance Tuning
Practical techniques for maximizing RabbitMQ throughput and minimizing latency, covering prefetch, publisher confirms, queue type choice, and memory/disk alarms.
Monitoring RabbitMQ
Learn the key metrics, tools, and alerting strategies for keeping a RabbitMQ cluster observable and catching problems before they cause outages.