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

This article gives you a detailed introduction to redis highly available clusters. Most of the knowledge points are often used by everyone, so I will share them for you as a reference. Let's follow the editor and have a look.

1, preface

Redis is the cache middleware we use on the largest scale at present. Because of its powerful, efficient and convenient function, it has been widely used.

Redis released 3.0.0 in 2015, with official support for redis cluster. This puts an end to the era when there is no cluster in redis. Before, most of the redis cluster we used were Twemproxy released by twitter and codis developed by Pea Pod. This article will understand and practice redis cluster. Next, I will try to explain it in a familiar and easy-to-understand way.

2Design essentials of Magi Redis Cluster

When redis cluster is designed, it takes into account decentralization and middleware, that is, every node in the cluster is equal and peer-to-peer, and each node saves its own data and the state of the whole cluster. Each node is connected to all other nodes, and these connections remain active, which ensures that we only need to connect to any node in the cluster to get the data of other nodes.

3The principle of redis cluster

We know that each node in the cluster is peer-to-peer and keeps its own data, so how does redis allocate these nodes and data properly?

Instead of using the traditional consistent hash to allocate data, Redis Cluster uses a different way of hash slot to allocate data.

Redis cluster allocates 16384 slot by default. When we set a key, we use the CRC16 algorithm to get the slot we belong to, and then assign the key to the nodes in the hash slot. The specific algorithm is: CRC16 (key)% 16384.

It should be noted that the Redis cluster needs at least 3 nodes, because the voting fault tolerance mechanism requires more than half of the nodes to think that a node is dead, so two nodes cannot form a cluster.

Therefore, we assume that there are three nodes that have been deployed as redis cluster. They are three nodes, which can be three ports on a machine or three different servers. Then 16384 slot are allocated using hash slot, and the slot ranges of the three nodes are as follows:

Node A covers 0-5461; node B covers 5462-10922; node C covers 10923-16383

So, now I want to set up a key, such as my_name:set my_name linux.

According to redis cluster's hash slot algorithm: CRC16 ('my_name') 384 = 2412. Then the storage of this key will be allocated to A.

Similarly, when I connect to any node that wants to get the key of my_name, I will do the same algorithm, and then jump to node An internally to get the data.

The advantage of this hash slot allocation is that it is very clear. For example, the way I want to add a node ID,redis cluster is to take a part of the slot from the front of each node to D. It will look something like this: (I will experiment in the following practice)

Node A covers 1365-5460; node B covers 6827-10922; node C covers 12288-16383; node D covers 0-1364, 5461-6826, and 10923-12287

Similarly, deleting a node is similar, and you can delete it after the move is complete.

So redis cluster is such a shape:

4 the master-slave mode of cluster Redis

In order to ensure the high availability of data, redis cluster adds the master-slave mode. A master node corresponds to one or more slave nodes, the master node provides data access, and the slave node pulls data backup from the master node. When the master node dies, the slave node accesses one to act as the master node, thus ensuring that the cluster will not fail.

In the above example, the cluster has three master nodes of ABC. If none of these three nodes join the slave node, if B dies, we will not be able to access the entire cluster. The slot of An and C is also inaccessible. So when we set up the cluster, we must add slave nodes for each master node, such as this, the cluster includes the master node A _ Magi B _ Magi C, and the slave node A _ 1 ~ B _ 1 ~ C1, then even if B dies, the system can continue to work correctly. Because the B1 node takes the place of the B node, the redis cluster will select the B1 node as the new primary node, and the cluster will continue to provide services correctly. It is important to note that when B is reopened, it becomes the slave node of B1, not the master node again.

If node B and B1 die at the same time, the Redis cluster will not be able to provide services normally. In general, both nodes will not be allowed to die at the same time.

The following figure of the process is shown:

Set up redis high availability cluster

According to the redis cluster internal failover implementation principle, the reids cluster needs at least three nodes, and to ensure the high availability of the cluster, each node needs a slave node, so building a redis cluster requires at least six servers, three masters and three slaves.

The conditions are limited, and it is a test environment, so we create a pseudo-cluster on two machines and launch multiple TCP instances through different redis ports to form a cluster. Of course, the Redis cluster in the actual production environment is the same as here.

Currently, there are two ways to build redis cluster:

1. Build manually, that is, execute the cluster command manually and complete the build process step by step.

2. Build it automatically, even if it is quickly built with the official cluster management tools.

The principle of the two methods is the same, the automatic build mode only encapsulates the redis commands that need to be executed in the manual build mode into the executable program. Automatic construction is recommended in the production environment, which is simple and fast, and is not easy to make mistakes. Both methods will be mentioned in the actual demonstration in this article.

Environment description:

Host 172.16.1.100 (CentOS 7.3), launch three instances 7000Magol 7001Magi 7002; all master hosts BRV 172.16.1.110 (CentOS 7.3), start three instances 8000LQ 8001F8002; all are built manually from one

1, install redis

