configuration

Create a conf directory under the redis directory to store the configuration files of each node.

#redis-master.conf
port 7000
daemonize yes
logfile "redis-master.log"
dbfilename "dump-master.rdb"

#redis-slave-01.confPort 7001 daemonize yes logfile "redis-slave-01.log" dbfilename "dump-slave-01.rdb" slaveof 127.0.0.1 7000
#redis-slave-02.confPort 7002 daemonize yes logfile "redis-slave-02.log" dbfilename "dump-slave-02.rdb" slaveof 127.0.0.1 7000Copy the code

Start Redis in turn

. / redis - 5.0.5 / SRC/redis - server conf/redis - master - 7000. Conf. / redis - 5.0.5 / SRC/redis - server conf/redis - slave - 7001. Conf . / redis - 5.0.5 / SRC/redis - server conf/redis - slave - 7002. ConfCopy the code

After the node is started, connect the primary node to check whether the primary/secondary status is normal, as shown in the following figure:

configuration

#Port on which the Sentinel instance runs. The default is 26379
port 26379

#Sentinel's working directory
dir ./

#Sentinel monitors the redis master node
## IP: indicates the HOST IP address
## port: sentry port number
## master-name: specifies the name of the master node that can be named by itself (consisting of only letters A-z, digits 0-9, and ".-_").
## quorum: When these quorum sentinels consider the master node to be disconnected, the master node is objectively considered to be disconnected
# sentinel monitor <master-name> <ip> <redis-port> <quorum>  Sentinel Monitor MyMaster 127.0.0.1 6379 2
#When requirepass 
      
        is enabled in a Redis instance, all clients connected to the Redis instance must provide a password.
      
# sentinel auth-pass <master-name> <password>  
sentinel auth-pass mymaster 123456  

#Specifies the maximum interval between the primary node responding to sentinel sentinel. After this interval, the sentinel subjectively considers the primary node offline. Default: 30 seconds
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000  

#Specifies the maximum number of slaves that can synchronize the new master at the same time during a failover. The smaller the number, the longer it takes to complete the failover; The opposite is true, but if this number is larger, it means that more slaves are unavailable because of Replication. This value can be set to 1 to ensure that only one slave at a time is unable to process command requests.
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1  

#Failover -timeout. The default value is three minutes. It can be used for the following purposes:
## 1. The interval between two failover operations for the same sentinel and the same master.
## 2. Start when a slave synchronizes data from an incorrect master and end when the slave is corrected to synchronize data from the correct master.
## 3. The time it takes to cancel an ongoing failover.
## 4. Maximum time required to configure all Slaves to point to the new Master when performing failover. However, even after this timeout, slaves will still be configured correctly to point to the master but will not synchronize data according to the rules configured for parallel Syncs
# sentinel failover-timeout <master-name> <milliseconds>  
sentinel failover-timeout mymaster 180000

#This script is invoked when sentinel has any warning level events (such as subjective and objective failures of redis instances, etc.). The maximum execution time of a script is 60 seconds. If this time is exceeded, the script will be terminated by a SIGKILL signal and executed again.
#The following rules apply to the result of running a script:
## 1. If the script returns 1 after execution, the script will be executed again later, with the current default being 10.
## 2. If the script returns 2 after execution, or a value higher than 2, the script will not be executed twice.
## 3. If the script is aborted during execution due to a system interrupt signal, it behaves the same as if the value is 1.
# sentinel notification-script <master-name> <script-path>  
sentinel notification-script mymaster /var/redis/notify.sh

#The script should be generic and can be called multiple times, not specific.
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

Copy the code

The sentinel node can be started in two ways, which are identical:

./redis-sentinel sentinel-27000.conf
./redis-server sentinel-27000.conf --sentinel
Copy the code

Once configured and started in this manner, the sentinel system is up and running. You can view the sentinel node information by connecting to the sentinel node through redis-CLI:

3. Failover and recovery

1. Run the kill command to forcibly kill the primary node

2. Failover takes some time. After a while, go back to sentinel and run the info sentinel command to view the fault. As you can see, the primary node has been removed from the

127.0.0.1:7000 has been moved to 127.0.0.1:7001

3. Restart node 7000 and access the node to view information through the info relication. As you can see, the primary node is 7001 and node 7000 becomes a Salve node.

5. During the failover phase, the sentry and master/slave configuration files are overwritten.

For master and slave nodes, the slaveof configuration changes: the new master node does not have the Slaveof configuration, and its slave node slaveof the new master node. For the sentinel node, in addition to the change of the information of the master and slave nodes, epoch will also change. It can be seen in the following figure that the parameters related to epoch are +1.