I heard that searching “Java Fish Boy” on wechat will improve my skills to the next level

(a) Sentry overview

Previously we talked about the master/slave replication of Redis. In order to achieve high availability, one server will be selected as master and multiple servers as slaves. When the master is down, the system selects a slave as the master, takes the master offline, and notifies all slaves who the new master is. This raises the question, who decides whether the master breaks down and which slave is selected as master?

This is done in master-slave replication by Sentinel, a distributed system that monitors each server in the master-slave structure and selects a new master through a voting mechanism when a failure occurs.

Sentinel is also a Redis server and is usually configured to have an odd number of sentinels (to avoid a tie when campaigning).

(2) The role of sentinels

1. Monitoring: Constantly check whether the master and slave are running properly. Master survival detection; Check the status of master and slave

2. Notification: Send notifications to other sentinels and clients when the detected server has a problem

3. Automatic failover: Enable the connection between the master and slave, select a new slave as the master, and connect the other slaves to the new master

(3) The working principle of the sentry

3.1 Monitoring Phase

Monitoring is one of the functions of sentry, monitoring is to synchronize the status information of each node

1. Run the ping command to obtain the status (online or not) of other sentinels

2. Obtain master status, including master rUNID, slave details, etc., through the info command

3. Obtain the status of all slaves (according to the slave information in the master), including rUNId, role, host, offset, and so on.

When the two Sentinels obtained the monitoring information of master or slave respectively, they would exchange data with each other for data synchronization. Similarly, when the third Sentinel obtained the monitoring information, it would also synchronize data with the other two Sentinels.

3.2 Notification Phase

The notification phase is mainly about the interaction of sentinels. Suppose there are three sentinels in a system. When Sentinel1 asks sentinel2 and Sentinel3 about the status of the master and slave servers and gets a response, it informs Sentinel2 and Sentinel3 of the other sentinels. Likewise, sentinel2 tells 1 and 3 when it gets the news. So that data is always synchronized.

3.3 Failover phase

When a Master goes down, this is the failover phase.

1. When a sentinel detects that the master does not respond to a message, it sets the status of the master to SDOWN and notifies the other sentinels. The other sentinels send hello to the master. When more than half of the sentinels feel that the master is down, the master status is set to ODown, which is the second step.

2. Since the master is down, it is necessary to elect a new master. Which sentinel chooses the master needs to be determined by the voting mechanism inside the Sentinel. After being elected out to perform the sentinel to find the new master, the third step is entered.

The sentinel selects a new master from the remaining slaves according to the priority, offset, and so on. The sentinel selects a new master from the remaining slaves according to the priority, offset, etc

4. Sentinel sends command to new master:

slaveof no one
Copy the code

Sends commands to other slaves

Slaveof new masterIP portCopy the code

(4) Sentry operations

You are advised to perform operations on the Linux server

Turn on sentry:

Redis-sentinel sentinel.conf (Custom file name)Copy the code

The configuration file

Port 26379 dir/TMP Sentinel monitor myMaster 127.0.0.1 6379 2# set the host monitored by the sentinels to 127.0.0.1:6379. If two sentinels believe the host is down, the host will be considered down
sentinel down-after-milliseconds 30000   The monitored server is considered down for how long the connection has not responded
parallel-syncs mymaster 1  # specifies the maximum number of slave servers that can synchronize with the new master server during failover
failover-timeout mymaster 180000  # specifies the synchronization timeout for failover
Copy the code

Sentinel Monitor MyMaster 127.0.0.1 6379 2: 127.0.0.1 6379 indicates the object monitored by the sentinel. Mymaster is a self-defined name, and the last 2 indicates that the monitored server is down when two sentinels think it is down. This is usually the number of sentinels divided by 2+1, which is more than half. When the host is down, the sentry automatically selects one of the hosts as the host