Host A: [root@redis01-server ~] # tar zxf redis-4.0.14.tar.gz [root@redis01-server ~] # mv redis-4.0.14 / usr/local/redis [root@redis01-server ~] # cd / usr/local/redis/ [root@redis01-server redis] # make & & make install# installation completed Modify the configuration file: [root@redis01-server ~] # vim / usr/local/redis/redis.conf 69 bind 172.16.1.100 # set the ip address of the current redis host 92 port 7000 # set redis's listening port 136daemonize yes # to daemon run redis instance 814 cluster-enabled yes # start cluster mode 822 cluster-config-file nodes-7000.conf # set the current node cluster profile path 828 cluster-node-timeout 5000 # set current connection timeout seconds 672 appendonly yes # enable AOF persistence mode 676 appendfilename "appendonly-7000.aof" # AOF file name B host: [root@redis02-server ~] # tar zxf redis-4.0.14.tar.gz [root@redis02-server ~] # mv redis-4.0.14 / usr/local/redis [root@redis02-server ~] # cd / usr/local/redis [root @ redis02-server redis] # make & & make install [root@redis02-server ~] # vim / usr/local/redis/redis.confbind 172.16.1.110port 8000 daemonize yescluster-enabled yescluster-config-file nodes-8000.confcluster-node-timeout 5000appendonly yesappendfilename "appendonly-8000.aof"

2. According to the above plan, create the directory where the startup configuration files of each node are stored

A mainframe: [root@redis01-server ~] # mkdir / usr/local/redis-cluster [root@redis01-server ~] # cd / usr/local/redis-cluster/ [root@redis01-server redis-cluster] # mkdir {7000cd 7002} B mainframe: [root@redis02-server ~] # mkdir / usr/local/redis-cluster [root@redis02-server ~] # cd / usr/local/redis-cluster/ [root@redis02-server redis-cluster] # mkdir {8000meme 8001mai 8002}

3. Copy the master files to the corresponding directory

Host A: [root@redis01-server ~] # cp / usr/local/redis/redis.conf / usr/local/redis-cluster/7000/ [root@redis01-server ~] # cp / usr/local/redis/redis.conf / usr/local/redis-cluster/7001/ [root@redis01-server ~] # cp / usr/local/redis/redis.conf / usr/local/redis-cluster/7002/B host: [root@redis02-server ~] # cp / usr/local/redis / redis.conf / usr/local/redis-cluster/8000/ [root@redis02-server ~] # cp / usr/local/redis/redis.conf / usr/local/redis-cluster/8001/ [root@redis02-server ~] # cp / usr/local/redis/redis.conf / usr/local/redis-cluster/8002/# modify the respective listening TCP port numbers: host A: [root@redis01-server ~] # sed-I "7000Comp7000Compg" / Usr/local/redis-cluster/7001/redis.conf [root@redis01-server ~] # sed-I "s usr/local/redis-cluster/7001/redis.conf [root@redis02-server ~] # sed-I" s 7000lash g "/ usr/local/redis-cluster/7002/redis.conf B mainframe: [root@redis02-server ~] # sed-I" s 8000lash g "/ usr/local/redis-cluster/8001/redis.conf [root@redis02-server ~] # sed-I" sqqqq8000x8000xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

4. Start the reids service

Host A: [root@redis01-server ~] # ln-s / usr/local/bin/redis-server / usr/local/sbin/ [root@redis01-server ~] # redis-server / usr/local/redis-cluster/7000/redis.conf [root@redis01-server ~] # redis-server / usr/local/redis-cluster/7001/redis.conf [root@redis01-server ~] # redis-server / usr/local/redis-cluster/7002/redis.conf # ensure each node Normal operation of the service: [root@redis01-server ~] # ps-ef | grep redisroot 19595 10 04:55? 00:00:00 redis-server 172.16.1.100 grep redisroot 172.16.1.100 redis-server 172.16.1.100 redis-server 172.16.1.100 redis-server 19602 04:56? 00:00:00 redis-server 172.16.1.100 ef 7001 [cluster] root 19607 04:56? 00:00:00 redis-server 172.16 .1.100 cluster 7002 [cluster] root 19612 2420 0 04:58 pts/0 00:00:00 grep-- color=auto redisB host: [root@redis02-server ~] # ln-s / usr/local/bin/redis-server / usr/local/sbin/ [root@redis02-server ~] # redis-server / usr/local/redis-cluster/8000/redis.conf [root@redis02-server ~] # redis-server / usr/local/redis-cluster/8001/redis.conf [root @ redis02-server ~] # redis-server / usr/local/redis-cluster/8002/redis.conf [root@redis02-server ~] # ps-ef | grep redisroot 18485 10 00:17? 00:00:00 redis-server 172.16.1.110 cluster 8000 [cluster] root 18490 10 00:17? 00:00:00 redis-server 172.16.1.110 usr/local/redis-cluster/8002/redis.conf 8001 [cluster] root 18495 100: 17? 00:00:00 redis-server 172.16.1.110 root 18501 1421 0 00:19 pts/0 00:00:00 grep-- color=auto redis

5, node handshake

Although cluster support is enabled for each of the above 6 nodes, they do not trust each other or are not related by default. Node handshake is to create links between nodes (each node is connected to other nodes) to form a complete network, that is, cluster.

The command for the node to shake hands is as follows:

Cluster meet ip port

The six nodes we created can be connected to Node A through redis-cli to execute the following five sets of commands to complete the handshake:

Note: the firewall: systemctl stop firewalld of each host in the cluster needs to be turned off, otherwise the handshake cannot be completed.

