π’π’π’π£π£π£
Hello! Hello, everyone. I'm [one heart classmate], a highly motivated [Java domain blogger]! πππ
β¨ Writing style of [one heart students]: I like to explain every knowledge point in [easy to understand] writing, rather than using [tall and tall] official statement.
β¨ The field of the blog is the learning of back-end technology, and more back-end technology and learning experience will be continuously updated in the future.
β¨ If there is [xiaocute] who is interested in [back-end technology], please pay attention to [one heart students] πππ
β€οΈβ€οΈβ€οΈ Thank you, big and small! β€οΈβ€οΈβ€οΈ
catalogue
π΄ Problems in master-slave mode
π΄ Sentinel mode of solution
5, Sentinel Conf configuration item
6, Advantages and disadvantages of sentinel mode
1, Introduction
π΄ Problems in master-slave mode
In the master-slave replication mode, we can find that the system does not have the function of automatic recovery, so when the master server goes down, we need to manually switch a slave server to the master server. In this process, not only human intervention is required, but also the server will be unavailable for a period of time, and the data security can not be guaranteed. Therefore, the availability of master-slave mode is low and is not suitable for online production environment.
π΄ Sentinel mode of solution
Redis officially recommends a highly available scheme, namely Redis Sentinel sentinel mode, which makes up for the deficiency of master-slave mode. Sentinel obtains whether the working state of the host is normal through monitoring. When the host fails, sentinel will automatically Failover (i.e. Failover) and promote the monitored slave to the master server, so as to ensure the high availability of the system.
2, Sentinel mode principle
Sentinel mode is a special mode. Redis provides it with exclusive sentinel commands. It is an independent process and can run independently. The basic principle is that the Sentry can monitor multiple running redis instances by sending commands and waiting for the response of redis server.
Next, Sentinel is used to build the Redis cluster. The basic structure diagram is as follows:
In the process of the above figure, sentinels mainly play two important roles:
π First: the sentinel node will send a PING command to each Redis node once per second, and judge its operation status through the reply of the Redis node.
π Second: when the sentinel detects the failure of the master server, it will automatically select a machine from the slave nodes and promote it to the master server, and then use PubSub publish and subscribe mode to notify other slave nodes, modify the configuration file and follow the new master server.
3, Multi sentry mode
In the actual production situation, sentinel is the high availability guarantee of the cluster. In order to avoid accidents at a sentinel node, it is generally composed of 3 ~ 5 nodes, and each sentinel will monitor each other. In this way, even if individual nodes are connected, the cluster can still operate normally.
Its structure diagram is as follows:
3.1 working process
Let's explain the working process of multi sentry mode:
(1) Subjective offline
Subjective offline, applicable to master server and slave server. If the Sentinel node does not receive a valid reply from the target server within the specified time (configuration parameter: down after milliseconds), the server is judged as "subjective offline". For example, if Sentinel1 sends a PING command to the main service and does not receive a PONG reply from the main server within the specified time, Sentinel1 determines that the main server is "subjectively offline". At this time, the system will not immediately carry out the failover process, because Sentinel1 only subjectively believes that the main server is unavailable.
(2) Objective offline
Objective offline, only applicable to the primary server. Sentinel1 finds that the primary server has failed. It will ask other sentinel nodes to judge the status of the primary server through corresponding commands. If more than half of sentinel nodes think that the primary server is down, sentinel 1 node determines that the primary service is "objective offline".
(3) Vote
In voting, all sentinel nodes will elect sentinel 1 as the leading node to perform Failover operation according to the principle of who finds and who handles it through the voting mechanism. Sentinel1 node selects one of the best slave nodes as the master server according to certain rules, and then notifies the other slave nodes to change the configuration file through the publish and subscribe function to follow the new master server. So far, the master-slave switching operation is completed.
3.2 workflow summary
(1) Sentinel is responsible for monitoring the "health" status of the master and slave nodes. When the master node hangs up, an optimal slave node is automatically selected to switch to the master node.
(2) When the client connects to the Redis cluster, it will first connect to Sentinel, query the address of the master node through Sentinel, and then connect to the master node for data interaction.
(3) When the master node fails, the client will ask Sentinel for the address again, and Sentinel will tell the client the latest master node address. Therefore, the application can automatically complete the master-slave node switching without restarting.
4, Build sentinel mode
Since the sentinel mode is based on the master-slave mode, you need to build the master-slave mode first. The construction process of the master-slave mode is not explained here. You can see my last blog[ Redis -- master-slave mode of cluster].
(1) Configure sentinel sentry
Create a new profile redis sentinel Conf and configure as follows
port 26379 sentinel monitor myredis 127.0.0.1 6379 1
Profile description:
port 26379 #sentinel listening port, which defaults to 26379 and can be changed sentinel monitor <master-name> <ip> <redis-port> <quorum>
< master name >: the name of the server, which can be customized.
< IP >: represents the main server monitored.
< redis port >: represents the primary server port.
< quorum >: a number indicating how many sentinels think the primary server is down. For example, write 2, which means that only two or more sentinels think the primary server is unavailable will fail. It is usually considered that the host has been down when the number is half or more. The < quorum > needs to be set according to the number of sentinels.
(2) Start sentienl sentry
Execute command:
redis-sentinel sentinel.conf
Host: 6379
Slave: 63806381
(3) Stop primary server service
Let's simulate the unexpected downtime of the master service. First, terminate the Redis service of the master server directly, and then check whether the slave server is promoted to the master server.
Terminate the redis service of the master:
127.0.0.1:6379> shutdown
(4) Review the master-slave relationship
Then we went to check the sentry's log and found that our 6379 host was down, and after a while, we promoted our slave 6381 to the host through election!
We entered the client of 6381 to check its master-slave relationship, found that it has successfully become a master, and said that it has a slave 6380:
And our sentinel The conf configuration file has also changed:
(5) Host regression
If our original host 6379 comes back, it can only be merged into the new host as a slave.
Restore 6379 server:
redis-server redis79.conf
Check the master-slave relationship of 6379 and find that it has indeed become a slave:
(6) Open multiple Sentinels
If you want to enable multiple sentinels, you only need to configure multiple sentinels Conf file, and then change the port number to be consistent with others. Note that the < master name > server name should also be consistent, and then start it all. As follows:
Sentry 1:
port 26379 sentinel monitor myredis 127.0.0.1 6379 2
Sentry 2:
port 26380 sentinel monitor myredis 127.0.0.1 6379 2
Since < quorum > is set to 2, only when both sentinels find that the host is down will the rewrite election be conducted.
Note: if you want to stop sentinel mode, you only need to: Ctrl+C to stop.
5, Sentinel Conf configuration item
| Configuration item | Parameter type | explain |
|---|---|---|
| dir | File directory | The file storage directory of sentinel process service. The default is / tmp. |
| port | Port number | The process port number of the starting sentinel. The default is 26379. |
| sentinel down-after-milliseconds | < service name > < milliseconds (integer) > | Within the specified number of milliseconds, if the master node does not respond to the Sentinel's PING command, the sentinel considers that the server is offline subjectively, and the default time is 30 seconds. |
| sentinel parallel-syncs | < service name > < number of servers (integer) > | Specify how many Redis services can synchronize new hosts. Generally speaking, the smaller the number, the longer the synchronization time, and the larger the number, the higher the requirements for network resources. |
| sentinel failover-timeout | < service name > < milliseconds (integer) > | Specify the number of milliseconds allowed for failover. If it exceeds this time, it will be considered that the failover fails. The default is 3 minutes. |
| sentinel notification-script | < service name > < script path > | Script notification: configure the script to be executed when an event occurs. You can notify the administrator through the script. For example, send an email to notify relevant personnel when the system is not running normally. |
| sentinel auth-pass <master-name> <password> | < server name > < password > | If the master server sets a password, the sentry must also configure a password, otherwise the sentry cannot monitor the master and slave servers. This password is the same as the master server password. |
The detailed usage is as follows:
#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 #Master name can be the name of the master node named by itself, which 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 the 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 XXX #After a specified number of milliseconds, the master node does not respond to the sentry. At this time, the sentry subjectively thinks that the master node is offline, and the default is 30 seconds # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster 30000 # This configuration item specifies how many more slaves can synchronize the new master at the same time in the event of failover active / standby switching (election). The smaller the number, the longer it takes to complete the failover. However, if the number is larger, it means that more slaves are unavailable due to replication. You can set this value to 1 to ensure that only one slave can not process command requests at a time. # 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 synchronize data to the correct master. #3. The time required to cancel an ongoing failover. #4.When carried failover When, configure all slaves Point to new master Large time required. 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 to notify relevant personnel when the system is not running normally. #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.#The large execution time of a script is 60s. If it exceeds this time, the script will be terminated by a SIGKILL signal and then re executed. #Notification script: when sentinel has any warning level events (such as subjective failure and objective failure of redis instance, etc.), this script will be called. At this time, this script should notify the system administrator about the abnormal operation of the system through e-mail, SMS, etc. 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 If the script path is configured in the conf configuration file, you must ensure that the script exists in this path and is executable, otherwise sentinel cannot be started successfully. #Notification script # 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 of the change of the master address. #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>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) # 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
6, Advantages and disadvantages of sentinel mode
π΅ Advantages
1. Sentinel cluster, based on master-slave replication mode, has all the advantages of master-slave configuration.
2. Master slave switchable, failover, high availability system.
3. Sentinel mode is the upgrade of master-slave mode. It is more robust from manual to automatic.
π΅ shortcoming
1. Redis is not easy to expand online. Once the cluster capacity reaches the upper limit, online expansion will be very troublesome.
2. The configuration of sentinel mode is cumbersome.
Summary
The above is the explanation of [sentinel mode] in [Redis cluster] sorted out by [one heart students]. Compared with [master-slave mode], if the [host goes down], we no longer need to configure it manually, which greatly improves our [development efficiency]!
If this [article] is helpful to you, I hope I can praise [one heart classmate] ποΌ It's not easy to create. Compared with the official statement, I prefer to use [easy to understand] to explain every knowledge point. If there are cute people who are interested in [back-end technology], they are also welcome to pay attention β€οΈβ€οΈβ€οΈ [one heart students] β€οΈβ€οΈβ€οΈοΌ I will bring you great [harvest and surprise] ππ!