1, an overview of the

Redis clustering enables high availability and Sharding across a set of Redis nodes. There will be one master and multiple slave nodes in the cluster. When a master node fails, a slave node should be selected as the new master. However, Redis itself (including many of its clients) does not have the ability of automatic fault discovery and master/standby switchover, so external monitoring schemes are needed to realize automatic fault recovery.

Redis Sentinel is an officially recommended high availability solution. It is a monitoring management tool for Redis clusters, providing node monitoring, notification, automatic failover, and client configuration discovery services.

2. Problems encountered

1. Docker Host network

Docker host network does not take effect for Windows and MAC (no solution was found), and finally abandoned Windows using centos cluster deployment.

2. Sentinel connection problem without host network

When sentinel cluster is connected without host network, the port of the primary node can be designated, so it can be connected normally. However, when the primary node fails, the IP obtained by Sentinel from the primary node is the virtual IP in the container, so the cluster cannot be connected normally.

3. Setup process

1. Directory structure

2. Sentinel configuration file

1, sentinel1. Conf

# port
port 26379
dir /tmp
# myMaster: custom cluster name, 2: the number of votes must be 2 sentinels to determine whether the primary node failed
sentinel monitor mymaster <ip> <port> 2
# indicates that the primary node is unreachable after 5000 seconds and there is no reply
sentinel down-after-milliseconds mymaster 5000
# indicates that at most NumSlaves are updating the new master simultaneously during failover
sentinel parallel-syncs mymaster 1
# failover timeout
sentinel failover-timeout mymaster 5000

Copy the code

2, sentinel2. Conf

# port
port 26380
dir /tmp
# myMaster: custom cluster name, 2: the number of votes must be 2 sentinels to determine whether the primary node failed
sentinel monitor mymaster <ip> <port> 2
# indicates that the primary node is unreachable after 5000 seconds and there is no reply
sentinel down-after-milliseconds mymaster 5000
# indicates that at most NumSlaves are updating the new master simultaneously during failover
sentinel parallel-syncs mymaster 1
# failover timeout
sentinel failover-timeout mymaster 5000

Copy the code

3, sentinel3. Conf

# port
port 26381
dir /tmp
# myMaster: custom cluster name, 2: the number of votes must be 2 sentinels to determine whether the primary node failed
sentinel monitor mymaster <ip> <port> 2
# indicates that the primary node is unreachable after 5000 seconds and there is no reply
sentinel down-after-milliseconds mymaster 5000
# indicates that at most NumSlaves are updating the new master simultaneously during failover
sentinel parallel-syncs mymaster 1
# failover timeout
sentinel failover-timeout mymaster 5000

Copy the code

3, the docker – compose. Yml

version: '2'Services: master: image: redis:4.0 restart: always container_name: redis-master# Use the 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 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
    Map files to specified Sentinel locations using data volumes
    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  
    
Copy the code

4. Test the cluster deployment effect using centos

1. Test connecting clusters through Sentinel1

2. Test data synchronization of main node idea node

3. Disable master to view the active/standby switchover

At the end

After Dragon Boat Festival, I was lazy for a week. Before that, I set up a Sentinel cluster. Due to the docker network model problem, the cluster could not be connected after the switchover between master and standby nodes.