[root@redis01-server] # redis-cli-h 172.16.1.100-p 7000172.16.1.100 7001OK172.16.1.100:7000 > cluster meet 172.16.1.100 7001OK172.16.1.100:7000 > cluster meet 172.16.1.100 7002OK172.16.1.100:7000 > cluster meet 172.16.1.110 8000OK172.16.1.100:7000 > cluster meet 172.16.1.110 8001OK172.16.1.100:7000 > cluster meet 172.16.1.110 8002OK# View handshake Whether it is normal or not: 172.16.1.100 cluster nodes060a11f6985df66e4b9cf596355bbe334f843587 7000 > cluster nodes060a11f6985df66e4b9cf596355bbe334f843587 172.16.1.100 cluster nodes060a11f6985df66e4b9cf596355bbe334f843587 7001V 17001 master-0 1584155029000 1 connected2fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110 cluster nodes060a11f6985df66e4b9cf596355bbe334f843587 8002 "18002 master-01584155029000 5 connected6d3ac8cf0dc3c8400d2df8d0559fbe8bdce0c34d 172.16.1.110Vista 8000mm 18000 master-01584155029243 connectedcc3b16e067bf1ce9978c13870f0e1d538102a733 172.16.1.110Race 8001mm 18001 master-01584155030000 0 connected0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 172.16.1.100 7000mm 17000 myself Master-0 1584155028000 2 connectedc0fefd1442b3fa4e41eb6fba5073dcc1427ca812 172.16.1.100 master 7002 connected-01584155030249 4

As you can see, all the nodes in the cluster have established links, and since then, the node handshake has been completed.

# although the node has established a link, the redis cluster is not online yet. Execute the cluster info command to check the current running status of the cluster:

172.16.1.100 cluster infocluster_state:fail 7000 > cluster infocluster_state:fail # indicates that the current cluster is offline cluster_slots_assigned:0 # 0 means that all slots are not currently assigned to the node cluster_slots_ok:0cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:0cluster_current_epoch:5cluster_my_epoch:2cluster_stats_messages_ping_sent:612cluster_stats_messages_pong_sent:627cluster_ Stats_messages_meet_sent:10cluster_stats_messages_sent:1249

6, assign slots

Only by assigning slot to all master nodes in the cluster can the cluster go online normally. The command for assigning slots is as follows:

Cluster addslots slot [slot...]

# according to pre-planning, it is necessary to manually distribute 16384 hash slots equally to the primary node A _ Magi B ~ ~ C using the cluster addslots command.

[root@redis01-server ~] # redis-cli-h 172.16.1.100-p 7000 cluster addslots {0.5461} OK [root@redis01-server ~] # redis-cli-h 172.16.1.100-p 7001 cluster addslots {5462... 10922} OK [root@redis01-server ~] # redis-cli-h 172.16.1.100-p 7002 cluster addslots {10923. 16383} OK

After the slot allocation is completed, you can view the status of the current cluster again:

[root@redis01-server] # redis-cli-h 172.16.1.100-p 7000 cluster infocluster_state:ok cluster_slots_assigned:16384cluster_slots_ok:16384cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:3cluster_current_epoch:5cluster_my_epoch:2cluster_stats_messages_ping_sent:2015cluster_stats_messages_pong_sent:2308cluster_stats_messages_meet_sent:10cluster_stats_messages_sent:4333cluster_stats_messages_ Ping_received:2308cluster_stats_messages_pong_received:2007cluster_stats_messages_received:4315

Cluster_state:ok proves that the redis cluster has been launched successfully.

# to delete a distribution slot, you can execute the cluster delslots command, for example:

[root@redis01-server] # redis-cli-h 172.16.1.100-p 7000 cluster delslots {10923. 16383}

# check the slot allocation: [root@redis01-server ~] # redis-cli-h 172.16.1.100-p 7000 cluster nodes060a11f6985df66e4b9cf596355bbe334f843587 172.16.1.100Vera 700114001 master-015841563880001 connected 5462-109222fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110root@redis01-server 8002mm 18002 master-01584156387060 5 connected6d3ac8cf0dc3c8400d2df8d0559fbe8bdce0c34d 172.16.1.110Rod 8000mm 18000 master-01584156386056 3 connectedcc3b16e067bf1ce9978c13870f0e1d538102a733 172.16.1.110Rang800118001 master-01584156387000 0 connected0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 172.16.1.100Race 7000,000 myself Master-0 1584156387000 2 connected 0-5461c0fefd1442b3fa4e41eb6fba5073dcc1427ca812 172.16.1.100 5461c0fefd1442b3fa4e41eb6fba5073dcc1427ca812 7002mm 17002 master-01584156386000 4 connected 10923-16383

You can see that the slots of the three master nodes have been allocated, but there are still three slave nodes that are not in use. If one master node fails at this time, then the whole cluster will fail, so we need to configure the master node for the slave node to achieve high availability.

7, master-slave replication

The cluster replication command is as follows: cluster replicate node-id

1) Connect any node in the cluster to get the node-id of all master nodes

[root@redis01-server] # redis-cli-h 172.16.1.110-p 8000 cluster nodes2fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110 cluster nodes2fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110 master-0 1584157179543 5 connectedc0fefd1442b3fa4e41eb6fba5073dcc1427ca812 172.16.1.100 root@redis01-server 7002 "17002 master-01584157179946 4 connected 10923-163836d3ac8cf0dc3c8400d2df8d0559fbe8bdce0c34d 172.16.1.11018000 myself Master-0 1584157179000 3 connected060a11f6985df66e4b9cf596355bbe334f843587 172.16.1.100 master 7001mm 17001 master-01584157180952 1 connected 5462-10922cc3b16e067bf1ce9978c13870f0e1d538102a733 172.16.1.110 connected 8001O 18001 master-01584157180549 0 connected0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 172.16.1.100For 7000mm 17000 master-015841571795442 connected0-5461

