Centos7 deploys RabbitMQ mirror queue cluster

1. Background

In the section of the previous chapter on , we learned how to build a single-node RabbitMQ server, but the single-node RabbitMQ is unreliable. If the single-node hangs up, the message queue will be unavailable. Here we build a 3-node RabbitMQ cluster to solve this problem.

Two, introduce the RabbitMQ cluster

1. Cluster type

By default, the RabbitMQ cluster is only the metadata (metadata) is synchronized, and the messages in the queue are not synchronized. This is also insecure. It needs to be configured as a mirror queue to make the data redundant to other nodes. To ensure that a node is down, it can also provide services to the outside world.

metadata: Refers to queue information, switch information, binding information, etc.

2. The importance of node names

In the cluster, the node name must be unique, and the cluster is contacted through the node name.


3. The importance of erlang cookie

What is the authentication of the cluster nodes so that the cluster nodes can communicate with each other, relying on erlang cookie , so the value of the erlang cookie in the cluster must be consistent.

1. The location of the erlang cookie file

The location of this file is different for different operating systems.

This position is generally at /var/lib/rabbitmq/.erlang.cookie .

2. Permission of erlang cookie file

.erlang.cookie file permissions general to 600 on it, do not give too high or too low, otherwise the cluster may not start.


4. Cluster node type

The RabbitMQ cluster is divided into disk nodes and memory nodes.
1. disk node is stored on the disk
2, memory node data is stored in memory, but not all the data is in memory of the presence of , such as: the message will only exist indexes.
in a cluster requires at least one disk (disc) node

5. Add nodes to the cluster

The node of the newly added cluster must be a brand new node and cannot carry data. If it exists, you need to execute rabbitmqctl reset on the node that joins the cluster.

Three, build a RabbitMQ cluster

Here we use 3 Centos7 servers to build a RabbitMQ cluster.

CPU name	ip address	Node type	username	password	management port	amqp port
centos01	192.168.56.101	Disk node (disc)	admin	admin	15672	5672
centos02	192.168.56.102	Disk node (disc)	admin	admin	15672	5672
centos03	192.168.56.103	Memory node (ram)	admin	admin	15672	5672

　　

1. Configure 3 servers to be able to access their respective hostnames

This is required on all 3 servers
vim /etc/hosts

bash192.168.56.101 centos01
192.168.56.102 centos02
192.168.56.103 centos03

2. Synchronize the erlang cookie of each node

If the cookie file does not exist, you can start a RabbitMQ node, and then copy the past, in the process of copying, you need to ensure that the RabbitMQ node is best not to start.

on the centos01 server

scp /var/lib/rabbitmq/.erlang.cookie root@192.168.56.102:/var/lib/rabbitmq/.erlang.cookie
scp /var/lib/rabbitmq/.erlang.cookie root@192.168.56.103:/var/lib/rabbitmq/.erlang.cookie

3. Create a cluster

1. Operation on centos01 server

rabbitmq-server -detached

You can check /var/log/rabbitmq/rabbit\@centos01.log see if the startup is successful.

2. Release the cluster communication port, etc.

firewall-cmd --zone=public --add-port=5672/tcp --permanent
firewall-cmd --zone=public --add-port=15672/tcp --permanent
firewall-cmd --zone=public --add-port=4369/tcp --permanent
firewall-cmd --zone=public --add-port=25672/tcp --permanent

3. Centos02 joins centos01

rabbitmq-server -detached
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@centos01
rabbitmqctl start_app

4. Centos03 join centos02

rabbitmq-server -detached
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@centos02 --ram
rabbitmqctl start_app

5. Check whether the cluster is built

6. Remove the centos03 cluster

1. Stop the node that needs to be removed

rabbitmqctl stop

2. Execute on another node that is started

rabbitmqctl forget_cluster_node rabbit@centos03

3. Rejoin the cluster

The following error may be reported during startup: "Node rabbit@centos03 thinks it's clustered with node rabbit@centos02, but rabbit@centos02 disagrees"

At this time, we need to delete rm -rvf /var/lib/rabbitmq/mnesia/ , and then execute the command to join the cluster next time.

rabbitmq-server -detached
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@centos02 --ram
rabbitmqctl start_app

Fourth, configure the mirror cluster

1. Ordinary cluster

The cluster formed by the above steps is an ordinary cluster, but the metadata in the queue is shared, and the data in the queue is specifically stored on a certain node.

This is not enough for high availability. If the node hangs up, the data in this queue cannot be consumed, and data cannot be sent to this queue. So if this problem is solved, the answer is to use a mirrored queue cluster.

2. Mirror queue cluster

All queues in the default virtual host ( / ) are configured as mirrored queues. ( ha-all is just a name)

rabbitmqctl set_policy --vhost / ha-all "^" '{"ha-mode":"all"}'


After creating the mirror queue, it is found that the queue exists on all nodes.

For advanced usage of mirror queue, refer to official document 161b801ade2d8d https://www.rabbitmq.com/ha.html

Five, reference documents

1. RabbitMQ official cluster to build
2, usage image queue