Redis sentinel Mode Construction

I. Introduction to Sentinel

I used to talk about a wave of redis and its application scenarios. Today I tried his sentinel model;

Sentinel is a redis HA solution. A sentinel system consisting of one or more sentinel instances can monitor any number of Master servers, and all slave servers under these master servers,

When the monitored master server goes offline, a slave server under the master server is automatically upgraded to a new master server, then, the new master server replaces the offline master server to continue processing command requests.

The Sentinel mechanism provided by redis automatically monitors the running status of Master/Slave after redis is started in Sentinel mode. The basic principle is: Heartbeat Mechanism + voting decision.
Monitoring (Monitoring): sentinel constantly checks whether your master server and slave server are operating normally.
Notification: When a monitored redis server encounters a problem, Sentinel can send a notification to the administrator or other applications through the API.
Automatic failover: When a master server cannot work properly, Sentinel will start an automatic failover operation, it will upgrade one of the failed master servers to a new master server,

Replace other slave servers that fail the master server with the new master server. When the client tries to connect to the master server that fails, the Cluster also returns the address of the new master server to the client, this allows the cluster to use the new master server instead of the Invalid server.

Ii. redis sentinel Construction

The test uses two Enis, one master redis, and two slave redis.
Copy five redis. Windows. conf files and rename them as follows (developers can rename them according to their own development habits ):

Master.62.16.conf Configuration:

Port 6379
# Set the connection password
Requirepass GRs
# Connection password
Masterauth GRs

Slave.6380.conf Configuration:

Port 6380
Requirepass GRs
Masterauth GRs
Dbfilename dump6380.rdb
# Configuring master
Slaveof 127.0.0.1 6379

Slave.6381.conf Configuration:

Port 6381
Requirepass GRs
Masterauth GRs
Dbfilename dump6381.rdb
# Configuring master
Slaveof 127.0.0.1 6379

Sentinel.62.161.conf configuration (clear the original configuration file and add the following content) (the other is the same, you only need to modify the next port ):

Port 63791
# The primary master is valid only after two sentinel instances are successfully elected. Here, master-1 is the name, which must be consistent during integration. You can change it as needed.
Sentinel monitor master-1 127.0.0.1 6379 2
# Determine the time (in milliseconds) when the master is suspended. If no correct information is returned after the timeout, it is marked as sdown.
Sentinel down-after-milliseconds master-1 5000
# If sentinel fails to complete the failover operation (Master/Slave automatic switch upon failure) within this configuration value, the Failover fails.
Sentinel Failover-Timeout master-1 18000
# Identity Authentication
Sentinel auth-pass master-1 GRs
# The option specifies the maximum number of slave servers that can be synchronized to the new master server during failover. The smaller the number, the longer it takes to complete the Failover.
Sentinel parallel-syncs master-1 1

Note the following three problems:
First, if you connect to apsaradb for redis-cli-H 127.0.0.1-P 6379, you do not need to change the configuration file. The default configuration file is bind 127.0.0.1 (only access through 127.0.0.1 connections is allowed)
If you connect to apsaradb for redis-cli-H 192.168.180.78-P 6379, you need to change the configuration file to bind 127.0.0.1 192.168.180.78 (only access to 127.0.0.1 and 192.168.180.78 is allowed) or comment out bind 127.0.0.1 (allow all remote access)
Second, masterauth is the requirepass of the master server to be connected. If a redis cluster has one master server and two slave servers, when the master server fails, sentinel will randomly select an slave server as the master server. In view of this mechanism, the solution is to set requirepass and masterauth of all master and slave servers to the same.
Third, what does sentinel monitor master-1 127.0.0.1 6379 mean by the last 2 lines at the end of the 2 row? We know that the network is unreliable. Sometimes an sentinel may mistakenly think that a master redis instance is dead due to network congestion. When the Sentinel cluster is used, the solution to this problem becomes very simple, only multiple sentinels need to communicate with each other to confirm whether a master is actually dead. This 2 indicates that when two sentinel nodes in the cluster think that the master is dead, in order to truly think that the master is no longer available. (Each sentinel in the Sentinel Cluster also communicates with each other through the gossip protocol ).
Start the service in sequence as follows
1. redis-server master.62.16.conf

2. redis-server slave.6380.conf

3. redis-server slave.6381.conf

4. redis-server sentinel.62.161.conf -- sentinel (Linux: redis-sentinel sentinel.62.161.conf)

5. redis-server sentinel.62.162.conf -- sentinel (Linux: redis-sentinel sentinel.62.162.conf)

View Master Status:

View the slave status:

View sentinel status:

Verify the master-slave switchover of redis sentinel:
1. First shut down the primary redis (6379) Service (shutdown ).
2. Check the sentinel and find that the port number 6380 is changed from the service to the master service, and sentinel automatically completes the Failover.

3. Start the 6379 service that has just been shutdown and check it. It turns into a slave service.

Now, my setup and demonstration are over.

It will take time to integrate and use the standalone version of spring.

Redis sentinel Mode Construction