2) execute the following three sets of commands to specify its master node for the slave node, so that the cluster can automatically complete the master-slave replication.

[root@redis02-server] # redis-cli-h 172.16.1.110-p 8000 cluster replicate 0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fdOK [root@redis02-server] # redis-cli-h 172.16.1.110-p 8001 cluster replicate 060a11f6985df66e4b9cf596355bbe334f843587OK [root@redis02-server] # redis-cli-h 172.16.1.110-p 8002 cluster replicate c0fefd1442b3fa4e41eb6fba5073dcc1427ca812OK

3) View the replication status information of each node in the cluster:

[root@redis02-server ~] # redis-cli-h 172.16.1.110-p 8000 cluster nodes2fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110 cluster nodes2fb26d79f703f9fbd8841e4ee93ea88f7df5dad9 172.16.1.110 slave c0fefd1442b3fa4e41eb6fba5073dcc1427ca812 01584157699631 5 connectedc0fefd1442b3fa4e41eb6fba5073dcc1427ca812 172.16.1.100 root@redis02-server 7002 "17002 master-01584157700437 4 connected 10923-163836d3ac8cf0dc3c8400d2df8d0559fbe8bdce0c34d 172.16.1.1108000mm 18000 myself Slave 0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 0 1584157699000 3 connected060a11f6985df66e4b9cf596355bbe334f843587 172.16.1.100 slave 0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 7001n 17001 master-01584157701442 1 connected 5462-10922cc3b16e067bf1ce9978c13870f0e1d538102a733 172.16.1.110 connected 8001O 18001 slave 060a11f6985df66e4b9cf596355bbe334f843587 01584157699932 1 connected0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 172.16.1.100 slave 0f74b9e2d07e159fdc0fc1edffd3d0b305adc2fd 7000U 17000 master-01584157700000 2 connected0-5461

You can see that all the slave nodes act as backup nodes for the corresponding master node, and so far, a redis cluster has been successfully built manually.

Summarize the key steps of building a redis cluster manually:

1. Install redis2 on each node, modify the configuration file, turn on cluster mode 3, start each node redis service 4, node handshake 5, assign slot 6 to master node, and establish replication relationship between master and slave nodes.

Recommended blog posts:

The difference between redis's rdb and aof persistence: https://www.cnblogs.com/shizhengwen/p/9283973.html

Second, automatic construction

After Redis 3.0, a cluster management tool, redis-trib.rb, has been officially released, which is integrated in the src directory of the Redis source package. It encapsulates the cluster commands provided by redis and is easy to use and convenient.

Environment description:

Host ARV 172.16.1.100 (CentOS 7.3), launch three instances 7000Magol 7001Magi 7002; mainframe BRV 172.16.1.110 (CentOS 7.3), launch three instances 8000focus 8001LI 8002

1. Perform steps 1-4 of "manually building redis" above (to start redis (to ensure the normal operation of the redis service), and turn off the firewall.

2. Build cluster management tools

Redis-trib.rb was developed by the Redis author in the Ruby language, so you need to install the Ruby environment on the machine before using the tool.

Note that this tool has been integrated into redis-cli since Redis version 5.0 and is provided with the-- cluster parameter, where the create command can be used to create a cluster.

1) install Ruby environment and other dependencies (two hosts) [root@redis-01 ~] # yum-y install ruby ruby-devel rubygems rpm-build openssl openssl-devel# confirm installation version: [root@redis-01 ~] # ruby- vruby 2.0.0p648 (2015-12-16) [x86_64-linux]

2) use redis-trib.rb script to build a cluster

[root@redis-01 ~] # ln-s / usr/local/redis/src/redis-trib.rb / usr/local/sbin/ [root @ redis-01 ~] # redis-trib.rb create-- replicas 1 172.16.1.100VRV 7000 172.16.1.100RU 7001 172.16.1.100RU 7002 172.16.1.110RV 8000 172.16.1.110Rod 8001 172.16.1.1Rod 800 commands are used here -- the replicas 1 parameter means that a slave node is created for each master node (randomly assigned). The other parameters are the address collection of the instance / usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require': cannot load such file-- redis (LoadError) from / usr/share/rubygems/rubygems/core_ext/kernel_require.rb:55:in `require' from / usr/local/sbin/redis-trib.rb:25:in `'.

The above error report requires the gem package of redis to install the interface of ruby and redis, and install the gem package. The URL: https://rubygems.org/gems/redis/ chooses the corresponding version to download. Select version 3.3.0 here:

[root@redis-01 ~] # gem install-l redis-3.3.0.gem Successfully installed redis-3.3.0Parsing documentation for redis-3.3.0Installing ri documentation for redis-3.3.01 gem installed

# recreate the cluster

