What is Sentinel Sentinel surveillance

We built the master-slave replication and learned that when the master server goes down, we need to manually switch a slave server to the master server. Does it feel like a hassle? That’s right. Not only would that cost labor, but it would also cause the service to be unavailable for a period of time, which is obviously not feasible. So Redis has sentinel mode. Redis provides the Sentinel command, which is an independent process sentinel that monitors the health of Redis instances by sending commands to multiple nodes and getting Redis servers to respond. When the sentry detects that the primary node is down, it automatically switches the secondary node to the primary node and notifies the other secondary servers to modify the configuration file to switch the host.

Sentinel has three main missions

Task 1: Monitor. Sentinel does not constantly check whether your primary and secondary servers are working properly.

Task 2: Alert. When a monitored Redis server has a problem, Sentinel can send a notification through the API to the administrator or other applications to alert them of the failure.

Task 3: Automatic failover. As mentioned above, manual failover is required, which can be done with Sentinel. When a primary server fails, Sentinel starts an automatic failover operation by upgrading one of the secondary servers under the failed primary server to the primary server and making all secondary servers under the failed primary server replicate the new primary server. When the client fails to connect to the master server, a new server address is also returned to the client so that the new server address can be used to replace the failed master server.

Think about it. Is that a problem? A sentry process monitors the Redis server. If the sentry can’t get a response from the Redis server due to network problems, you might want to set up multiple sentries to monitor the Redis server. But if you have more than one sentry monitoring, you get the multi-sentry mode, and we’ll talk about the multi-sentry mode.

This section describes the offline names in multi-sentinel mode

Subjective offline (Subjectively Down, SDOWN for short)

It is a single Sentinel instance that makes the decision to take a server offline, such as not being notified of a network problem mentioned above. If a server does not respond to Sentinel in the amount of time specified in the down-after-milliseconds option, Sentinel will assume that the host server has gone offline.

We were Objectively Down, or ODOWN

After multiple sentinels perform SDOWN judgment on the same server and the sentinels communicate with each other through the Sentinel IS-master-down-by-addr command, determine whether the server is offline.

Objective offline conditions apply only to the primary server

Arbitration quornm

When Sentinel receives a sufficient number of primary server offline reports from other Sentinels within a given time frame, Sentinel changes the status of the primary server from active offline to objective offline. The sufficient number is the value in the configuration file, and the number of sentinels that are set to Sentinel is usually increased by 1, so 4 sentinels is set to 3.

Sentinel Sentinel setup environment preparation

Core flow: set ping per second, the server does not respond after the specified time, then the task of the server is subjective offline. If the primary server of multiple Sentinel tasks is offline, then it is considered to be objective offline, and then vote to switch from the secondary server to the primary server under that primary server. If there are not enough people to take the master server offline, the state of the server is removed.

Environment Preparation:

Step 1: Configure three sentries. The configuration of each sentry is the same.

Step 2: Start primary server -> Secondary server -> Sentry.

The port number of sentry is 26379 (keep it open).

# bind 0.0.0.0 # daemonize yes # configure the primary server to listen on, mymaster stands for server name, custom, 172.18.172.109 stands for monitoring primary server, 6379 stands for port, #2 indicates that a failover operation is performed only when two or more sentinels decide that the primary server is unavailable. Sentinel monitor mymaster 172.18.172.109 6379 2 # sentinel auth-pass Sentinel auth-pass myMaster 123456 The master has stopped sentinel down-after-milliseconds mymaster 5000 # Sentinel failover- Timeout MyMaster 30000Copy the code

Create three sentinels in the redis/conf directory

sentinel-1.conf

Port 26379 bind 0.0.0.0 daemonize yes pidfile "/var/run/redis-sentinel-1.pid" logfile "/var/log/redis/sentinel_26379.log" dir "/ TMP "Sentinel monitor myMaster 8.129.113.233 6379 2 Sentinel down-after-milliseconds mymaster 5000 sentinel auth-pass mymaster 123456 sentinel failover-timeout mymaster 30000Copy the code

sentinel-2.conf

Port 26380 Bind 0.0.0.0 daemonize yes pidfile "/var/run/redis-sentinel-2.pid" logfile "/var/log/redis/sentinel_26380.log" dir "/ TMP "Sentinel monitor myMaster 8.129.113.233 6379 2 Sentinel down-after-milliseconds mymaster 5000 sentinel auth-pass mymaster 123456 sentinel failover-timeout mymaster 30000Copy the code

sentinel-3.conf

Port 26381 bind 0.0.0.0 daemonize yes pidfile "/var/run/redis-sentinel-3.pid" logfile "/var/log/redis/sentinel_26381.log" dir "/ TMP "Sentinel monitor mymaster 8.129.113.233 6379 2 Sentinel down-after-milliseconds mymaster 5000 sentinel auth-pass mymaster 123456 sentinel failover-timeout mymaster 30000Copy the code

Remember to create the /var/log/redis folder, mainly used to store the sentinels’ log files

Start the sentinel (failure to start the sentinel requires opening the port of the network security group)

./redis-server /usr/local/redis/conf/sentinel-1.conf --sentinel
./redis-server /usr/local/redis/conf/sentinel-2.conf --sentinel
./redis-server /usr/local/redis/conf/sentinel-3.conf --sentinel
Copy the code

Advantages: Master and slave can be switched automatically, higher availability.

Disadvantages: The write and storage capabilities of the primary node are limited

Briefly analyze the log

1. The boss is disconnected

2. Frantically sending inquiries to the boss (boss, did you hang up? There is no answer, it should be hung up, then the sentry will assist from node to boss)

3. MASTER MODE enabled

4. Making data requests with other boys (the former boss died, you still don’t follow me?)

5. Then a new master and slave is established

SpringBoot integration with Redis master-slave +Sentinel Sentinel

Above you have a clear understanding of how to use the sentinel in Redis and how to set up the sentinel environment. The next step is to use the SpringBoot+Sentinel Sentinel integration.

First comment out the host and port of Redis in the application.yml configuration

Adding a new configuration (Sentry related configuration)

Sentinel: master: mymaster nodes: 8.129.113.233:26379,8.129. 113.233:26380,8.129. 113.233:26381Copy the code

This allows you to configure the Redis sentry configuration in your project. Sentry is frequently used in Redis.