Redis Sentinel deployment process

version

CentOS 8.1.1911（VMWare）
redis 5.0.8 

Basic Information

服务器IP：192.168.31.68
Redis 端口：7000（主） 7001，7002（从） Sentinel端口：27000 27001 27002 

• Key codes or commands are expressed like this

Configure Redis

• master7000.conf

bind 0.0.0.0
port 7000
daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7000.pid logfile "7000.log" dbfilename dump7000.rdb 

• slave7001.conf

bind 0.0.0.0
port 7001 daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7001.pid logfile "7001.log" dbfilename dump7001.rdb slaveof 192.168.31.68 7000 

• slave7002.conf

bind 0.0.0.0
port 7002 daemonize yes dir /home/misty/redis-data/sentinel01 pidfile /var/run/redis_7002.pid logfile "7002.log" dbfilename dump7002.rdb slaveof 192.168.31.68 7000 

Start the Redis service

• Start redis

redis-server master7000.conf
redis-server slave7001.conf redis-server slave7002.conf 

Verification service started

$ ps -ef | grep redis-server | grep -v grep misty      4633   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7000 misty      4649   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7001 misty      4663   2639  0 03:16 ?        00:00:00 redis-server 0.0.0.0:7002 

Redis automatically establishes a master-slave relationship

redis:7000> info replication
# Replication
role:master connected_slaves:2 slave0:ip=192.168.31.68,port=7001,state=online,offset=630,lag=0 slave1:ip=192.168.31.68,port=7002,state=online,offset=630,lag=1 master_replid:187ff0474ccd0303571db1ca94174c46c2476dba master_replid2:0000000000000000000000000000000000000000 master_repl_offset:630 

It can be seen that the master has learned the information of the two slave nodes. It is worth noting the offset, the master and slave nodes determine whether they have been synchronized through the offset.

redis:7001> info replication
# Replication
role:slave master_host:192.168.31.68 master_port:7000 master_link_status:up master_last_io_seconds_ago:6 master_sync_in_progress:0 slave_repl_offset:882 slave_priority:100 slave_read_only:1 connected_slaves:0 master_replid:187ff0474ccd0303571db1ca94174c46c2476dba master_replid2:0000000000000000000000000000000000000000 master_repl_offset:882 

Pay attention to slave_priority here. In sentinel mode, if the master goes down, sentinel first decides who to be promoted to master based on slave_priority.

In the default configuration, the slave_priority of all nodes is the same, so the largest one will be selected according to the offset.

If you can't select a successor, choose the one with the smallest runID as the master (the oldest senior).

RunID is checked through the info server.

At this time, we think that the master node is shut down, and the slave node will show that the master node status is down. The slave node will not be automatically upgraded to master.

# Replication
role:slave
master_host:192.168.31.68 master_port:7000 master_link_status:down master_last_io_seconds_ago:-1 

After restarting the master node, the state returns to up

Configure Sentinel

• sentinel27000.conf

port 27000
daemonize yes
pidfile /var/run/redis-sentinel.pid logfile "sentinel27000.log" dir /home/misty/redis-data/sentinel01 sentinel monitor mymaster 192.168.31.68 7000 2 sentinel down-after-milliseconds mymaster 30000 sentinel parallel-syncs mymaster 1 sentinel failover-timeout mymaster 180000 sentinel deny-scripts-reconfig yes 

Since the configuration file differs only in the port number, only one configuration file is posted. Can be created in batches through the sed command

• sentinel27001.conf

sed "s/27000/27001/g" sentinel27000.conf > sentinel27001.conf

We will notice that the configuration information of sentinel does not identify the existence of other sentinels, but only the information of the master node. When the sentinel service is started, sentinel nodes will automatically sense the existence of other sentinel nodes and slave nodes through the master node.

Sentinel will modify the configuration file after startup, it is recommended to back up the configuration file.

• Start sentinel

redis-sentinel sentinel27000.conf
redis-sentinel sentinel27001.conf redis-sentinel sentinel27002.conf 

Verify that the sentinel starts successfully:

> ps -ef | grep redis-sentinel | grep -v grep misty      5516   2639  0 03:59 ?        00:00:00 redis-sentinel *:27000 [sentinel] misty      5528   2639  0 04:00 ?        00:00:00 redis-sentinel *:27001 [sentinel] misty      5539   2639  0 04:00 ?        00:00:00 redis-sentinel *:27002 [sentinel] 

Use redis-cli to connect to any sentinel, run info sentinel, you will get the same information

# Sentinel
sentinel_masters:1
sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:name=mymaster,status=ok,address=192.168.31.68:7000,slaves=2,sentinels=3 

A sentinel group can manage multiple redis master-slave groups, distinguished by master: name

Test master-slave automatic switching

We shut down 7000 nodes, wait a moment, you will find that the master node has switched to 7001 nodes.

sentinel:27000> info sentinel
...
master0:name=mymaster,status=ok,address=192.168.31.68:7001,slaves=2,sentinels=3 

It shows that there are still two slaves. When looking at the 7001 node, there is only one 7002 left in the slave.

redis:7001> info replication
# Replication
...
slave0:ip=192.168.31.68,port=7002,state=online,offset=227471,lag=0 

After restarting the redis: 7000 service, it is automatically set to the slave of redis: 7001

redis:7001> info replication
# Replication
...
slave0:ip=192.168.31.68,port=7002,state=online,offset=299880,lag=0 slave1:ip=192.168.31.68,port=7000,state=online,offset=299880,lag=1 

carry out

At this point, a basic Redis Sentinel group is built.

The redis sentinel node is only responsible for monitoring, and is not responsible for the forwarding of commands such as add, delete, modify, and check. The client still needs to connect to the actual Redis master node for operation. (Different from Cluster)

Appendix: Java Connect Redis Sentinel

import org.apache.commons.pool2.impl.GenericObjectPoolConfig;
import redis.clients.jedis.JedisSentinelPool;

import java.util.HashSet;

public class Sentinel {
  public static void main(String[] args) { var poolConfig = new GenericObjectPoolConfig<>(); poolConfig.setMaxTotal(10); var sentinels = new HashSet<String>(); sentinels.add("192.168.31.68:27000"); sentinels.add("192.168.31.68:27001"); sentinels.add("192.168.31.68:27002"); var sentinelPool = new JedisSentinelPool("mymaster", sentinels, poolConfig, 30000); try (var jedis = sentinelPool.getResource()) { jedis.set("hello", "world"); System.out.println(jedis.get("hello")); } catch (Exception e) { e.printStackTrace(); } } } 

If Redis cannot connect, please modify the server firewall and open the relevant ports

Client principle

• Select an available Sentinel node
• Visit sentinel to get master information: sentinel get-master-addr-by-name mymaster
• Verify the master node: role
• Create a connection pool
• Monitor the sentinel and rebuild the connection pool after discovering that the master node has changed