[root@redis-01] # redis-trib.rb create-- replicas 1 172.16.1.100 replicas 7000 172.16.1.100 root@redis-01 7002 172.16.1.100 root@redis-01 7002 172.16.1.110 root@redis-01 8000 172.16.1.110 replicas 8001 172.16.1.110Rod 8002 > > Creating cluster > Performing hash slots allocation on 6 nodes...Using 3 masters:172.16.1.100:7000172.16.1.110:8000172.16.1.100:7001Adding replica 172.16.1 .110slots:0 8002 to 172.16.1.100:7000Adding replica 172.16.1.100 to 172.16.1.110:8000Adding replica 172.16.1.110V 8001 to 172.16.1.100V 7001M: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100V 7000 slots:0-5460 (5461 slots) masterM: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100V 7001 slots:10923-16383 (5461 slots) masterS: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100V 7002 replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1. 110 slots:5461 8000 slots:5461-10922 (5462 slots) masterS: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 948421116dd1859002c78a2df0b9845bdc7db631 8001 replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cS: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 948421116dd1859002c78a2df0b9845bdc7db631 8002 replicates 8613a457f8009aaf784df0ac6d7039034b16b6a6Can 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 clusterWaiting for the cluster to join.. > > Performing Cluster Check (using node 172.16.1.100V7 000) M: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 master 7000 slots:0-5460 (5461 slots) master 1 additional replica (s) S: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110yes 8002 slots: (0 slots) slave replicates 8613a457f8009aaf784df0ac6d7039034b16b6a6S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 Vol 8001 slots : (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 slots 8000 slots:5461-10922 (5462 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 5721b77733b1809449c6fc5806f38f1cacb1de8c 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M 7001 slots:10923-16383 (5461 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.

Redis-trib will prompt you what configuration has been made, enter yes to accept, and the cluster will be configured and joined, meaning that the instances will start after communicating with each other.

At this point, the cluster can be said to be built, a command to solve, can be said to be very convenient.

3. Test cluster

1) Test the status of the cluster:

[root@redis-01 ~] # redis-trib.rb check 172.16.1.100 Performing Cluster Check 7000) M: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 slots 7000 slots:0-5460 (5461 slots) master 1 additional replica (s) S: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 slots 8002 slots: (0 slots) slave replicates 8613a457f8009aaf784df0ac6d7039034b16b6a6S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 slots 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 slots:5461 8000 slots:5461-10922 (5462 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 additional replica 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 master 7001 slots:10923-16383 (5461 slots) master 1 additional replica (s)

You can see that there are three master nodes (M), which are 7000pr 8000je 7001pr 3 slave nodes (S), respectively 7002pr 8001pr 8002. Each node has a successful connection state.

2) Test the connection cluster

The cluster has been successfully built; according to the characteristics of redis cluster, it is decentralized and each node is peer-to-peer, so you can get and set data from any node you connect to, and then test:

[root@redis-01 ~] # redis-cli-h 172.16.1.100-p 7000-c / / Cluster mode needs to add-c parameter 172.16.1.100 set my_name linux 7000 > set my_name linux / / set a value-> Redirected to slot [12803] located at 172.16.1.100 set my_name linux 7001 / / as mentioned earlier, when allocating key, it uses the CRC16 ('my_name') 384 algorithm to calculate which node to put the key to. Here 12803 is assigned, so slot is assigned to 7001 (range: 10923-16383) on this node OK172.16.1.100:7001 > get my_name / / to get the data value "linux"

The method adopted by redis cluster is very straightforward. After creating the key, it jumps directly to 7001 nodes instead of its own 7000 nodes. Now we connect the 8002 slave node:

[root@redis-01 ~] # redis-cli-h 172.16.1.110-p 8002-c 172.16.1.110 located at 8002 > get my_name- > Redirected to slot [12803] located at 172.16.1.100 get my_name- 7001 "linux" / / also gets the value of key (my_name), which also jumps to 7001 and returns the data value

3) Test the high availability of the cluster

At present, my redis cluster has three master nodes (7000mag8000recover7001) for data storage and reading, and three slave nodes (7002meme8001j8002) responsible for synchronizing the data of the master node to its own node, so let's take a look at the appendonly.aof content of the slave node (because the value just created is assigned to 7001 nodes, and the slave node of the 7001 master node is 8001, so let's look at the aof file of 8001)

[root@redis-02 ~] # cat appendonly-8001.aof * 2 $6SELECT$10*3 $3set$7my_name$5linux

You can see that the data is indeed synchronized from the primary node.

Note: the dump.rdb file or appendonly.aof file will be generated in the directory where your redis starts. If you want to customize the path, you can modify the configuration file:

263 dir. / # change the relative path to the absolute path

# below, we simulate the failure of one of the master master servers:

[root@redis-01 ~] # ps-ef | grep redisroot 5598 10 01:02? 00:00:06 redis-server 172.16.1.100 grep redisroot 5603 01:02? 00:00:06 redis-server 172.16.1.100 ef 172.16.1.100 ef 7001 [cluster] root 5608 10 01:02? 00:00:06 redis-server 172.16.1.100 : 7002 [cluster] root 19735 2242 0 03:32 pts/0 00:00:00 grep-- color=auto reds [root @ redis-01 ~] # kill 5598

# Test the status of the cluster:

[root@redis-01 ~] # redis-trib.rb check 172.16.1.100 ERR 7000 [ERR] Sorry Can't connect to node 172.16.1.100: 7000 [root @ redis-01 ~] # redis-trib.rb check 172.16.1.100 slots 7001 > Performing Cluster Check (using node 172.16.1.100 slots 7001) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 slots 7001 slots:10923-16383 (5461 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 1007002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 Slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 master 8000 slots:5461-10922 (5462 slots) master 1 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 master 8002 slots:0-5460 (5461 slots) master 0 additional replica (s)

