Shulou(Shulou.com)06/02 Report--

This article introduces the relevant knowledge of "the concept and process of Redis cluster contraction". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Concept

Shrinking the cluster means reducing the size of the cluster nodes, that is, some nodes need to be offline. The process of the offline node is as follows:

Process flow

1. First of all, you need to determine whether the offline node has a responsible slot, and if so, you need to migrate the slot to other nodes to ensure the integrity of the mapping of the entire cluster slot node after the node is offline.

two。 When the offline node is no longer responsible for the slot or is a slave node, it can forget the offline node through other nodes in the cluster, so that when all nodes forget the offline node, the node can be shut down normally.

Offline migration slot

Offline nodes need to migrate their responsible slots to other nodes, which is the same as the cluster expansion and migration slots introduced in the previous article. Let's take the 6381 and 6383 nodes offline.

6381 is the primary node, and as shown in the figure above, we know that this node is responsible for slots 8192-12287. According to the process we described above, we need to migrate the slots that the node is responsible for to other nodes before we go offline. And the contraction of the cluster and the expansion of the cluster are just the opposite. We need to turn 6381 nodes into source nodes and other master nodes into target nodes. We still use the redis-trib reshard command when migrating slots. Because the reshard command can only have one target node, we need to execute the reshard command three times when we want to migrate 4096 slots. In order to ensure that the migration slots migrate evenly to other nodes, we migrate the above 4096 slots to 1365, 1365 and 1366 slots respectively.

Let's migrate 6381 of the slots to 6379:

When the slot migration is complete, we can see that the 6379 node has been responsible for the new migration slot.

Let's move 1365 of the slots to 6380 in the same way:

View the slot that the 6380 node is now responsible for.

We still migrate 1366 of the slots to 6382 in the same way:

Continue to view the slots for which the 6382 node is responsible.

And from the figure above, we already know that the 6381 nodes are no longer responsible for any slots. Let's move on to the second step of the process, that is, after the migration of the node slot to be offline is completed, we also need to make the cluster forget the node that is offline.

Forget the node

As we mentioned before, the nodes in the cluster constantly exchange node status with each other through Gossip messages, so to make other nodes in the cluster forget the offline node is to make other nodes stop exchanging Gossip messages with the node to be offline. In Redis, we use the cluster forget {downNodeId} command.

When the node receives the cluster forget {downNodeId} command, the node specified by nodeId is added to the disabled list, and the node in the disabled list no longer sends Gossip messages. The disabled list is valid for 60 seconds, and nodes will continue to participate in the message exchange for more than 60 seconds. Therefore, to make other nodes in the cluster forget the offline node is to operate within these 60 seconds. In the actual operation, if you use the cluster forget {downNodeId} command to go offline, it may cause omissions because a large number of node command interactions are involved and there is a limit of 60 seconds. So in the actual operation, we will not use the cluster forget {downNodeId} command to offline the node. We will use the redis-trib.rb del-node {host:port} {downNodeId} command.

Note: when using the redis-trib.rb del-node {host:port} {downNodeId} command to offline a node, it is recommended to give priority to the offline slave node, and then to the offline master node to avoid unnecessary replication. So let's give priority to 6383 nodes, followed by 6381 nodes.

When the node is offline, we can check the status of the cluster node for the second time, and we find that the 6381 node is no longer in the cluster.

This is the whole content of Redis shrinking cluster, to put it bluntly, that is, some of the cluster node functions are offline. This is very necessary in our actual development, to master cluster expansion and contraction of the cluster, we can make a calm response in the actual scenario.

This is the end of the introduction to the concept and process of Redis cluster contraction. Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.