This article introduces the Redis Cluster cluster, and briefly introduces the implementation of the cluster. It is mainly a specific practical part: cluster startup, failover, adding nodes, removing nodes
Basic concepts of Redis cluster
Redis's cluster mode provides data fragmentation and ensures the availability of each partition. Each node of redis cluster needs to open two TCP connections, one to provide services for clients, such as 6379, and the other port + 10000 on the first port, which is 16379. For cluster bus, nodes use cluster bus for fault detection, configuration update, failover authorization, etc. Clients should not attempt to connect to the cluster bus interface. These two ports must be open for the cluster to work properly. (offset of both ports is always 10000)
Data fragmentation in cluster
Redis Cluster does not use consistent Hash. It uses another method: Hash slot.
There are 16384 hash slots in Redis cluster. CRC 16 & 16384 are used to calculate the hash slots. Each node of Redis cluster is responsible for A part of hash slot, for example, three nodes, including node A (0-5500), node B (5501-11000), and node C (11001-16383)
When adding or deleting A node, you only need to move some slots on the node to A new node. For example, you need to add A new node D, and move some slots on A, B, and C to d. To delete A node, for example, if you need to delete A, you only need to move the slot on A to B and C.
Master-slave model in cluster
To ensure the availability of each node in the cluster, the cluster uses the master-slave model. For example, in the three master and three slave architecture, a, B, C, A1, B1, C1, a and A1 are the primary and secondary replication. If node a fails, the cluster will upgrade A1 to the primary node, ensuring the availability of the cluster. If A1 fails, the cluster will not be available.
Cluster consistency guarantee
Redis Cluster cannot guarantee strong consistency of data. Asynchronous replication of redis is the first reason why data consistency cannot be guaranteed: the client writes data to a -- > a replies to the client -- > a spreads the data to nodes A1,A2,A3. There may be failures in the process of diffusion, resulting in data loss. Replication diffusion can be set to synchronize, write all and return to the client, but this will result in low performance.
When the network is partitioned, the client is isolated from a few instances, and the data may also be lost. A, A1, B, B1, C, C1, client, and client are writing data to C, resulting in the network partition, resulting in the isolation of client and C. The cluster elects C1 as the new master node, and after the network is restored, the data in C will be lost, This situation controls the loss of data by setting the node timeout. After a node time-out, the primary node is considered a failure and can be replaced by one of the replicas. Similarly, after the node timeout has passed and the master node cannot sense most of the other masters, it enters an error state and stops accepting writes.
The consistency of Redis cluster basically requires a balance between performance and y consistency.
Redis cluster configuration
cluster-enabled <yes/no> cluster-config-file <filename> cluster-node-timeout <milliseconds> cluster-slave-validity-factor <factor> cluster-migration-barrier <count> cluster-require-full-coverage <yes/no>
- Cluster enabled < yes / no >, whether cluster mode is enabled or not. It is not enabled by default
- Cluster config file < filename >, after the cluster is turned on, the Redis cluster will write the configuration of each change to the file, and use this configuration file when restarting. This document is generally not considered to be altered.
- Cluster node timeout < milliseconds >, the timeout time of the node is long. If the node cannot access it for more than this time, the slave node will fail over.
- Cluster slave validity factor < factor >, if set to zero, the slave will always attempt to fail over the master, regardless of whether the link between the master and the slave remains disconnected or not. If the value is positive, the maximum disconnection time is multiplied by the node timeout value provided by this option. If the node is a slave node, the failover will not be attempted if the primary link disconnects for more than the specified time. For example, if the node timeout is set to 5 seconds and the validity factor is set to 10, a slave device that is disconnected from the master device for more than 50 seconds will not attempt to fail over its master device. Note that if no slave can fail over it, any value different from zero may cause the Redis cluster to become unavailable after the primary fails. In this case, the cluster will return only if the original primary server rejoins the cluster.
- Cluster migration barrier < count >, the master server will keep the minimum number of slave servers connected, so that another slave server will migrate to the master server that is no longer covered by any slave servers.
- Cluster require full coverage < yes / no >,: if set to yes, by default, if any node does not cover a certain percentage of key space, the cluster will stop accepting writes. If this option is set to no, the cluster will provide queries even if it can only process requests about a subset of keys.
Redis Cluster use
The Redis version I use here is 5.0.3. Different versions may have different commands.
First, prepare six Redis nodes. If the conditions are limited, they will be on one server. Copy six redis.conf , the most basic configuration must be:
port 7000 cluster-enabled yes cluster-config-file nodes.conf cluster-node-timeout 5000 appendonly yes
The port numbers of the six nodes are: 700007002700370047005
Start 6 nodes respectively:
redis-server redis-1.conf redis-server redis-2.conf redis-server redis-3.conf redis-server redis-4.conf redis-server redis-5.conf redis-server redis-6.conf
Now six nodes have been opened
[root@iZnom30el3gvhxZ redis]# ps -ef | grep redis root 16270 1 0 15:15 ? 00:00:09 redis-server *:7000 [cluster] root 16277 1 0 15:15 ? 00:00:09 redis-server *:7001 [cluster] root 16534 1 0 15:20 ? 00:00:08 redis-server *:7003 [cluster] root 16541 1 0 15:20 ? 00:00:08 redis-server *:7004 [cluster] root 16548 1 0 15:20 ? 00:00:08 redis-server *:7005 [cluster] root 17158 1 0 15:33 ? 00:00:08 redis-server *:7002 [cluster] root 22290 13798 0 17:17 pts/0 00:00:00 grep --color=auto redis
Turn on cluster mode
Use the following command to create Redis Cluster:
# Node has no password set redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 # Node set password redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 -a <requirepass>
Where -- cluster replicas 1 means that each node has a slave node
It should be noted that if you want to set passwords for instances, it is better to set the same passwords for all nodes and configure masterauth. Otherwise, there may be errors during failover. You can also open the cluster without setting the password. After opening, you can set the password through the config set masterauth abc config set requirepass abc config rewrite command.
[root@iZnom30el3gvhxZ cluster]# redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Performing hash slots allocation on 6 nodes... Master[0] -> Slots 0 - 5460 Master[1] -> Slots 5461 - 10922 Master[2] -> Slots 10923 - 16383 Adding replica 127.0.0.1:7003 to 127.0.0.1:7000 Adding replica 127.0.0.1:7004 to 127.0.0.1:7001 Adding replica 127.0.0.1:7005 to 127.0.0.1:7002 >>> Trying to optimize slaves allocation for anti-affinity [WARNING] Some slaves are in the same host as their master M: 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000 slots:[0-5460] (5461 slots) master M: 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001 slots:[5461-10922] (5462 slots) master M: 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002 slots:[10923-16383] (5461 slots) master S: 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003 replicates 07bc00f5b816a612e96ad2fcdc25b4decdc498bd S: 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004 replicates 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 S: 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005 replicates 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea Can I set the above configuration? (type 'yes' to accept): yes >>> Nodes configuration updated >>> Assign a different config epoch to each node >>> Sending CLUSTER MEET messages to join the cluster Waiting for the cluster to join ... >>> Performing Cluster Check (using node 127.0.0.1:7000) M: 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000 slots:[0-5460] (5461 slots) master 1 additional replica(s) M: 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002 slots:[10923-16383] (5461 slots) master 1 additional replica(s) S: 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005 slots: (0 slots) slave replicates 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea S: 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003 slots: (0 slots) slave replicates 07bc00f5b816a612e96ad2fcdc25b4decdc498bd S: 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004 slots: (0 slots) slave replicates 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 M: 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001 slots:[5461-10922] (5462 slots) master 1 additional replica(s) [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered.
After entering the command, you will be confirmed with the information, enter yes, and finally output [OK] All 16384 slots covered. That is to say, the cluster is created successfully.
Redis 5.0 also provides create cluster, which can also be used in utils / create cluster to start and close clusters.
Use redis cli to enter a node:
[root@iZnom30el3gvhxZ cluster]# redis-cli -c -p 7000 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7000>
-c to enter in the cluster mode, add the influence of this parameter or not, and demonstrate a little. First, save a key in redis to see:
127.0.0.1:7000> set foo bar -> Redirected to slot [12182] located at 127.0.0.1:7002 OK 127.0.0.1:7002>
It can be seen that the hash slot calculated by foo is 12182, which is stored in node 7002 in the third node
Let's see what the effect is if - c is not added:
[root@iZnom30el3gvhxZ cluster]# redis-cli -p 7000 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7000> get foo (error) MOVED 12182 127.0.0.1:7002 127.0.0.1:7000>
As you can see, an error (move 12182 127.0.0.1:7002) was thrown. In fact, when you enter redis cli in the cluster mode, this error will also appear. Only the client hides the error and re performs the operation on the 7002 node.
In redis cli, you can view the cluster status through cluster info:
127.0.0.1:7000> CLUSTER INFO cluster_state:ok cluster_slots_assigned:16384 cluster_slots_ok:16384 cluster_slots_pfail:0 cluster_slots_fail:0 cluster_known_nodes:6 cluster_size:3 cluster_current_epoch:6 cluster_my_epoch:1 cluster_stats_messages_ping_sent:1001 cluster_stats_messages_pong_sent:987 cluster_stats_messages_sent:1988 cluster_stats_messages_ping_received:982 cluster_stats_messages_pong_received:1001 cluster_stats_messages_meet_received:5 cluster_stats_messages_received:1988
cluster_state:ok Indicates that the cluster is normal
Test failover
cluster nodes to view the nodes in the cluster:
127.0.0.1:7000> CLUSTER NODES 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 myself,master - 0 1557916585000 1 connected 0-5460 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557916585000 3 connected 10923-16383 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 slave 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 0 1557916584562 6 connected 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557916585565 4 connected 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557916585966 5 connected 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 master - 0 1557916585000 2 connected 5461-10922
Close one of the primary nodes to simulate a failure scenario. Here, close 7000:
[root@iZnom30el3gvhxZ ~]# redis-cli -a abc -p 7000 shutdown Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. [root@iZnom30el3gvhxZ ~]# redis-cli -c -p 7001 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7001> CLUSTER NODES 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557972888691 3 connected 10923-16383 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557972889594 5 connected 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 myself,master - 0 1557972888000 2 connected 5461-10922 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 master,fail - 1557972867020 1557972866000 1 disconnected 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 master - 0 1557972888188 7 connected 0-5460 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557972889191 4 connected 127.0.0.1:7001>
It can be seen that the current status of port 7000 fail s, and the original node 7005 becomes the primary node.
Restart 7000 nodes:
[root@iZnom30el3gvhxZ ~]# cd /usr/local/redis/cluster/ [root@iZnom30el3gvhxZ cluster]# redis-server cluster1/redis.conf [root@iZnom30el3gvhxZ cluster]# redis-cli -c -p 7000 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7000> CLUSTER NODES 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557973018558 5 connected 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557973017957 4 connected 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 master - 0 1557973018000 2 connected 5461-10922 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 myself,slave 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 0 1557973018000 1 connected 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557973017556 3 connected 10923-16383 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 master - 0 1557973016553 7 connected 0-5460 127.0.0.1:7000>
7000 nodes are rebooted and become slave nodes.
Manual failover
Redis Cluster provides the function of manually performing failover. Sometimes we need to maintain and upgrade some points in the cluster. The specific instruction is CLUSTER FAILOVER, which needs to be executed on the slave node that wants to be promoted to the primary node
For example, if the 7000 node is a slave node of the 7005 node, and now you want to offline maintain the 7005 node, you need to upgrade the 7000 node to the primary node to maintain the availability of the external server. You need to execute the command in the client of the 7000 node:
[root@iZnom30el3gvhxZ cluster]# redis-cli -c -p 7000 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:7000> CLUSTER FAILOVER OK 127.0.0.1:7000> CLUSTER NODES 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557973168583 5 connected 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557973167380 4 connected 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 master - 0 1557973168884 2 connected 5461-10922 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 myself,master - 0 1557973168000 8 connected 0-5460 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557973168583 3 connected 10923-16383 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 slave 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 0 1557973169385 8 connected 127.0.0.1:7000>
7005 node has been changed to slave node, and 7005 node can be offline.
In manual failover, the client switching occurs on the premise that the new primary node completely replicates the failed old primary node data, avoiding data loss.
Add node
First, you need to prepare a new redis instance as the node to be added. As follows, 7006 is the newly started node
[root@iZnom30el3gvhxZ cluster]# ps -ef | grep redis root 8522 1 0 10:16 ? 00:00:25 redis-server *:7000 [cluster] root 18060 1 0 13:28 ? 00:00:00 redis-server *:7006 [cluster] root 18066 7831 0 13:28 pts/0 00:00:00 grep --color=auto redis root 26183 1 0 May15 ? 00:01:34 redis-server *:7001 [cluster] root 26190 1 0 May15 ? 00:01:35 redis-server *:7002 [cluster] root 26202 1 0 May15 ? 00:01:26 redis-server *:7003 [cluster] root 26208 1 0 May15 ? 00:01:26 redis-server *:7004 [cluster] root 26215 1 0 May15 ? 00:01:27 redis-server *:7005 [cluster]
The command to add a node is redis cli -- cluster add node 127.0.0.1:7006 127.0.0.1:7000. The first parameter after add node is the ip of the newly added node, and the second is the ip of any node in the cluster
[root@iZnom30el3gvhxZ cluster]# redis-cli --cluster add-node 127.0.0.1:7006 127.0.0.1:7000 -a wk123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Adding node 127.0.0.1:7006 to cluster 127.0.0.1:7000 >>> Performing Cluster Check (using node 127.0.0.1:7000) M: 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000 slots:[8461-16383] (7923 slots) master 1 additional replica(s) S: 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004 slots: (0 slots) slave replicates 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 S: 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003 slots: (0 slots) slave replicates 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea M: 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001 slots:[0-5460] (5461 slots) master 1 additional replica(s) M: 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002 slots:[5461-8460] (3000 slots) master 1 additional replica(s) S: 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005 slots: (0 slots) slave replicates 07bc00f5b816a612e96ad2fcdc25b4decdc498bd [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. >>> Send CLUSTER MEET to node 127.0.0.1:7006 to make it join the cluster. [OK] New node added correctly. 127.0.0.1:7006> CLUSTER NODES 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557985157416 12 connected 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557985159418 11 connected 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 master - 0 1557985158417 10 connected 8461-16383 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 master - 0 1557985158000 11 connected 0-5460 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557985158517 12 connected 5461-8460 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 0 1557985158000 10 connected 3425f765692f0b8b9c4931c038fae8d86fe6e383 127.0.0.1:7006@17006 myself,master - 0 1557985158000 0 connected
After executing the command of redis cli -- cluster add node 127.0.0.1:7006 127.0.0.1:7000 - a ABC, output [OK] New node added correctly. That is to say, adding a new node is successful. In redis cli, check that the node has been added, but there is no hash slot assigned on 7006. Now we need to assign some hash slots on other nodes to 7006 nodes (use the reset command), Here is a demonstration of dividing the nodes on 7000 nodes into 4000 to 7006 nodes:
[root@iZnom30el3gvhxZ cluster]# redis-cli --cluster reshard 127.0.0.1:7000 -a wk123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Performing Cluster Check (using node 127.0.0.1:7000) M: 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000 slots:[8461-16383] (7923 slots) master 1 additional replica(s) S: 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004 slots: (0 slots) slave replicates 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 S: 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003 slots: (0 slots) slave replicates 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea M: 3425f765692f0b8b9c4931c038fae8d86fe6e383 127.0.0.1:7006 slots: (0 slots) master M: 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001 slots:[0-5460] (5461 slots) master 1 additional replica(s) M: 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002 slots:[5461-8460] (3000 slots) master 1 additional replica(s) S: 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005 slots: (0 slots) slave replicates 07bc00f5b816a612e96ad2fcdc25b4decdc498bd [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [OK] All 16384 slots covered. How many slots do you want to move (from 1 to 16384)?
Here you need to enter the number of slot s you want to allocate. Here we enter 4000,
How many slots do you want to move (from 1 to 16384)? 4000 What is the receiving node ID?
Here, you need to enter the node receiving these slot s, and enter the ID of the target node printed above. Here, enter 3425f76592f0b8b9c4931c038fae8d86fe6e383,
How many slots do you want to move (from 1 to 16384)? 4000 What is the receiving node ID? 3425f765692f0b8b9c4931c038fae8d86fe6e383 Please enter all the source node IDs. Type 'all' to use all the nodes as source nodes for the hash slots. Type 'done' once you entered all the source nodes IDs. Source node #1:
Enter the id of the source node here. If it's all nodes, just enter all directly. If it's one or more nodes, you can enter one by one. Finally, enter done. Here, we just need to separate the upper part of 7000 nodes,
How many slots do you want to move (from 1 to 16384)? 4000 What is the receiving node ID? 3425f765692f0b8b9c4931c038fae8d86fe6e383 Please enter all the source node IDs. Type 'all' to use all the nodes as source nodes for the hash slots. Type 'done' once you entered all the source nodes IDs. Source node #1: 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea Source node #2: done
You will also be confirmed again, and enter yes to wait for the allocation to be completed.
Enter redis cli to view the nodes:
127.0.0.1:7006> CLUSTER NODES 1793ee70d256fc3ab7ab582b20a9da0c8884e683 127.0.0.1:7004@17004 slave 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 0 1557985824187 12 connected 08aa7f83a0e69d441f523a5b2758cf42d7b1fe6d 127.0.0.1:7005@17005 slave 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 0 1557985823000 11 connected 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 127.0.0.1:7000@17000 master - 0 1557985823085 10 connected 12461-16383 07bc00f5b816a612e96ad2fcdc25b4decdc498bd 127.0.0.1:7001@17001 master - 0 1557985823185 11 connected 0-5460 3dc5d7b70542e56f85b0ce74190b4d37e540cdc0 127.0.0.1:7002@17002 master - 0 1557985824586 12 connected 5461-8460 3a5b137a1997d72cdd61fb4cf58de6530a78fbca 127.0.0.1:7003@17003 slave 4c0b7a5b52bf3c4cb61c88f3af7fc73b8db00dea 0 1557985823000 10 connected 3425f765692f0b8b9c4931c038fae8d86fe6e383 127.0.0.1:7006@17006 myself,master - 0 1557985824000 13 connected 8461-12460
There are already allocated slot s on 7006
Add new node as slave
It's easy to add a new node. There's no demonstration here. Here are the main commands:
# Random primary server redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000 --cluster-slave # Specify master server accurately redis-cli --cluster add-node 127.0.0.1:7007 127.0.0.1:7000 --cluster-slave --cluster-master-id 3425f765692f0b8b9c4931c038fae8d86fe6e383
or
redis 127.0.0.1:7007> cluster replicate 3425f765692f0b8b9c4931c038fae8d86fe6e383
Remove node
The main command to delete a node is redis cli -- cluster del node 127.0.0.1:7000 < node id > after del node, the first parameter is the ip of any node in the cluster, and the second parameter is the id of the node to be removed
Note that if you want to delete the primary node, you need to assign the slot s in the primary node first. Otherwise, you cannot delete them, as follows
[root@iZnom30el3gvhxZ cluster]# redis-cli --cluster del-node 127.0.0.1:7000 3425f765692f0b8b9c4931c038fae8d86fe6e383 -a abc Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Removing node 3425f765692f0b8b9c4931c038fae8d86fe6e383 from cluster 127.0.0.1:7000 [ERR] Node 127.0.0.1:7006 is not empty! Reshard data away and try again.
Perform a reset to assign the slot on 7006. Do not show here, and directly post the response of successfully deleting the node:
[root@iZnom30el3gvhxZ cluster]# redis-cli --cluster del-node 127.0.0.1:7000 3425f765692f0b8b9c4931c038fae8d86fe6e383 -a wk123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. >>> Removing node 3425f765692f0b8b9c4931c038fae8d86fe6e383 from cluster 127.0.0.1:7000 >>> Sending CLUSTER FORGET messages to the cluster... >>> SHUTDOWN the node. [root@iZnom30el3gvhxZ cluster]# ps -ef | grep redis root 8522 1 0 10:16 ? 00:00:32 redis-server *:7000 [cluster] root 19854 7831 0 14:04 pts/0 00:00:00 grep --color=auto redis root 26183 1 0 May15 ? 00:01:40 redis-server *:7001 [cluster] root 26190 1 0 May15 ? 00:01:40 redis-server *:7002 [cluster] root 26202 1 0 May15 ? 00:01:29 redis-server *:7003 [cluster] root 26208 1 0 May15 ? 00:01:28 redis-server *:7004 [cluster] root 26215 1 0 May15 ? 00:01:29 redis-server *:7005 [cluster]
7006 node has been removed and is offline.
For more details, please refer to:
Official document of Redis Cluster
Redis Cluster advanced official document