The principle and actual combat of redis-Sentinel sentinel

Sentinel (Sentinel, Sentinel) is a high-availability solution for redis: a Sntinel system consisting of one or more Sentinel instances.
Its main function is to monitor any number of master servers and all the slave servers under these master server trees, and when the monitored master server enters the offline state, it will automatically offline a slave server under the master server. Upgrade to a new master server, and then the new master server continues to process command requests in place of the offline master server.
In fact, the meaning of the sentinel mode is to make redis highly available. When there is a problem with redis, redis can realize the hot switching
process :
we now assume that there is a

Sentinel系统
主服务器server1
从服务器server2、server3、server4

Then you can draw a state diagram

When the original master server server1 crashes, the Sentinel system will select a server from the slave servers to serve as the master server

When the original master server server1 resumes service, server1 will be defined as the slave server of the current master server server2

The difference between starting Sentinel and starting redis server

1. Different startup methods

redis-sentinel /path/to/your/sentinel.conf

or

redis-server /path/to/your/sentinel.conf --sentinel

Inside the program, when Sentinel is started, the code used by redis is replaced with Sentinel-specific code, and the Sentinel state is initialized, the list of monitored master servers is initialized, and a network link to the master server is created.

2. Different available commands
Because Sentinel simply provides monitoring services, its content can only execute some monitoring-related commands, including publish and subscribe commands, file event handler commands, time event handler commands, etc. Including some commands such as set and get

3. The internal code is different, and the configuration file is also different.
In point 1, it was mentioned that the sentinel mode will use special code, and the configuration file is the embodiment of some general configuration of the code, so the configuration file and the configuration file of the redis service are also different. Among them, it is worth noting that:

1.实例的名字，主服务器的名字由用户在配置文件中设置从服务器以及哨兵的名字将会由哨兵自己定义，格式为IP:port
2.实例无响应多少毫秒之后才会被判断为主观下线（down-after-milliseconds），该值可以在配置文件中找到并修改
3.判断实例为客观下线所需支持的投票数（quorum）
4.在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量（parallel_syncs）
5.刷新故障迁移状态的最大时限制(failover_timeout)

Among them, subjective offline and objective offline need to be in a sentinel system to reflect their functions, that is, the number of sentinels monitoring the same host>=2

In other words, we can configure sentinel related status by modifying sentinel.conf

port 26379 #端口号
sentinel monitor mymaster 127.0.0.1 6379 2 #监听的主机名，ip，端口，客观下线时投票数
sentinel down-after-milliseconds mymaster 30000#实例无响应多少毫秒后判断为主观下线
sentinel parallel-syncs mymaster 1#在执行故障转移操作时，可以同时对新的主服务器进行同步的从服务器数量
sentinel failover-timeout mymaster 180000#刷新故障迁移状态的最大时限制

Sentinel mode workflow internal implementation

1. Create a network link to the main server.
When the sentry is initialized, two links will be created to the main server

命令链接：主要用来发送命令
订阅链接：主要用来监听信息

Then the sentinel can obtain the information of the main service and all the slave servers through the info command, and according to the feedback content, the sentinel builds the monitored server object internally, and updates the status in real time.

Not only that, if there are multiple Sentinels monitoring the same server, then the Sentinel can learn the current Sentinel system set by interacting with the main server

Finally, the whole system will become a network state

Logic to detect offline:

1.当其中一台哨兵发A现主服务器下线时，此时对A来说主服务器是主观下线，他需要把该消息传递给系统中其他哨兵
2.当其他哨兵B、C接受到A的消息后，会对主服务器进行监测，如果判断为下线，将对A进行反馈，此时如果认为主服务器已经进入下线状态的Sentinel的数量超过配置中设置的quorum值，那么该Sentinel就会认为主服务器已经进入客观下线状态。
3.当一个主服务器被判断为客观下线时，监视这个下线主服务器的各个Sentinel会进行协商，选举出一个领头，执行故障转移操作

Failover:

1.在已下线主服务器树下的所有从服务器里面，挑出一个从服务器，并将其转换为主服务器(根据其活跃的状态与级别，可以在从服务器里面进行设置)
2.让已下线主服务器树下的所有从服务器改为复制新的主服务器
3.将已下线主服务器设置为新的主服务器的从服务器，当这个旧的主服务器重新上线

When the original master server comes back online, make it the slave server of the current master server

actual combat

I will add a sentinel on the basis of the master-slave built in this article
to simulate the process of high availability. Its applications include 1. master server redis-m
2. slave server redis-s
3. sentinel redis-sentinel

Duplicate an application as a sentinel application based on the original

cp -rf  redis-m redis-sentinel

Here, in order to be able to switch from master to slave, to switch from master to master, it is necessary to update the configuration in the master-slave server, and these two items need to be added.

requirepass Link$2013
masterauth Link$2013

Modify the sentry configuration file

cd redis-sentinel
vim sentinel.conf

Mainly modify the following configuration

sentinel monitor mymaster 127.0.0.1 10001 1
sentinel down-after-milliseconds mymaster 5000 #5秒无反应认定为失效
sentinel parallel-syncs mymaster 1
daemonize yes
sentinel auth-pass mymaster Link$2013 #记得配置密码否则无法监听

Start the master-slave chain first, then start the sentinel

./redis-sentinel ../sentinel.conf

View process status

Use cli to enter the sentinel, enter the command info to see the following information

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:10001,slaves=1,sentinels=1 #这里可以看到监听的主从链的状态

Now let's kill redis-m to Jiu and see the changes

Enter the sentinel node again and enter the info command

# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
master0:name=mymaster,status=ok,address=127.0.0.1:10002,slaves=1,sentinels=1

Enter redis-s, enter info, view replication information

# Replication
role:master
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

Restart redis-m, kill redis-s 9, and you can see that the state has switched back. It should be noted here that during hot switching, you must ensure that there are replaceable servers from the service list, that is, if

杀死redis-m
再杀死redis-s
启动redis-m
这时已经无法切换到redis-m了
这时启动redis-s，已经无法维持redis-m、redis-s的主从关系了