Redis sentinel mode cluster construction

Sentinel, as the name suggests, stands on guard. It is a high-availability solution provided by redis. It is an optimization and upgrade to the master-slave mode. In the master-slave mode, if the main library goes down, manual intervention is required to remove a slave The node is promoted to the main library, and the address of the master node of the application configuration needs to be modified. In Sentinel mode, each sentinel process will send messages to other sentinels, masters, and slaves at regular intervals to confirm whether the other party is alive or not. "If it is found that the other party has not received a response within the specified time, it will mark the node as offline. If it is the master node, it will also negotiate with other Sentinel nodes. When the majority thinks the master node is unreachable , They will elect a Sentinel node to complete the failover work, and will notify the application side that the master node has been transferred. Let's build a Sentinel cluster below.

Installation and deployment

Environmental preparation

    Here we are using Redis 4.0.10, start three servers on one server to simulate the one-master two-slave architecture, the redis installation process is not demonstrated here, you can refer to the article [redis] deployment and parameter details ( Hematemesis is sorted out, it is recommended to collect) .

Deployment process

1. Start the master node to
modify the configuration file /usr/local/redis/etc/redis_6377.conf, mainly pay attention to the following parameters

port 6377daemonize yeslogfile "/redis_data/log/redis_6377.log"dir "/redis_data/data/6377"dbfilename "dump_6377.rdb"

Execute start command

redis-server /usr/local/redis/etc/redis_6377.conf

Connect test through redis client

redis-cli -h 127.0.0.1 -p 6377127.0.0.1:6377> pingPONG

2. Starting the slave node
The main difference between the slave node configuration file and the master node configuration file is that 6377 is changed to the port number corresponding to the slave node. The port numbers of the two slave nodes in this experiment are 6378 and 6379 respectively. At the same time, configure the IP and port of the master node to be synchronized.

slaveof 127.0.0.1 6377

Start slave node

redis-server /usr/local/redis/etc/redis_6378.confredis-server /usr/local/redis/etc/redis_6379.conf

 
Confirm whether the master and slave are in effect

[redis@localhost etc]$ redis-cli -h 127.0.0.1 -p 6377 info replication# Replicationrole:masterconnected_slaves:2slave0:ip=127.0.0.1,port=6378,state=online,offset=308,lag=0slave1:ip=127.0.0.1,port=6379,state=online,offset=308,lag=1

3. Start Sentinel Nodes.     Sentinel Nodes must have at least 3 and an odd number, so that a majority can be formed in the agreement. Configure the Sentinel node configuration file /usr/local/redis/sentinel-26377.conf, mainly pay attention to the following parameters

port 26377dir "/redis_data/data/26377"logfile "/redis_data/log/redis-26377.log"#Configure the IP and port of the master node, 2 means that the master node judges failure and requires at least 2 Sentinel nodes to agree, generally set to Sentinel Half of the number of nodes plus 1. sentinel monitor mymaster 127.0.0.1 6377 2# 30 seconds ping cannot pass the information of the master node, subjectively thinks that the master is down sentinel down-after-milliseconds mymaster 30000# During the failover, the slave node initiates replication to the new master at the same time The number of requests, 1 means that the slave node will poll to initiate replication. sentinel parallel-syncs mymaster 1#failover starts, if it is not completed within 180 seconds, it is considered that the transfer has failed sentinel failover-timeout mymaster 180000

Start the Sentinel node

redis-sentinel sentinel-26377.confredis-sentinel sentinel-26378.confredis-sentinel sentinel-26379.conf

4. Check whether the sentry is in effect through the Sentinel node

[redis@localhost redis]$ redis-cli -h 127.0.0.1 -p 26377 info Sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6377,slaves=2,sentinels=3

At this point, the redis cluster construction in Sentinel mode is complete.

Failover

Simulate the downtime of the main library, kill the main library through the kill command, and check the failover situation:

127.0.0.1:26377> info sentinel# Sentinelsentinel_masters:1sentinel_tilt:0sentinel_running_scripts:0sentinel_scripts_queue_length:0sentinel_simulate_failure_flags:0master0:name=mymaster,status=ok,address=127.0.0.1:6378,slaves=2,sentinels=3

You can see that the master is changed to 127.0.0.1:6378. The general steps of failover are as follows:

1. Each Sentinel node sends ping detection to the master, slave, and other Sentinel stages every 1 second. If no response is returned after down-after-milliseconds, the node is judged to be offline subjectively.

2. The Sentinel node asks other Sentinel nodes about the judgment of the abnormal node. When the quorum sentinel nodes are considered to be subjectively offline, the node is objectively offline.

3. In the sentinel node, a leader is elected through the Raft algorithm to complete the failover.

4. When the failed node is the master node, the sentinel leader will select one of the slave nodes as the master node based on priority, replication offset, runid, etc., and execute the slave of no one command.

5.  The leader sends instructions to other slave nodes to make them become slave nodes of the new master, and update the original master node as a slave node. When the old master is restored, it will replicate the data of the new master.

6. After the copy is completed, the switch message of the master node is issued.