As you can see from the above results, when the 7000 master node dies, then there is only 8002 of the 7000 slave nodes, so 8002 will be elected as the master node. And the original data on the 7000 nodes will not be lost, but will be transferred to the 8002 nodes, and when the user gets the data again, it will be obtained from 8002.

Since the 7000-node server is down for some reason, what role will 7000 nodes play in the cluster when we resolve the problem and re-join the 7000 nodes in the cluster?

[root@redis-01 ~] # redis-server / usr/local/redis-cluster/7000/redis.conf [root@redis-01 ~] # ps-ef | grep redisroot 5603 10 01:02? 00:00:08 redis-server 172.16.1.100 usr/local/redis-cluster/7000/redis.conf 172.16.1.100 usr/local/redis-cluster/7000/redis.conf 7001 [cluster] root 5608 10 01:02? 00:00:08 redis-server 172.16.1.100 usr/local/redis-cluster/7000/redis.conf 7002 [cluster] root 19771 10 03:50? 00:00:00 redis-server 172.16.1.100 root 7000 [cluster] root 19789 2242 0 03:51 pts/0 00:00:00 grep-- color=auto redis# check the status of the cluster: [root@redis-01 ~] # redis-trib.rb check 172.16.1.100 root 7001 > > Performing Cluster Check (using node 172.16.1.100 root 7001) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 slots:10923 -16383 (5461 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 slots 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 slots 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 master 8000 slots:5461-10922 (5462 slots) master 1 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 d161ab43746405c2b517e3ffc98321956431191c 8002 slots:0-5460 (5461 slots) master 1 additional replica (s) S: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 8613a457f8009aaf784df0ac6d7039034b16b6a6 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9

You can see that 7000 nodes have successfully joined the cluster, but it acts as a 8002 slave node.

4. Add new nodes to the cluster

Adding a new node can be divided into two situations: 1 as a master node and 2 as a slave node. Let's practice it respectively.

1, join as the primary node

1) create a new 7003 node and join as a new master node:

[root@redis-01 ~] # mkdir / usr/local/redis-cluster/7003 [root@redis-01 ~] # cd / usr/local/redis-cluster/ [root@redis-01 redis-cluster] # cp 7000/redis.conf 7003 / [root @ redis-01 redis-cluster] # sed-I "s 7003/redis.conf # launch the 7003 redis service: [root@redis-01 ~] # redis-server / usr/local/redis-cluster/7003/redis.conf [root@redis-01 ~] # ps-ef | grep redisroot 5603 10 01:02? 00:00:09 redis-server 172.16.1.100 01:02? 00:00:09 redis-server 172.16.1.100 ps 7002 [cluster] root 19771 03:50? 00:00:00 redis-server 172.16.1.100: 7000 [cluster] root 19842 10 04:06? 00:00:00 redis-server 172.16.1.100 cluster root 19847 2242 0 04:06 pts/0 00:00:00 grep-- color=auto redis

2) add 7003 nodes to the cluster

[root@redis-01 ~] # redis-trib.rb add-node 172.16.1.100 add-node 7003 172.16.1.100 add-node is the join instruction. The preceding indicates the newly joined node, and the latter indicates a node of the joined cluster, which is used to identify which cluster it is. In theory, either can > Adding node 172.16.1.100 Adding node 7003 to cluster 172.16.1.100 Performing Cluster Check 7000) S: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 slots 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110Performing Cluster Check 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM 8002 slots:0-5460 (5461 slots) master 1 additional replica (s) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 master 7001 slots:10923-16383 (5461 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 master 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 slots 8000 slots:5461-10922 master 1 additional replica (s) [OK] All nodes agree about slots configuration. > > Check for open slots... > > Check slots coverage... [OK] All 16384 slots covered. > Send CLUSTER MEET to node 172.16.1.100:7003 to make it join the cluster. [OK] New node added correctly.

Indicates that the new node is connected successfully and has joined the cluster. Let's check again:

[root@redis-01 ~] # redis-trib.rb check 172.16.1.100 slots:0 7003 > Performing Cluster Check (using node 172.16.1.100 Performing Cluster Check 7003) M: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 Performing Cluster Check 7003 slots: (0 slots) master 0 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110Performing Cluster Check 8002 slots:0-5460 (5461 slots) master 1 additional replica (s) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 slots:0 7001 slots:10923-16383 (5461 slots) ) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 slots 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 slots 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cS: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 slots 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 slots 8000 slots:5461-10922 (5462 slots) master 1 additional replica (s)

You can see that there are seven nodes in the cluster, and 7003 is also a master node, but you have noticed that the slots of 7003 nodes is 0; that is, although it is now the master node, it does not have any slot assigned to it, so it is not responsible for data access yet. Therefore, we need to manually refragment and migrate the cluster.

3) migrate slot nodes

