A RabbitMQ cluster consists of several RabbitMQ nodes (instances) that work together and form a single logical broker. Queues in a RabbitMQ cluster only reside on one of the RabbitMQ nodes, along with all of their content. But this is just the default, which can be changed using mirrored queues. Mirrored queues behave as if they are on all nodes, actions such as handling consumers or routing messages can be done on any of the nodes. The nodes will route the actions to the node where the queue actually is, so it is fully transparent for the clients. Queues are only on a number of nodes, but exchanges and bindings are on all nodes. Let us take a look at mirrored and non-mirrored queues.
Mirrored queues
Mirrored queues in RabbitMQ consist of a master and one or several mirrors. All messages are sent to the master and the mirrors. In a case where the master node goes down one of the mirrors will take over, so that no messages are lost.
You may think that you are now missing a mirror. However RabbitMQ will make one of the nodes a mirror of the new master. So you always have the same amount of mirrors - except if there are no more nodes to make mirrors of.
Having mirrors creates High availability but not loadbalancing. Since it is always the master node servicing the consumption. When the master node has handled a message the mirrors automatically delete the message as well. However all nodes (even nodes that are not mirrors) can still route all requests to the master. So any node can be used to contact the master - not just the ones that are mirrors of the master.
Mirrors are created and configured using policies. In a policy you can set how many mirrors you want. More details on how to set this up can be found here.
When we look at availability, having mirrored queues serves as a failover if one of the RabbitMQ nodes goes down.
Non-mirrored queues
What happens to a non-mirrored queue when a node goes down depends on whether the queue is durable or not. If the queue is not durable it will simply be deleted and can be redeclared by another node.
Should the queue be durable then it will become unavailable. All actions on this queue will cause the following error: "operation queue.declare caused a channel exception notfound". Rendering the queue useless until the node is back online. Therefore queue mirroring is advisable if you want high availability.
Durable queues that are not mirrored in a cluster setup have a single point of failure (the node)
That is all
Did I miss something or is anything unclear, let me know in the comments :)