The guard mode

In master-slave replication when our host went down, we had to manually set up a host was very troublesome. Sentinel mode solves this problem by automatically selecting a host.

The background monitors the status of the host, and if the host fails, the host can be automatically selected from the machine according to the number of votes.

Sentinel is a separate process that determines failure by sending commands and waiting for the Redis server to respond

The role of sentinels

  1. Send a command to the server (host, slave) back. Monitor its status
  2. When an outage is detected, one slave machine is automatically repaired to the host machine, and then the other slave machines are notified by publishing and subscribing mode to modify their configuration files and let them switch hosts.

A single sentry can fail, so we usually need multiple sentries to monitor each other in a multi-sentry mode

process

If Sentry 1 thinks the host is down (subjective offline), he will not switch the host immediately. Sentinel 1 alone is not enough. When the sentry behind also thinks the host is down, and reaches a certain number. A random sentry initiates a vote, performs a failover to change a slave machine to a host, and notifies other slave machines to switch to a host by publishing and subscribing. After that, even if the original host is restored, it can only become a slave machine.

use

  1. Create and write sentinel.conf

Part of the configuration

port 16379  # Sentry port numberDaemonize Yes Sentinel Monitor Master 127.0.0.1 6379 1# Monitor master 1 to re-select host after outage
protected-mode no
logfile "/usr/local/bin/sentinel-1/sentinel-1.log" 
Copy the code
  1. Start the
redis-sentinel sentinel.conf
Copy the code

Complete configuration

Quote: blog.csdn.net/newbie_9074…

# Example sentinel.conf
 
# Sentinel instance runs on port 26379 by default
port 26379
 
# Sentinel's working directory
dir /tmp
 
IP port of the redis master node monitored by Sentinel
# master-name Specifies the name of the master node that can be named by itself. The name can contain only letters a-z, numbers 0-9, and ".-_".
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 192.168.1.108 6379 2# When requirePass Foobared is enabled in the Redis instance, all clients connected to the Redis instance must provide the password
Note that the primary and secondary authentication passwords must be the same as the primary and secondary authentication passwords
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# specifies the number of milliseconds after the primary node does not answer sentinel sentinel at this point the sentinel subjectively considers the primary node offline by default 30 seconds
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
 
# This configuration item 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,
# But the larger the number, the more slaves are unavailable due to 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 can be used in the following ways:
#1. The interval between two failover operations for the same sentinel and the same master.
#2. Start time counting when a slave synchronizes data from an incorrect master. Until the slave is corrected to synchronize data to the correct master.
#3. The time required 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 not according to the rules configured for parallel Syncs
Three minutes by default
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
 
# SCRIPTS EXECUTION
 
# Configure the script that needs to be executed when an event occurs. You can use the script to notify the administrator, for example, send an email to inform related personnel when the system is not working properly.
The following rules apply to the results of a script:
If the script returns 1 after execution, the script will be executed again later. The current default is 10
If the script returns 2 after execution, or a value higher than 2, the script will not be executed again.
If the script is aborted during execution due to a system interrupt signal, it behaves the same as if the value is 1.
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.
 
# notification script: This script will be called when sentinel has any warning level events (such as subjective and objective failures of redis instances, etc.).
The script should then notify the system administrator of system malfunctions via email, SMS, etc. When the script is called, it is passed two parameters,
# One is the type of event,
# One is the description of the event.
If the sentinel.conf configuration file is configured with the script path, then the script must exist in the path and be executable, otherwise sentinel will not start successfully.
Notification script
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
The client reconfigures the master node parameter script
This script will be called when a master changes due to a failover, notifying the client that the master address has changed.
The following arguments will be passed to the script when it is called:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# currently 
      
        always "failover",
      
# 
      
        is either "leader" or "observer".
      
The from-ip, from-port, to-ip, to-port parameters are used to communicate with the old master and new master(i.e. the old slave)
# This 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