Docker Builds redis Master+Sentry

1. Principle of redis master slave + sentry


First, we need to know the consistency hash algorithm, which works by storing data clockwise to the nearest redis server, or possibly by calculating the value of the key from the hash algorithm
The hash value is exactly the address value of the redis server.
The reids master slave + sentry implementation is through sending data to the sentry. Because the sentry has information from the master server, the Sentry will send our data to the master server. If we send data directly to the master server, if the master server goes down, the Sentry will elect a master server again, such as the one we just started connecting to at port 7000.The primary server may be 7001 when the sentry chooses the primary server after the primary server is down. We need to modify our code over and over again, which is very cumbersome.

2. Prepare one master server and two slave servers

Let's take one subject and two subordinates as an example

Start Master Server

# --net=host container uses host port directly, no port mapping is required
docker run -d --name redis6379 --net=host --restart=always redis 

# Enter the container and run the redis client
docker exec -it redis6379 redis-cli

# View cluster information, default is primary server
> info replication

Start two slave servers

# Start the redis6380 container as the slave server for redis6379
# --port and--slaveof are parameters to the redis-server command
docker run -d --name redis6380 --net=host --restart=always redis \
redis-server --port 6380 --slaveof 192.168.64.150 6379

# Start the redis6381 container as the slave server for redis6379
docker run -d --name redis6381 --net=host --restart=always redis \
redis-server --port 6381 --slaveof 192.168.64.150 6379

# View the roles of the three redis services
docker exec -it redis6379 redis-cli
> info replication

docker exec -it redis6380 redis-cli -p 6380
> info replication

docker exec -it redis6381 redis-cli -p 6381
> info replication

3. Start three Sentinels

We have three sentries here. If the primary server 6379 is down, we will elect a new primary server by two of the three sentries. For example, if two senders elect a 6380 server as the primary server, the 6380 server will be elected as the new primary server. If the previously downloaded 6379 server is restarted, it will become a slave server.

Sentry Profile

mkdir /opt/sentinel/
cd /opt/sentinel/

# "sentinel monitor mymaster 192.168.64.150 6379 2" in configuration file
# The last two indicate that two sentries voted to confirm that the primary server is down before the sentry thinks the primary server is down.
cat <<EOF >5000.conf
port 5000
sentinel monitor mymaster 192.168.64.150 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
EOF

cat <<EOF >5001.conf
port 5001
sentinel monitor mymaster 192.168.64.150 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
EOF

cat <<EOF >5002.conf
port 5002
sentinel monitor mymaster 192.168.64.150 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
EOF

Start Three Sentinels

docker run -d --name sentinel5000 \
-v /opt/sentinel/5000.conf:/sentinel.conf \
--net=host \
redis redis-sentinel /sentinel.conf

docker run -d --name sentinel5001 \
-v /opt/sentinel/5001.conf:/sentinel.conf \
--net=host \
redis redis-sentinel /sentinel.conf

docker run -d --name sentinel5002 \
-v /opt/sentinel/5002.conf:/sentinel.conf \
--net=host \
redis redis-sentinel /sentinel.conf

# Enter a Sentry Container to view the master and slave servers it monitors and other Sentinels
docker exec -it sentinel5000 redis-cli -p 5000
> sentinel master mymaster
> sentinel slaves mymaster
> sentinel sentinels mymaster

Stop primary server 6379, test sentry re-elect new primary server

# Stop Master Server
docker stop redis6379
# View Server Switch Log in Sentry Log: +switch-master mymaster 192.168.64.150 6379 192.168.64.150 6381
docker logs sentinel5000

# View role changes for 6380 and 6381 servers
docker exec -it redis6380 redis-cli -p 6380
> info replication

docker exec -it redis6381 redis-cli -p 6381
> info replication


Here we see that the primary server 6379 can only be restarted as a slave server.

Client stores data through Sentinel

//Connect to the master server through the sentry and hand over the data to the sentry
//The sentry knows who the primary server is because it may be down
public class Test2 {
    public static void main(String[] args) {
        //List of Sentinel Servers
        Set<String> list = new HashSet<String>();
        list.add("192.168.64.150:5000");
        list.add("192.168.64.150:5001");
        list.add("192.168.64.150:5002");
        //Configuration object
        JedisPoolConfig conf = new JedisPoolConfig();
        //Sentry connection pool
        JedisSentinelPool p =
                new JedisSentinelPool("mymaster", list, conf);
        //Data manipulation tools
        Jedis j = p.getResource();
        j.set("k1","v1");
    }
}

Keywords: Database Docker Redis

Added by MikeL7 on Tue, 28 Sep 2021 21:22:57 +0300