This is the 24th day of my participation in the More text Challenge. For more details, see more text Challenge

Related articles

Redis combat summary: Redis combat

preface

In the Redis cluster we talked about, after the host is disconnected, we have to manually set up another host from the host! It’s not smart! In practice, we use sentinel mode to automatically switch the host.

Colloquial point, is to choose their own ‘big brother’!

An overview,

The method of the master/slave switchover technology is as follows: When the primary server is down, a slave server needs to be manually switched over to the primary server. This requires manual intervention and laborious work, and also causes services to be unavailable for a period of time. This is not a recommended approach, more often than not, we prioritize sentry mode.

Redis has officially provided the Sentinel architecture since 2.8 to address this issue.

An automatic version of schemausurp, which can monitor whether the host is faulty in the background and automatically convert the slave to master based on the number of votes.

Sentinel mode is a special mode, first Redis provides sentinel command, sentinel is a separate process, as a process, it will run independently. The idea is that sentry monitors multiple running Redis instances by sending commands and waiting for the Redis server to respond.

2. Configure sentries

1. Add sentinel configuration file sentinel.conf

The contents are as follows:

# Sentinel Monitor Name of monitored host port1(The representative automatically votes for big brother!) sentinel monitor myredis127.0. 01. 6379 1
Copy the code

2. Activate the sentry

Command:

Redis-sentinel dyjConfig/sentinel.conf #Copy the code

After successful startup, see figure below!

3. Prerequisites

Open a host, two slave machine, a master two slave when the most basic!

4, test host downtime after the automatic selection of big brother, if the host back at this time, can only be merged to the new host, as a slave machine, this is the rule of sentinel mode!

Wait for sentry’s default configuration time to be 30 seconds!

Check redis information again:

You can find 8381 into the host, 8380 is still from the machine!

Let’s try connecting the Big Brother host! You can find that 6379 becomes from the machine, from the big brother into the little brother!

And the 6381 successfully become the mainframe mobile phone!

Third, summary

1, the advantages of

① Sentinel cluster, based on the primary-slave replication mode, has all the advantages of the primary-slave configuration

(2) The primary and secondary services can be switched over, and the faults can be transferred. The system availability is better

③ Sentry mode is the upgrade of master and slave mode, manual to automatic, more robust!

2 and disadvantages

①Redis is not good online expansion, once the cluster capacity reaches the upper limit, online expansion is very troublesome!

② Implement the configuration of sentry mode is actually very troublesome, there are many choices!

3. Note: All of the above configurations are based on the premise of single machine cluster. Interested can build their own formal cluster under the multi-sentinel mode to monitor! The diagram below:

4, sentry configuration file parsing (found online, only need to pay attention to a few key points!) :

# Example sentinel.conf # Sentinel instance running on the default port26379 
port 26379# master-name Specifies the IP address of the redis primary node monitored by Sentinel. # master-name Specifies the IP address of the redis primary node monitored by Sentinel0-9, these three characters". - _"Composition. # sentinel monitor <master-name> < IP > <redis-port> <quorum> sentinel monitor mymaster127.0. 01. 6379 2When the RequirePass Foobared authentication password is enabled in the Redis instance, all clients connected to the Redis instance will need to provide the password Auth-pass <master-name> <password> Sentinel auth-pass mymaster MySUPER--secret-0123passw0rd # Specifies how many milliseconds after sentinel has not been answered by the master node In this case, the sentinel considers the primary node offline by default30Second # sentinel down-after-milliseconds <master-name> <milliseconds> sentinel down-after-milliseconds mymaster30000# This configuration item specifies the maximum number of slaves that can synchronize a new master at the same time when a failover occurs. # The smaller the number, the longer it takes to complete a failover. This means that more and more slaves are unavailable because of Replication. This can be done by setting this value to1To ensure that only one slave at a time is in a state unable to process command requests. # sentinel parallel-syncs <master-name> <numslaves> sentinel parallel-syncs mymaster1Failover timeout can be used in the following ways1.The interval between two failover of the same Sentinel and the same Master. #2.When a slave synchronizes data from an incorrect master, the time is calculated. Until the slave is corrected to synchronize data to the correct master. #3.The time required when you want to cancel an ongoing failover. #4.When failover is performed, configure the maximum time required for all Slaves to point to the new Master. However, even after this timeout, slaves will still be properly configured to point to the Master, # Default three minutes # Sentinel failover <master-name> Sentinel failover mymaster180000Configure the SCRIPTS that need to be executed when an event occurs. You can use SCRIPTS to notify administrators, such as email notification when the system is not working properly. # Return if the script is executed1, the script will be executed again later, the current default is10Return if the script is executed2, or better than2For a higher return value, the script will not be executed repeatedly. If the script was terminated during execution due to an interrupt signal received from the system, the same return value is1Does the same thing. 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 then re-executed. # Notification script: Sentinel will call this script when there is any warning level event (such as subjective and objective failure of Redis instances, etc.). This script should notify the system administrator of the abnormal system operation via email, SMS, etc. When the script is invoked, it is passed two arguments, the type of the event and a description of the event. If the script path is configured in the sentinel.conf configuration file, ensure that the script exists in the path and can be executed. Otherwise, Sentinel cannot be started successfully. # Sentinel Notification-script <master-name> <script-path> Sentinel Notification-script mymaster /var/redis/notify.sh # When a master is changed due to a failover, this script will be called to notify the client that the master address has changed. # The following arguments will be passed to the script when it is invoked: # <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # <role> is one of the "leaders" or "observers". This script is supposed to 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

I see no ending, but I will search high and low

If you think I blogger writes good! Writing is not easy, please like, follow, comment to encourage the blogger ~hahah