- Prepare cluster environment: docker-79, docker-80, docker-81
- Pull image:
docker pull bitnami/redis-cluster:latest
3. Create a new compose.yml script in any folder: redis_compose.yml
abnormal
SELECT is not allowed in cluster mode
Open the connection and prompt: SELECT is not allowed in cluster mode
This is because the default number of databases in the redis.conf configuration file is 16 in the stand-alone mode. This configuration does not work in the cluster mode. The cluster client does not support multiple databases db, and only one database defaults to SELECT 0;
The redis cluster version only uses db0. Although the select command can support select 0. Other DB will return errors.
CLUSTERDOWN Hash slot not served
Use cluster info to view the redis cluster status:
You can see that the cluster status is fail and the number of slots below is 0, which is very abnormal.
Enter the container in turn: docker exec -it container ID bash
Execution: redis cli - C - H 172.17.0.1 - P 6379
redis can be connected normally, and then execute cluster meet 172.17.0.1 6379
This IP(172.17.0.1) is the default internal network IP of docker:
If you do not have a password, you will be prompted with OK directly. If you have a password, you need to enter: auth redis password
This meet command is very popular. It is to let nodes in the cluster know each other??? Then operate the IP of the other two servers and let them know each other.
After this step, it is found that the problem has not been solved. Try to write the value into the client, and still prompt this exception.
Then execute redis cli -- cluster info 192.168.104.79:6379 - A in the container huauN@2021 , where huauN@2021 It is the redis cluster password. If there is no password, you don't need to add the - a password. It is found that the slots slot is empty. That's why the above error occurs.
root@docker-80:/# redis-cli --cluster info 192.168.104.79:6379 -a huauN@2021 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.104.79:6379 (6ce9026c...) -> 0 keys | 0 slots | 0 slaves. [OK] 0 keys in 1 masters. 0.00 keys per slot on average. root@docker-80:/#
Then use redis cli -- cluster fix to repair the cluster
root@docker-80:/# root@docker-80:/# redis-cli --cluster fix 192.168.104.79:6379 -a huauN@2021 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 192.168.104.79:6379 (6ce9026c...) -> 0 keys | 0 slots | 0 slaves. [OK] 0 keys in 1 masters. 0.00 keys per slot on average. >>> Performing Cluster Check (using node 192.168.104.79:6379) M: 6ce9026c9f438f8025323bf13787e43f08dc33bd 192.168.104.79:6379 slots: (0 slots) master [OK] All nodes agree about slots configuration. >>> Check for open slots... >>> Check slots coverage... [ERR] Not all 16384 slots are covered by nodes. >>> Fixing slots coverage... The following uncovered slots have no keys across the cluster: [0-16383] Fix these slots by covering with a random node? (type 'yes' to accept): yes >>> Covering slot 660 with 192.168.104.79:6379 >>> Covering slot 4315 with 192.168.104.79:6379 >>> Covering slot 13760 with 192.168.104.79:6379 >>> Covering slot 10315 with 192.168.104.79:6379
Then let the input confirm whether to repair the slot: Fix these slots by covering with a random node? (type 'yes' to accept): if you enter yes here, the slot will be automatically repaired. Wait for the rolling output to end. Look at the node information, as shown in the figure below. The number of slots is 16384, which is the number of normal single node slots.
At this time, directly check the slot points of the other two machines. You can see that they are also normal.
At this time, redis can be used normally by using the client connection test:
The key also exists automatically on the other two machines:
At this time, if you look at the cluster status, it has become ok: