Table of contents
4. How does redis cluster allocate these six nodes?
1. What is a cluster
- Redis cluster (including many small clusters) realizes the horizontal expansion of Redis, that is, starts N redis nodes, distributes and stores the entire database in these N nodes, and each node stores 1/N of the total data, that is, a small cluster Store 1/N data, and each small cluster maintains its own 1/N data.
- Redis cluster provides a certain degree of availability (availability) through partition: Even if some nodes in the cluster fail or cannot communicate, the cluster can continue to process command requests.
- The characteristics of the redis cluster in this mode are: divide and conquer, fragmentation.
2. Why use
The capacity is not enough, how to expand redis?
How does redis allocate concurrent write operations?
In addition, master-slave mode, pass the torch mode, host downtime, resulting in changes in the ip address, the configuration in the application needs to modify the corresponding host address, port and other information.
It was solved by proxy host before, but a solution is provided in redis3.0. It is a decentralized cluster configuration.
3. Cluster connection
- Log in in normal mode: you may directly enter the read host, and when storing data, there will be a MOVED redirection operation, so you should log in in cluster mode.
- Cluster login: redis-cli -c -p 6379 Use the cluster policy to connect, and the setting data will be automatically switched to the corresponding write host.
4. How does redis cluster allocate these six nodes?
A cluster must have at least three master nodes.
Option --cluster-replicas 1 : Indicates that we want to create a slave node for each master node in the cluster.
The allocation principle tries to ensure that each master database runs on a different IP address, and each slave database and master database are not on the same IP address.
5. Cluster construction:
1) Create 6 different redis nodes through the ./install_server.sh execution file under the utils path in redis, and the port numbers are 6379, 6380, 6381, 8362, 6383, 6384
2) If each node originally stored data, first clear the data files of each node. Delete all the files in the 6 folders.
Empty the data directory. Delete all files under the Redis data directory. Use the command: rm -rf /path/to/redis/data/*
3) Modify the configuration files of 6 redis nodes
In the /etc/redis file, find the configuration file corresponding to each port number:
For example, the modified content is as follows:
bind 0.0.0.0
port 6380 # Set to the corresponding service-specific port number
daemonize yes
dbfilename "dump6380.rdb" # Set to the corresponding service-specific name
appendonly yes
cluster-enabled yes
cluster-config-file nodes- 6380.conf # set to the corresponding service exclusive
4) Start six nodes
[root@bogon src]# ./redis-server /etc/redis/6379.conf
[root@bogon src]# ./redis-server /etc/redis/6380.conf
[root@bogon src]# ./redis-server /etc/redis/6381.conf
[root@bogon src]# ./redis-server /etc/redis/6382.conf
[root@bogon src]# ./redis-server /etc/redis/6383.conf
[root@bogon src]# ./redis-server /etc/redis/6384.conf5) Check whether each node starts successfully
[root@bogon src]# ps -ef | grep redis
root 3889 1 0 09:56 ? 00:00:03 ./redis-server 0.0.0.0:6379 [cluster]
root 3895 1 0 09:56 ? 00:00:03 ./redis-server 0.0.0.0:6380 [cluster]
root 3901 1 0 09:57 ? 00:00:03 ./redis-server 0.0.0.0:6381 [cluster]
root 3907 1 0 09:57 ? 00:00:02 ./redis-server *:6382 [cluster]
root 3913 1 0 09:57 ? 00:00:02 ./redis-server 0.0.0.0:6383 [cluster]
root 3919 1 0 09:57 ? 00:00:02 ./redis-server 0.0.0.0:6384 [cluster]
root 4247 2418 0 10:22 pts/0 00:00:00 grep --color=auto redis6) Configure the cluster
Command format: --cluster-replicas 1 means to create a slave node for each master
Note: The IP here is the real IP of the machine where each node is located
[root@localhost src]# ./redis-cli --cluster create 192.168.177.128:6379 192.168.177.128:6380 192.168.177.128:6381 192.168.177.128:6382 192.168.177.128:6383 192.168.177.128:6384 --cluster-replicas 1
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.177.128:6383 to 192.168.177.128:6379
Adding replica 192.168.177.128:6384 to 192.168.177.128:6380
Adding replica 192.168.177.128:6382 to 192.168.177.128:6381
>>> Trying to optimize slaves allocation for anti-affinity
[WARNING] Some slaves are in the same host as their master
M: ae77569d28f01657d9e3e04810e8562abdb3f5dd 192.168.177.128:6379
slots:[0-5460] (5461 slots) master
M: 5ccafb9ee2f223c987c740d3d8282f200e4892dd 192.168.177.128:6380
slots:[5461-10922] (5462 slots) master
M: dcd5d5066cd9aa5e3f2830ce985395acb978d764 192.168.177.128:6381
slots:[10923-16383] (5461 slots) master
S: 8849bb5437931a3fd8510ffa4c0f755f4e26d1eb 192.168.177.128:6382
replicates ae77569d28f01657d9e3e04810e8562abdb3f5dd
S: b00800f65775c52519bd6e9f398f916ffe46fed8 192.168.177.128:6383
replicates 5ccafb9ee2f223c987c740d3d8282f200e4892dd
S: 6e7a1ae63691267b000363f6528b620a656e03e7 192.168.177.128:6384
replicates dcd5d5066cd9aa5e3f2830ce985395acb978d764
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 192.168.177.128:6379)
M: ae77569d28f01657d9e3e04810e8562abdb3f5dd 192.168.177.128:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: dcd5d5066cd9aa5e3f2830ce985395acb978d764 192.168.177.128:6381
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
M: 5ccafb9ee2f223c987c740d3d8282f200e4892dd 192.168.177.128:6380
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 8849bb5437931a3fd8510ffa4c0f755f4e26d1eb 192.168.177.128:6382
slots: (0 slots) slave
replicates ae77569d28f01657d9e3e04810e8562abdb3f5dd
S: b00800f65775c52519bd6e9f398f916ffe46fed8 192.168.177.128:6383
slots: (0 slots) slave
replicates 5ccafb9ee2f223c987c740d3d8282f200e4892dd
S: 6e7a1ae63691267b000363f6528b620a656e03e7 192.168.177.128:6384
slots: (0 slots) slave
replicates dcd5d5066cd9aa5e3f2830ce985395acb978d764
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.7) View the master-slave relationship
Command format: redis-cli --cluster check [redis's own IP]: [redis's own port]
[root@localhost src]# ./redis-cli --cluster check 192.168.177.128:6379
192.168.177.128:6379 (ae77569d...) -> 0 keys | 5461 slots | 1 slaves.
192.168.177.128:6381 (dcd5d506...) -> 0 keys | 5461 slots | 1 slaves.
192.168.177.128:6380 (5ccafb9e...) -> 0 keys | 5462 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 192.168.177.128:6379)
M: ae77569d28f01657d9e3e04810e8562abdb3f5dd 192.168.177.128:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
M: dcd5d5066cd9aa5e3f2830ce985395acb978d764 192.168.177.128:6381
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
M: 5ccafb9ee2f223c987c740d3d8282f200e4892dd 192.168.177.128:6380
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 8849bb5437931a3fd8510ffa4c0f755f4e26d1eb 192.168.177.128:6382
slots: (0 slots) slave
replicates ae77569d28f01657d9e3e04810e8562abdb3f5dd
S: b00800f65775c52519bd6e9f398f916ffe46fed8 192.168.177.128:6383
slots: (0 slots) slave
replicates 5ccafb9ee2f223c987c740d3d8282f200e4892dd
S: 6e7a1ae63691267b000363f6528b620a656e03e7 192.168.177.128:6384
slots: (0 slots) slave
replicates dcd5d5066cd9aa5e3f2830ce985395acb978d764
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
Looking at the figure below, you can find that one master is one slave:
8) Master node data writing test
Add parameter -c to prevent routing failure
[root@bogon src]# ./redis-cli -p 6381 -c
127.0.0.1:6381> get name
-> Redirected to slot [5798] located at 192.168.109.149:6380
(nil)
192.168.109.149:6380> get name
(nil)
192.168.109.149:6380>9) Read data test from the node
Situation: The slave node in the redis cluster cluster can successfully copy the data slot data of the master node, but cannot get the data, and the display can only be read from the corresponding master node
Reason: The official default setting for the slave nodes in the Redis Cluster cluster is not to share the read request, and it is only used for backup and failover. When there is a request to read from the slave node, it will be redirected to the corresponding master node for processing
Solution: Use the command readonly before getting data. This readonly tells Redis Cluster that the slave node client is willing to read potentially outdated data and is not interested in write requests.
Note: readonly will be invalid after disconnection, and you need to use this command again to connect again.
[root@bogon src]# ./redis-cli -p 6379 -c
127.0.0.1:6379> set name zhangsan
-> Redirected to slot [5798] located at 192.168.109.149:6380
OK
192.168.109.149:6380> get name
"zhangsan"
192.168.109.149:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> get name
-> Redirected to slot [5798] located at 192.168.109.149:6380
"zhangsan"
192.168.109.149:6380>
[root@bogon src]# ./redis-cli -p 6383 -c
127.0.0.1:6383> readonly
OK
127.0.0.1:6383> get name
"zhangsan"
127.0.0.1:6383>