Shulou(Shulou.com)06/03 Report--

Redis's sentinel mechanism is an officially recommended high availability (HA) solution. When we use the master-slave structure of Redis, if the master node dies, we cannot automatically switch between master and slave and notify the client master node to go offline.

The Redis-Sentinel mechanism has three main functions:

(1) Monitoring: constantly monitoring whether the Redis master-slave node is installed and expected to run

(2) reminder: if there is a problem with the operation of Redis, you can notify the client or cluster administrator according to the configuration items in the configuration file.

(3) automatic failover: when the master node is offline, the sentry can select a master node from multiple slave nodes of the master node and update the configuration file and other master node information of the slave node.

Let's first talk about the configuration items in the configuration file sentinel.conf of the Sentinel mechanism.

The port running by # Example sentinel.conf # Sentinel sentinel instance defaults to 26379port 26379 # Sentinel sentinel's working directory dir / tmp # the ip port # master-name of the redis master node monitored by Sentinel sentinel can only be named by the letter AMEZ, the number 0-9, and the three characters ".-_". # quorum when these quorum numbers sentinel Sentinel thinks that the master master node is missing, then it objectively considers that the master node is missing # sentinel monitor sentinel monitor mymaster 127.0.0.1 6379 2 # when the requirepass foobared authorization password is opened in the Redis instance, all clients connecting to the Redis instance must provide the password # set the password of the sentry sentinel connection master-slave note that the verification secret must be the same as the master-slave setting. Code # sentinel auth-pass sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # specifies how many milliseconds after the primary node does not answer the Sentinel sentinel. At this time, the Sentinel subjectively thinks that the primary node is offline by default of 30 seconds # sentinel down-after-milliseconds sentinel down-after-milliseconds mymaster 30000 # this configuration item specifies the maximum number of slave that can synchronize the new master at the same time when the failover master / standby switch occurs. The smaller the number, the longer it takes to complete the failover, but the higher the number, the more slave is unavailable because of the replication. You can ensure that only one slave at a time is unable to process command requests by setting this value to 1. # sentinel parallel-syncs sentinel parallel-syncs mymaster 1 # timeout failover-timeout for failover can be used in the following aspects: # 1. The interval between two failover of the same sentinel to the same master. # 2. When a slave synchronizes data from an incorrect master to start calculating the time. Until slave is corrected to synchronize data to the correct master. # 3. The time it takes to cancel an ongoing failover. # 4. When failover, the maximum time it takes to configure all slaves to point to the new master. However, even after this timeout, slaves will still be correctly configured to point to master, but it will not follow the rules configured by parallel-syncs. # default three minutes # sentinel failover-timeout sentinel failover-timeout mymaster 180000 # SCRIPTS EXECUTION # configure the script that needs to be executed when an event occurs. You can notify the administrator through scripts, such as emailing the relevant personnel when the system is not working properly. # there are the following rules for the running result of the script: # if the script returns 1 after execution, the script will be executed again later. The number of repetitions currently defaults to 1. If the script returns 2 after execution, or a higher return value than 2, the script will not be repeated. # if the script is terminated during execution due to the receipt of a system interrupt signal, it will be the same as returning a value of 1. The maximum execution time of a script is 60s. If this time is exceeded, the script will be terminated by a SIGKILL signal and then re-executed. # Notification script: when any warning level event occurs in sentinel (such as subjective failure or objective failure of redis instance, etc.), this script will be called. In this case, the script should notify the system administrator by email, SMS, etc., about the abnormal operation of the system. When the script is called, two parameters are passed to the script, one is the type of the event, and the other is the description of the event. If this script path is configured in the sentinel.conf configuration file, you must ensure that the script exists in this path and is executable, otherwise sentinel will not start successfully. # Notification script # sentinel notification-script sentinel notification-script mymaster / var/redis/notify.sh # client reconfigure master node parameter script # when a master changes due to failover, this script will be called to notify the relevant client that the master address has changed. # the following parameters will be passed to the script when the script is called: # # is always "failover" at present, and # is one of "leader" or "observer". # the parameters from-ip, from-port, to-ip, to-port are used to communicate with the old master and the new master (that is, the old slave). This script should be generic, can be called multiple times, and is not targeted. # sentinel client-reconfig-script sentinel client-reconfig-script mymaster / var/redis/reconfig.sh

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.