Message Queues ¶
- All data/state required for the operation of a RabbitMQ broker is replicated across all nodes.
- An exception to this are message queues, which by default reside on one node, though they are visible and reachable from all nodes.
- To replicate queues across nodes in a cluster, use a queue type that supports replication.
- A client can connect to any node and perform any operation.
- Nodes will route operations to the quorum queue leader or queue master replica transparently to clients.
- All supported messaging protocols a client is only connected to one node at a time.
- In case of a node failure, clients should be able to reconnect to a different node, recover their topology and continue operation. For this reason, most client libraries accept a list of endpoints (hostnames or IP addresses) as a connection option. The list of hosts will be used during initial connection as well as connection recovery, if the client supports it.
- With quorum queues, clients will only be able to perform operations on queues that have a quorum of replicas online.
- This topic is covered in the Quorum Queues and Classic Mirrored Queues guides.
- RabbitMQ gets an HA upgrade: https://www.rabbitmq.com/blog/2020/04/20/rabbitmq-gets-an-ha-upgrade/
- You cannot turn a classic queue into a quorum queue via policies though. The x-queue-type property set to quorum must be included in the queue declaration. It is a quorum queue from birth.
- With classic mirrored queues, there are scenarios where it may not be possible for a client to transparently continue operations after connecting to a different node. They usually involve non-mirrored queues hosted on a failed node.
Stats and Metrics