Example of building a redis-sentinel cluster based on docker

1. Overview

Redis Cluster enables high availability and sharding among a group of Redis nodes. There will be 1 master and multiple slave nodes in the cluster. When the master node fails, a slave node should be elected as the new master. However, Redis itself (including many of its clients) does not have the ability to automatically detect faults and perform active-standby switching, and requires an external monitoring solution to achieve automatic fault recovery.

Redis Sentinel is the officially recommended high availability solution. It is a monitoring and management tool for Redis clusters, which can provide node monitoring, notification, automatic fault recovery and client configuration discovery services.

2. Problems encountered

1. Docker host network

When docker uses the host network, it does not work on Windows and Mac (no solution was found). Finally, I gave up on Windows and used CentOS to deploy the cluster.

2. Sentinel connection problem without using host network

When connecting to the sentinel cluster without using the host network, you can specify the master node port so that it can be connected normally. However, when the master node fails, the IP obtained by sentinel from the master node is the virtual IP in the container, which causes the cluster to be unable to connect normally.

3. Construction process

1. Directory structure

2. Sentinel configuration file

1. sentinel1.conf

#Port number port 26379
dir /tmp
# mymaster: custom cluster name, 2: voting quantity must be 2 sentinels to determine whether the master node fails sentinel monitor mymaster <ip> <port> 2
# If the master node is unreachable after more than 5000 seconds and there is no reply, sentinel down-after-milliseconds mymaster 5000
# Indicates that at most numslaves are updating the new master synchronously during failover
sentinel parallel-syncs mymaster 1
# Failover timeout sentinel failover-timeout mymaster 5000

2. sentinel2.conf

#Port number port 26380
dir /tmp
# mymaster: custom cluster name, 2: voting quantity must be 2 sentinels to determine whether the master node fails sentinel monitor mymaster <ip> <port> 2
# If the master node is unreachable after more than 5000 seconds and there is no reply, sentinel down-after-milliseconds mymaster 5000
# Indicates that at most numslaves are updating the new master synchronously during failover
sentinel parallel-syncs mymaster 1
# Failover timeout sentinel failover-timeout mymaster 5000

3. sentinel3.conf

#Port number port 26381
dir /tmp
# mymaster: custom cluster name, 2: voting quantity must be 2 sentinels to determine whether the master node fails sentinel monitor mymaster <ip> <port> 2
# If the master node is unreachable after more than 5000 seconds and there is no reply, sentinel down-after-milliseconds mymaster 5000
# Indicates that at most numslaves are updating the new master synchronously during failover
sentinel parallel-syncs mymaster 1
# Failover timeout sentinel failover-timeout mymaster 5000

3. docker-compose.yml

version: '2'
services:
 master:
 image: redis:4.0
 restart: always
 container_name: redis-master
 #Use host network network_mode: "host"
 command: redis-server --port 16379 
 
 slave1:
 image: redis:4.0
 restart: always
 container_name: redis-slave-1
 network_mode: "host"
 # Specify the port and specify the master ip port command: redis-server --port 16380 --slaveof <master ip> 16379
 
 slave2:
 image: redis:4.0
 restart: always
 container_name: redis-slave-2
 network_mode: "host" 
 command: redis-server --port 16381 --slaveof <master ip> 16379
 
 sentinel1:
 image: redis:4.0
 restart: always
 container_name: redis-sentinel-1
 network_mode: "host"
 # Specify the sentinel file location command: redis-sentinel /usr/local/etc/redis/sentinel.conf
 # Use the data volume to map the file to the specified sentinel location volumes:
  - ./sentinel/sentinel1.conf:/usr/local/etc/redis/sentinel.conf
 
 sentinel2:
 image: redis:4.0
 restart: always
 container_name: redis-sentinel-2
 network_mode: "host" 
 command: redis-sentinel /usr/local/etc/redis/sentinel.conf
 volumes:
  - ./sentinel/sentinel2.conf:/usr/local/etc/redis/sentinel.conf
 
 sentinel3:
 image: redis:4.0
 restart: always
 container_name: redis-sentinel-3
 network_mode: "host" 
 command: redis-sentinel /usr/local/etc/redis/sentinel.conf
 volumes:
  - ./sentinel/sentinel3.conf:/usr/local/etc/redis/sentinel.conf

4. Use centos to deploy cluster test results

1. Test the connection to the cluster through sentinel1

2. Test the data synchronization between master node and sub-node

3. Close the master to view the master-slave switch

Sentinel is connected normally

The master node is switched from 16379 to 16381

Conclusion

I was lazy for a week after the Dragon Boat Festival. I built a sentinel cluster before. Due to the problem of docker network model, the cluster could not be connected after the master and slave nodes switched. Yesterday, I saw that the host could not be implemented on window, so I put it on centos for testing and it worked perfectly.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.

You may also be interested in:

Detailed explanation of the environment construction of docker to build redis cluster
Method of building redis cluster based on docker
Use Docker to build a Redis master-slave replication cluster
Teach you how to build Redis cluster mode and sentinel mode with docker in 5 minutes
Building a Redis cluster on Docker
Implementation of Redis master-slave cluster based on Docker
How to deploy Redis 6.x cluster through Docker
How to quickly build a redis cluster using Docker-swarm

<<: my.cnf (my.ini) important parameter optimization configuration instructions

>>: React internationalization react-intl usage