(automatic election mode)
The method of master-slave switching technology is: when the master server is down, a slave server needs to be manually switched to the master server, which requires manual intervention, which is laborious and laborious, and the service will not be available for a period of time. This is not a recommended way. More often, we give priority to Sentinel mode. Redis has officially provided Sentinel architecture since 2.8 to solve this problem.
The automatic version of Mou Chao's usurpation can monitor whether the host fails in the background. If it fails, it will automatically convert from the library to the main library according to the number of votes.
Sentinel mode is a special mode. Firstly, Redis provides sentinel commands. Sentinel is an independent process. As a process, it will run independently. The principle is that the sentinel sends a command and waits for the response of the Redis server, so as to monitor multiple running Redis instances.
The sentry here has two functions
- Send commands to the master server and return them to the slave server through Redis.
- When the sentinel detects that the master is down, it will automatically switch the slave to the master, and then notify other slave servers through publish subscribe mode to modify the configuration file and let them switch hosts.
However, there may be problems when a sentinel process monitors the Redis server. Therefore, we can use multiple sentinels for monitoring. Monitoring will also be carried out among various sentinels, thus forming a multi sentinel mode.
Assuming that the main server goes down, sentry 1 detects this result first, and the system will not fail immediately. Sentry 1 only subjectively thinks that the main server is unavailable, which becomes a subjective offline phenomenon. When the following sentinels also detect that the primary server is unavailable and the number reaches a certain value, a vote will be held between sentinels. The voting result is initiated by a sentinel for "failover". After the switch is successful, each sentinel will switch the host from the server monitored by themselves through the publish and subscribe mode. This process is called objective offline.
Our current state is one master and two slaves!
- Configure sentinel profile sentinel conf
# sentinel monitor the monitored name host port 1 sentinel monitor myredis 127.0.0.1 6379 1
The following number 1 means that the host hangs up. slave votes to see who takes over as the host. The one with the most votes will become the host!
- Activate the sentry!
[root@kuangshen bin]# redis-sentinel kconfig/sentinel.conf 26607:X 31 Mar 2020 21:13:10.027 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo 26607:X 31 Mar 2020 21:13:10.027 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=26607, just started 26607:X 31 Mar 2020 21:13:10.027 # Configuration loaded
If the Master node is disconnected, a server will be randomly selected from the slave at this time! (there is a voting algorithm in it!)
If the master comes back at this time, it can only be merged into the new master as a slave. This is the rule of sentinel mode!
- Sentinel cluster is based on master-slave replication mode. It has all the advantages of master-slave configuration
- Master-slave can be switched, and the failure can be transferred, so the availability of the system will be better. 3. Sentry mode is the upgrade of master-slave mode, from manual to automatic, which is more robust!
- Redis is not easy to expand online. Once the cluster capacity reaches the upper limit, online expansion will be very troublesome!
- The configuration of sentinel mode is actually very troublesome. There are many choices!
All configurations of sentinel mode!
# Example sentinel.conf # The port on which the sentinel sentinel instance runs is 26379 by default port 26379 # sentinel's working directory dir /tmp # The ip port of the redis master node monitored by sentry sentinel # The master name can be named by itself. The name of the master node can only be composed of letters A-z, numbers 0-9 and the three characters ". -" form. # How many sentinel sentinels are configured in the quorum? If the sentinel sentinels agree that the master node is lost, then it is objectively considered that the master node is lost # sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2 # When the requirepass foobared authorization password is enabled in the Redis instance, all clients connecting to the Redis instance must provide it password # Set the password of sentinel sentinel connecting master and slave. Note that the same authentication password must be set for master and slave # sentinel auth-pass <master-name> <password> sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # After the specified number of milliseconds, the master node does not respond to the sentinel sentinel. At this time, the sentinel subjectively thinks that the master node goes offline for 30 seconds by default # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000 # This configuration item specifies the maximum number of slave s that can synchronize the new master at the same time when a failover active / standby switch occurs, The smaller the number, the better failover The longer it takes, But if this number is bigger, it means more slave because replication Not available. You can ensure that there is only one at a time by setting this value to 1 slave Is in a state where the command request cannot be processed. # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster 1 # Failover timeout can be used in the following aspects: #1. The interval between two failover s of the same sentinel to the same master. #2. When a slave synchronizes data from a wrong master, the time is calculated. Until the slave is corrected to the correct master When synchronizing data in. #3. The time required to cancel an ongoing failover. #4. During failover, configure the maximum time required for all slaves to point to the new master. But even after this timeout, slaves Will still be correctly configured to point to master，But don't press parallel-syncs Here comes the configured rule # The default is three minutes # sentinel failover-timeout <master-name> <milliseconds> sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION #Configure the script to be executed when an event occurs. You can notify the administrator through the script. For example, send an email notification when the system is not running normally Relevant personnel. #There are the following rules for the running results of scripts: #If the script returns 1 after execution, the script will be executed again later. The number of repetitions is currently 10 by default #If the script returns 2 after execution, or a return value higher than 2, the script will not be executed repeatedly. #If the script is terminated due to receiving the system interrupt signal during execution, the behavior is the same as when the return value is 1. #If the execution time of the script exceeds 60s, the script will be re executed by a signal. #Notification script: when any warning level event occurs in sentinel (such as subjective failure and objective failure of redis instance, etc.), The script will be called. At this time, the script should be sent by email, SMS And other ways to inform the system administrator about the abnormal operation of the system Rest. When calling the script, two parameters will be passed to the script, one is the type of event and the other is the description of event. If sentinel.conf match If the script path is configured in the configuration file, you must ensure that the script exists in this path and is executable, otherwise sentinel nothing The normal startup of the method is successful. #Notification script # shell programming # sentinel notification-script <master-name> <script-path> sentinel notification-script mymaster /var/redis/notify.sh # Client reconfiguration master node parameter script # When a master changes due to failover, this script will be called to notify the relevant clients that the master address has been changed Changed information. # The following parameters will be passed to the script when calling the script: # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # At present, < state > is always "failover", # < role > is one of "leader" or "observer". # The parameters from IP, from port, to IP and to port are used to communicate with the old master and the new master (i.e. the old slave) Believable # This script should be generic and can be called multiple times, not targeted. # sentinel client-reconfig-script <master-name> <script-path> sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # It is generally provided by the operation and maintenance department Set!