The RabbitMQ default cluster mode is configured above, but it does not guarantee high availability of queues. Although switches and bindings can be copied to any node in the cluster, the content of the queue is not copied. Although the mode solves some node pressures, the queue node outage directly causes the queue to fail.You can only wait for a reboot, so if you want the queue node to work properly when it goes down or fails, copy the contents of the queue to each node in the cluster and create a mirror queue

Mirror queue concept

Mirror queues can synchronize queues and messages, and when the master queue hangs up, one of the queues becomes master queue to take over.

Mirror queues are based on the normal cluster mode, so you have to configure the normal cluster before you can set up the mirror queue.

After the image queue is set up, it is divided into one master node and several slaves. If the master node is down, the slave node will have a master node, and the original master node will become a slave node when it is up.

queueAnd message will exist in all mirrored queues, but when the client reads the data from the master node, whether the master or slave nodes are physically connected, then the master node synchronizes the status of the queue and message to the slave node, so multiple clients connect different mirrors.The queue does not produce the same message being accepted many times.

Mirror queue policy

In any common cluster, any node will enable policies, and policies will automatically synchronize to cluster nodes.

Command format

set_policy [-p vhostpath] {name} {pattern} {definition} [priority]

Execute on any node.

[root@node1 ~]# rabbitmqctl set_policy -p / ha-allqueue “^message” ‘{“ha-mode”:”all”}’

Setting policy “ha-allqueue” for pattern “^message” to “{\”ha-mode\”:\”all\”}” with priority “0”

Note: The rule “^ message” is self-modifying, which refers to the queue name that starts with the synchronization “message” and is applied to all queues when configured, so the expression is “^”

Cluster reboot

When the cluster restarts, the last node that hangs should be the first to restart, if for special reasons (such as simultaneous power failure), it is not known which node is last to hang up. The following methods can be used to restart:

First execute on a node.

$ rabbitmqctl force_boot

 

$ service rabbitmq-server start

Execute on other nodes

$ service rabbitmq-server start

See if the cluster state is normal (to query on all nodes).

 

$ rabbitmqctl cluster_status