Cluster expansion
Prerequisites, there are currently 6 machines in the cluster, the port numbers are 6381 , 6382 , 6383 , 6384 , 6385 , 6386
1) Prepare the new node
Prepare two new nodes, the port numbers are 6387 and 6388 , the configuration is the same as the previous cluster configuration, and start the two nodes.
2) Join the cluster
Enter any node in the cluster and use the cluster meet command to add a new node to the cluster.
The new node is the master node state at the beginning, but because there is no responsible slot, it cannot accept any read and write operations. There are generally two options for subsequent operations on new nodes:
◆ Implement expansion for its migration slots and data
◆ Slaves acting as other masters are responsible for failover
The redis-trib.rb tool also implements the command to add new nodes to the existing cluster, and also implements support for adding slave nodes directly. For the above expansion operations, the following commands can be used to add new nodes:
redis-trib.rb add-node 127.0.0.1:6387 127.0.0.1:6381
redis-trib.rb add-node 127.0.0.1:6388 127.0.0.1:6381
3) Migrate slots and data, and migrate some of the slots in 6381 to 6387
a) Use the redis-trib.rb slot resharding command:
b) To confirm the number of slots to be migrated, enter 2000
c) Enter the node ID of 6387 as the target node. Only one target node can be specified:
d) Then enter the ID of the source node. Here, enter the three node IDs of 6381, 6382 and 6383 respectively, and finally use done to indicate the end:
e) Before data migration, the plan of all slots from the source node to the target node will be printed out. After confirming that the plan is correct, enter yes to execute the migration work. After the plan is executed, the reshard command will automatically exit.
4) Add slave node
Before the expansion, nodes 6387 and 6388 were added to the cluster. Node 6387 migrated some slots and data as the master node. However, compared with other master nodes, it currently has slave nodes, so this node does not have the ability to fail over. At this time, the node 6388 needs to be used as the slave node of 6387 to ensure the high availability of the entire cluster. It should be noted here that in cluster mode, the previous master-slave configuration command slaveof to add slave nodes is no longer supported. Execute the following command to start the ID of the master, that is, the ID of 6387:
Verify the configuration result:
cluster shrink
The current node status is as follows:
1) Migration tank
Now take nodes 6383 and 6386 offline, 6383 is the master node, responsible for slots 11589-16383, and 6386 is its slave node. Before offline 6383, the responsible slot needs to be migrated to other nodes.
Shrinking is exactly the opposite of the direction of expansion and migration. 6383 becomes the source node, and other master nodes become target nodes. The source node needs to evenly migrate the 4795 slots it is responsible for to other master nodes. Since only one target node can be executed each time the reshard command is executed, the reshard command needs to be executed three times to migrate 1598, 1598, and 1599 slots respectively. The migration process is the same as the expansion operation, except that you need to pay attention to the target node and the source node, and there is no need to migrate wrong.
After the migration is complete, find out the cluster status, and you can see that the 6383 node is no longer responsible for any slots
2) Forget nodes
You can use the redis cluster forget {downNodeId} command to forget a node, but it is recommended to use the redis-trib.rb command to forget a node, where the ID is the ID of the node to go offline:
3) Check the cluster status again
