Power Node Rabbitmq-18-21 Chapter RabbitMQ Cluster and High Availability

18 RabbitMQ cluster and high availability

The RabbitMQ cluster is divided into two modes, one is the default cluster mode, and the other is the mirror cluster mode;
all nodes in the RabbitMQ cluster (a node is a RabbitMQ broker server) are classified into two categories: one is a disk node , one is the memory node;
the disk node will persist all the information of the cluster (such as switches, bindings, queues, etc.) to the disk, and the memory node will only save this information in memory. Or restart, all the data of the memory node will be lost, but the data of the disk node will not be lost;

18.1 Default cluster mode

The default cluster mode is also called normal cluster mode or built-in cluster mode;
RabbitMQ’s default cluster mode only synchronizes metadata information such as switches, queues, and virtual hosts on each node, while the message content in specific queues will not be stored on each node. Synchronization;

Metadata
Queue metadata: Queue name and attributes (whether it can be persisted or not, whether it is automatically deleted)
Exchange metadata: Exchange name, type and attributes
Binding metadata: Binding list
vhost metadata of exchanges and queues : Related attributes in vhost, such as security attributes, etc.;
when a user accesses any of the RabbitMQ nodes, the queried information such as queue/user/exchange/vhost is the same;
but the specific information data of the queue in the cluster is only in the queue The owner node of the queue is saved, and other nodes only know the metadata of the queue and the pointer to the node, so when other nodes receive a message that does not belong to the queue of the node, they will pass the message to the owner node of the queue; why the
cluster To not replicate queue contents and state to all nodes:

1. storage;

2) Performance;
if the message needs to be copied to each node in the cluster, the network overhead is unavoidable, and the persistent message also needs to be written to the disk, occupying disk space.
So here comes the question?
If there is a message producer or message consumer connected to node 1 to send or receive messages through the amqp-client client, then the message sending and receiving in the cluster is only related to node 1, and there is no problem; if the
client The connection is node 2 or node 3 (queue 1 data is not on this node), so what will happen?
If the message producer is connected to node 2 or node 3, and the complete data of queue 1 is not on these two nodes at this time, then these two nodes mainly play a role of routing and forwarding in the process of sending messages. According to these two The metadata on the node (that is, the pointer to the owner node of the queue) is forwarded to node 1, and the final sent message will still be stored in queue 1 of node 1; similarly, if the node 2 or node connected to the message
consumer 3. These two nodes will also act as routing nodes to forward, and will obtain messages from queue 1 of node 1 for consumption;

19 Preparations before installation

19.1 Clone three machines from the machine that has installed rabbitmq

19.2 Reset the mac addresses of the three machines

Note that after cloning, do not start the three machines first, and the three machines must regenerate the mac address to prevent the ip address of the cloned machine from being duplicated

19.3 Starting three machines

Start and view the ip addresses of the three machines:

ip a

19.4 Use xshell to connect three machines

19.5 Modify the /etc/hosts files of the three machines

First, you need to configure the hosts file, because the RabbitMQ cluster node name is obtained by reading the hosts file;
vim /etc/hosts

| 192.168.131.128 rabbit128
192.168.131.129 rabbit129

192.168.131.130 rabbit130

19.6 Restart the network on all three machines to make the node name take effect

systemctl restart network

19.7 The xshells of the three machines exited and then reconnected

19.8 Firewall handling of three machines

| systemctl status firewalld
systemctl stop firewalld -- turn off the firewall

systemctl disable firewalld -- do not start the firewall at boot

19.9 The .erlang.cookie files of the three machines are consistent

Since the three machines are cloned, they must be the same

| If we use the RabbitMQ installed by decompression, then the file will be in $Under\; the\; usernamedirectory,\; that\; is,$ {username}/.erlang.cookie;

If we use the rpm installation package to install, then this file will be in the /var/lib/rabbitmq directory;

Note that the permission of .erlang.cookie is 400, which is already 400

20 Start rabbitmq on three machines separately

20.1 Startup

rabbitmq-server -detached

20.2 Check the cluster status

Use the following command to view the cluster status

rabbitmqctl cluster_status

20.4 Building a cluster

Execute the command on the rabbitmq129 machine to let 129 rabbitmq join the cluster:

| ./rabbitmqctl stop_app
./rabbitmqctl reset

./rabbitmqctl join_cluster rabbit@rabbit128 --ram

./rabbitmqctl start_app

The –ram parameter means to make rabbitmq129 a memory node. If there is no parameter, it will be a disk disk node by default;
after adding the rabbit129 node;
execute the same command on the rabbit130 node to make the rabbit130 node also join the cluster.

| ./rabbitmqctl stop_app
./rabbitmqctl reset

./rabbitmqctl join_cluster rabbit@rabbit128 --ram

./rabbitmqctl start_app

Of course, rabbit130 can also be used as a disk node

20.5 Operate a node, add users and permissions, etc.

| #List users
rabbitmqctl list_users

Add user

rabbitmqctl add_user admin 123456
#View permissions
rabbitmqctl list_permissions
#Set permissions
rabbitmqctl set_permissions admin ". " " ". " ".*"
#Set role
rabbitmqctl set_user_tags admin administrator
#Start the web console plug-in

./rabbitmq-plugins enable rabbitmq_management

Add a virtual host using a web browser: powernode

20.6 View the cluster status again

After executing the operation, we visit the web console in the browser to see the effect;
open the web console on any node to see the information of each node in the cluster environment; you
can also use ./rabbitmqctl cluster_status to view the cluster status;

20.7 Some Principles

The underlying layer of RabbitMQ is implemented through the Erlang architecture, so rabbitmqctl will start the Erlang node, and use the Erlang system to connect to the RabbitMQ node based on the Erlang node. During the connection process, the correct Erlang Cookie and node name are required. Erlang nodes exchange Erlang Cookies to obtain certification;

The above is the construction of the RabbitMQ default cluster mode (ordinary cluster mode);

20.8 Springboot connection cluster

| spring:
_#Configure rabbitmq
_rabbitmq:
_#Connect to the cluster, separated by commas
_addresses: 192.168.150.150:5672,192.168.150.151:5672,192.168.150.152:5672
username: admin
password: 123456
virtual-host: powernode |
| — |

21 mirror cluster mode

The mirror mode is based on the default cluster mode plus certain configurations;
in the default mode of the RabbitMQ cluster, it will copy the metadata of switches, bindings, and queues of all nodes to ensure that all nodes have the same metadata Data information, but the queue data is divided into two types: one is the metadata information of the queue (such as the maximum capacity of the queue, configuration information such as the name of the queue), and the other is the messages in the queue; the mirror mode is to put
all The queue data is completely synchronized, including metadata information and message data information. Of course, this will definitely have a certain impact on performance. When the data reliability is high, you can use the mirroring mode; implementing the mirroring mode is also very simple. It is
in Built on the basis of ordinary cluster mode;
mirror queue configuration command:
./rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]
-p Vhost: optional parameter, set for the queue under the specified vhost;
Name: The name of the policy; (you can choose a name yourself)
Pattern: queue matching pattern (regular expression);
Definition: mirror definition, including three parts ha-mode, ha-params, ha-sync-mode; (json format)
{"ha-mode":"exactly","ha-params":2}
ha-mode: indicates the mode of the mirror queue, and the valid value is all/exactly/nodes
all: indicates that all nodes in the cluster perform Mirror
exactly: means to mirror on the specified number of nodes, the number of nodes is specified by ha-params
nodes: Indicates that mirroring is performed on the specified node, and the node name is specified by ha-params ha
-params: the parameters required for ha-mode mode
ha-sync-mode: the synchronization method for messages in the queue, and the valid values ​​are automatic and manual
priority: optional parameter, the priority of the policy;
for example, if you want to configure all queues whose names start with policy_ for mirroring, and the number of mirrors is 2, then the command is as follows (execute the following command on any node):
./rabbitmqctl set_policy [-p Vhost] Name Pattern Definition [Priority]

./rabbitmqctl set_policy -p powernode ha_policy “^policy_” ‘{“ha-mode”:“exactly”,“ha-params”:2,“ha-sync-mode”:“automatic”}’

If you want to mirror on all queues on all nodes, then (execute the following command on any node):
all nodes, all virtual hosts, and all queues are mirrored./rabbitmqctl
set_policy [-p Vhost] Name Pattern Definition [Priority]

./rabbitmqctl set_policy ha-all “^” ‘{“ha-mode”:“all”}’

Mirror a virtual host

rabbitmqctl set_policy -p powernode ha-all “^” ‘{“ha-mode”:“all”,“ha-sync-mode”:“automatic”}’

(On the basis of the default cluster mode, execute the above command to change a default cluster mode into a mirror cluster mode)