Migrating to RabbitMQ Quorum Queues for Data Consistency

Use a Quorum Queue when you need RabbitMQ to survive node loss and network partitions without data loss. Quorum Queues replace deprecated mirrored queues by replicating messages with Raft consensus, requiring a majority of nodes to persist before an ack is sent to the publisher.

How Raft replication works

A Quorum Queue has a leader and followers. The publisher sends to the leader. The leader appends the entry to its log and replicates to followers. An ack is returned only after N/2 + 1 nodes, including the leader, have flushed the entry to disk. This disk-based design avoids split-brain and corruption seen with classic mirrored queues.

With 3 nodes you can lose 1 node and remain writable. With 5 nodes you can lose 2. The minimum for HA is 3 nodes.

Declare a quorum queue

Queue type is set at declaration and cannot be changed later. The queue must be deleted and recreated to change type.

# rabbitmqadmin run as a cluster admin
rabbitmqadmin declare queue name=orders_processing arguments='{"x-queue-type":"quorum","x-message-ttl":60000}'

x-queue-type:quorum is required. x-message-ttl is supported. The queue is persistent by design; transient mode is not applicable.

Verify replication and health

Check leader and sync state in Management UI or via CLI.

rabbitmqadmin list queues name leader node sync_count

Stop a follower node to simulate failure. The Raft group elects a new leader automatically if a majority remains. Publish a test message with publisher confirms enabled; a successful ack confirms quorum is still met.

Monitor rabbitmq_quorum_queues metrics for leader changes and replication lag.

Limits and common mistakes

• Lower throughput than classic queues. Each publish requires disk sync and network round trips for consensus.
• No message priority and no classic consistent-hash routing. Use alternative patterns if you need those features.
• Disk I/O bound. Ensure SSD storage with sufficient IOPS; every message must be synced to disk for safety.
• Do not use for high-volume transient data where loss is acceptable. Raft overhead wastes CPU and disk.
• Ignoring replication lag. Slow followers increase publish latency because the leader waits for quorum acks.