# this command is used to migrate slot nodes. The 172.16.1.100 slot 7000 indicates which cluster it is, and any port node can: [root@redis-01 ~] # redis-trib.rb reshard 172.16.1.100 How many slots do you want to move 7000 How many slots do you want to move (from 1 to 16384)? # after entering, it prompts us how many slot we need to migrate to 7003. We can calculate: 16384Comp4 = 4096, that is to say In order to load balance, we need to move 4096 slots to the 7003 How many slots do you want to move (from 1 to 16384)? 4096What is the receiving node ID? # it also prompts us, what is the node ID accepted, and 7003 of the id we can get What is the receiving node ID from the above information? Edd51c8389ba069d49fe54c24c535716ce06e62bPlease 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:

# then redis-trib will ask you the source node (source node) of the resharding, that is, from which node you want to take out 4096 hash slots and move these slots above the 7003 nodes. If we are not going to take out a specified number of hash slots from a specific node, we can type all into redis-trib, so that all master nodes in the cluster will become source nodes, and redis-trib will take out some hash slots from each source node, gather up 4096, and then move to 7003 nodes, so we enter all:

Source node # 1:all # will then start the migration and will ask you if you are sure: Do you want to proceed with the proposed reshard plan (yes/no)? Yes

After entering yes enter, redis-trib will officially start the resharding operation, moving the specified hash slots from the source node to the 7003 nodes one by one. After the migration, let's check:

[root@redis-01] # redis-trib.rb check 172.16.1.100 using node 7000 > > Performing Cluster Check (8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 Performing Cluster Check 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM 7003 slots:0-1364 5461-6826561-12287 (4096 slots) master 0 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 master 8002 slots:1365-5460 (4096 slots) master 1 additional replica (s) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 slots 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110000 slots:6827-10922 (4096 slots) master 1 additional replica (s)

Let's focus on 7003: "0-1364 slots 5461-6826 10923-12287 (4096)."

These slot that were originally on other nodes are migrated to 7003. It turns out that it is only an interval movement, not a convergence of the overall movement, let's verify whether there is data on the 7003 nodes:

[root@redis-01] # redis-cli-h 172.16.1.100-p 7003-c172.16.1.100 get my_name- > Redirected to slot [12803] located at 172.16.1.100 get my_name- 7001 "linux" / / proves that the 7003 master node has been working properly.

2, join as a slave node

1) create a new 8003 node as the slave node of 7003. The steps are similar. After starting the redis service of 8003, we add it to the slave node in the cluster:

/ using the add-node-slave-- master-id command, master-id points to which node you need to select as the master node for the new slave node, and 172.16.1.110 master-id 8003 indicates that you need to join the new slave node Finally, select any node in the current cluster [root@redis-02 ~] # redis-trib.rb add-node-- slave-- master-id edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.110 slave 8003 172.16.1.110 master-id edd51c8389ba069d49fe54c24c535716ce06e62b 8000 > > Adding node 172.16.1.110 slave 8003 to cluster 172.16.1.110 Adding node 8000 > > Performing Cluster Check (using node 172.16.1.110slave 8000) M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 slots:6827-10922 (4096 slots) master 1 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 slots:1365 8002 slots:1365-5460 (4096 slots) master 1 additional replica (s) M: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 slots:0-136 master 0923-12287 (4096 slots) master 0 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 master 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 slots:12288-16383 (4096 slots) ) master 1 additional replica (s) S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110 slots 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cS: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 All nodes agree about slots configuration 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9 [OK] All nodes agree about slots configuration. > > Check for open slots... > Check slots coverage... [OK] All 16384 slots covered. > > Send CLUSTER MEET to node 172.16.1.110 slots 8003 to make it join the cluster.Waiting for the cluster to join. > > Configure Node as replica of 172.16.1.100:7003. [OK] New node added correctly.

The above hint says that 7003 has been selected as the master node and has been successful. Let's check the status of each node in the cluster:

[root@redis-02] # redis-trib.rb check 172.16.1.110 master 8003 > Performing Cluster Check (using node 172.16.1.110 master 8003) S: 4ffabff843d32364fc506f3445980f5a04aa4292 172.16.1.110 master 8003 slots: (0 slots) slave replicates edd51c8389ba069d49fe54c24c535716ce06e62bM: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110 master 8000 slots:6827-10922 (4096 slots) master 1 additional replica (s) S: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 master 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172 .16.1.110: 8002 slots:1365-5460 (4096 slots) master 1 additional replica (s) M: 5721b77733b1809449c6fc5806f38f1cacb1de8c 172.16.1.100 master 7001 slots:12288-16383 (4096 slots) master 1 additional replica (s) M: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 slots:0-136 master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 d161ab43746405c2b517e3ffc98321956431191c 7002 slots: (0 slots) slave replicates 4debd0b5743826d203d1af777824eb1b83105d21S: 948421116dd1859002c78a2df0b9845bdc7db631 172.16. 1.110slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8c# 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8c# verifies whether the slave node can communicate in the cluster: [root@redis-02 ~] # redis-cli-h 172.16.1.110-p 8003-c172.16.1.110 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8c# 8003 > get my_name- > Redirected to slot [12803] located at 172.16.1.100 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8c# 7001 "linux" / / proves that the slave node joined successfully And it works normally. 5. Remove nodes from the cluster.

If nodes are added to the redis cluster, there must be a need to remove nodes. Redis cluster also supports the ability to remove nodes, which is also the use of redis-trib.rb.

Syntax format: redis-trib del-node ip: Port ``

1, remove the primary node

/ / unlike the newly added node, remove the node-id that requires the node. So we try to remove the 8000 master node: [root@redis-02 ~] # redis-trib.rb del-node 172.16.1.110 ERR 8000 4debd0b5743826d203d1af777824eb1b83105d21 > Removing node 4debd0b5743826d203d1af777824eb1b83105d21 from cluster 172.16.1.110 ERR 8000 [ERR] 172.16.1.110 ERR 8000 is not empty! Reshard data away and try again.

An error has been reported. It prompts us that since there is already data in the 8000 node, it cannot be removed, so its data should be transferred out first, that is, it has to be sliced again, so the sharding method after adding the new node is the same as above. Slice again:

[root@redis-01] # redis-trib.rb reshard 172.16.1.100 root@redis-01 700 indicates how many slots we want to divide. Since there are 4096 slots on 8000, fill in 4096How many slots do you want to move (from 1 to 16384)? 409 please prompt us which id we need to move to, then choose to move to the 8002 master node What is the receiving node ID? 3cc268dfbb918a99159900643b318ec87ba03ad9Please 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 # 1Source node # here is the key. Which node does he want us to transfer data from to 8002, because we are going to remove 8000, so we have to fill in the id of 8000 nodes: Source node # 1:4debd0b5743826d203d1af777824eb1b83105d21Source node # 2:done / / enter the done command to end the Do you want to proceed with the proposed reshard plan (yes/no)? Yes / / enter yes

Ok, so that the original data in the 8000 master node is migrated successfully.

Let's check the status of the node:

[root@redis-01 ~] # redis-trib.rb check 172.16.1.100 using node 7000 > Performing Cluster Check (172.16.1.100 using node 7000) S: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100 slots 7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9S: 4ffabff843d32364fc506f3445980f5a04aa4292 172.16.1.110 slave replicates edd51c8389ba069d49fe54c24c535716ce06e62bS 8003 slots: (0 slots) slave replicates edd51c8389ba069d49fe54c24c535716ce06e62bS: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.10 slots 8001 slots: (0 slots) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100: 7003 slots:0-1364 master 5461-6826 master 10923-12287 (4096 slots) master 1 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 master 8002 slots:1365-5460 slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.100 slots 7001 slots:12288-16383 (4096 slots) master 1 additional replica (s) S: d161ab43746405c2b517e3ffc98321956431191c 172.16.1.100 d161ab43746405c2b517e3ffc98321956431191c 7002 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9M: 4debd0b5743826d203d1af777824eb1b83105d21 172.16.1.110Rod 8000 Slots: (0 slots) master 0 additional replica (s) / / you can see that the slots on the 8000 node is already 0 And the slots on it has been migrated to 8002 nodes.

# now remove the 8000 master node again:

[root@redis-02 ~] # redis-trib.rb del-node 172.16.1.110 4debd0b5743826d203d1af777824eb1b83105d21 8000 4debd0b5743826d203d1af777824eb1b83105d21 > > Removing node 4debd0b5743826d203d1af777824eb1b83105d21 from cluster 172.16.1.110 4debd0b5743826d203d1af777824eb1b83105d21 8000 > > Sending CLUSTER FORGET messages to the cluster... > SHUTDOWN the node.[ root @ redis-02 ~] # redis-trib.rb check 172.16.1.110 4debd0b5743826d203d1af777824eb1b83105d21 8000 [ERR] Sorry, can't connect to node 172.16.1.110 Removing node 4debd0b5743826d203d1af777824eb1b83105d21 from cluster 8000

Ok, the master node was removed successfully.

2, remove from the node

It is much easier to remove a slave node, because we do not need to consider data migration, we remove 7002 from the node:

[root@redis-02 ~] # redis-trib.rb del-node 172.16.1.100 d161ab43746405c2b517e3ffc98321956431191c 7002 > > Removing node d161ab43746405c2b517e3ffc98321956431191c from cluster 172.16.1.100 d161ab43746405c2b517e3ffc98321956431191c 7002 > Sending CLUSTER FORGET messages to the cluster... > SHUTDOWN the node.// indicates that 7002 has been successfully removed from the node. [root@redis-02 ~] # redis-trib.rb check 172.16.1.100Veg7000 / / check the status information of the current cluster > Performing Cluster Check (using node 172.16.1.100Veg7000) S: 8613a457f8009aaf784df0ac6d7039034b16b6a6 172.16.1.100Veg7000 slots: (0 slots) slave replicates 3cc268dfbb918a99159900643b318ec87ba03ad9S: 4ffabff843d32364fc506f3445980f5a04aa4292 172.16.1.110using node 8003 slots: (0 slots) slave replicates edd51c8389ba069d49fe54c24c535716ce06e62bS: 948421116dd1859002c78a2df0b9845bdc7db631 172.16.1.110Rich 8001 slots: (0 slots) ) slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM: edd51c8389ba069d49fe54c24c535716ce06e62b 172.16.1.100 slave replicates 5721b77733b1809449c6fc5806f38f1cacb1de8cM 7003 slots:0-1364 master 5461-6826 5721b77733b1809449c6fc5806f38f1cacb1de8c 10923-12287 (4096 slots) master 1 additional replica (s) M: 3cc268dfbb918a99159900643b318ec87ba03ad9 172.16.1.110 additional replica 8002 slots:1365-5460 Check slots:12288-16383 (4096 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.

These are the details of the redis high availability cluster. Have you learned anything after reading it? If you want to know more about it, you are welcome to follow the industry information!

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.