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

Overview

Redis-Sentinel is a high availability (HA) solution officially recommended by Redis. When Redis is used as a high-availability solution for Master-slave, if master goes down, Redis itself (including many of its clients) does not automatically switch between master and slave, and Redis-sentinel itself is also an independent process, which can monitor multiple master-slave clusters and switch itself when master is down.

Its main functions are as follows

Monitor from time to time whether redis is running well as expected.

If a redis node is found to be in trouble, you can notify another process (such as its client)

Can switch automatically. When a master node is unavailable, one of the multiple slave of the master (if there is more than one slave) can be elected as the new master, and the other slave nodes will change the address of the master it follows to the new address of the slave promoted to the master.

Configuration correction without failover

Even if no failover is currently in progress, sentinel still uses the current configuration to set the monitored master. In particular:

Nodes identified as slaves according to the latest configuration claim to be master (refer to the redis3 isolated by the network in the example above), and they will be reconfigured as the slave of the current master.

If the slaves connects to a wrong master, it will be corrected and connected to the correct master.

Slave Election and priority

When a sentinel is ready for failover and receives authorization from another sentinel, you need to elect a suitable slave as the new master.

The slave election will mainly assess the following aspects of slave:

Number of times disconnected from master

Priority of Slave

Subscript for data replication (data used to evaluate how much master slave currently owns)

Process ID

If a slave loses contact with master more than 10 times, and each time exceeds the configured maximum lost time (down-after-milliseconds option), and if the sentinel discovers that the slave is missing during the failover, then the slave will be considered by sentinel to be unsuitable for use as a new master.

A stricter definition is that if an slave is continuously disconnected for longer than

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

Will be considered disqualified from the election.

Only slave that meets the above criteria will be added to the list of master candidates and sorted according to the following order:

Sentinel will first sort according to the priority of slaves. The smaller the priority, the higher the ranking. ).

If the priority is the same, look at the replicated subscript, which receives more replicated data from master, which comes first.

If the priority and subscript are the same, choose the one with the lower process ID.

A redis, whether master or slave, must specify a slave priority in the configuration. Note that it is also possible for master to become slave through failover.

If a redis is configured with a slave priority of 0, it will never be selected as master. But it still replicates data from master.

Sentinel and Redis authentication

When a master is configured to require a password to connect, both the client and the slave need to provide a password when connecting.

Master sets its own password through requirepass and cannot connect to this master without providing a password.

Slave uses masterauth to set the password when accessing master.

But when using sentinel, because a master may become a slave and a slave may become a master, you need to set both configuration items.

Sentinel API

Sentinel runs on port 26379 by default, and sentinel supports the redis protocol, so you can use redis-cli clients or other available clients to communicate with sentinel.

There are two ways to communicate with sentinel:

One is to use the client directly to send messages to it.

The other is to use the publish / subscribe pattern to subscribe to sentinel events, such as failover, or an error running a redis instance, and so on.

Sentinel command

The legal commands supported by sentinel are as follows:

PING sentinel replied to PONG.

SENTINEL masters displays all master being monitored and their status.

SENTINEL master displays the information and status of the specified master

SENTINEL slaves displays all slave of the specified master and their status

SENTINEL get-master-addr-by-name returns the ip and port of the specified master. If failover is in progress or failover has been completed, the ip and port of the slave promoted to master will be displayed.

The SENTINEL reset resets the name to match the state information of all the master of the regular expression, knowing the previous state information, as well as the slaves information.

SENTINEL failover forces sentinel to execute failover and does not require the consent of other sentinel. However, the latest configuration is sent to other sentinel after failover.

Dynamically modify Sentinel configuration

Starting with redis2.8.4, sentinel provides a set of API to add, delete, and modify the configuration of master.

It is important to note that if you modify the configuration of a sentinel through API, sentinel will not tell other sentinel about the modified configuration. You need to manually send commands to modify the configuration to multiple sentinel.

Here are some commands to modify the sentinel configuration:

The command SENTINEL MONITOR tells sentinel to listen to a new master

SENTINEL REMOVE commands sentinel to give up snooping on a master

The SENTINEL SET command is much like the Redis CONFIG SET command, which is used to change the configuration of the specified master. Multiple are supported. Examples include the following:

SENTINEL SET objects-cache-master down-after-milliseconds 1000

Any configuration item that exists in the configuration file can be set with the SENTINEL SET command. This can also be used to set the properties of master, such as quorum (number of votes), without having to delete master and then re-add master. For example:

SENTINEL SET objects-cache-master quorum 5 add or remove Sentinel

Because of the sentinel automatic discovery mechanism, it is very easy to add a sentinel to your cluster, all you need to do is monitor to a Master, and then the newly added sentinel can get the information of other sentinel and all the slave of masterd.

If you need to add multiple sentinel, it is recommended that you add one after another to prevent problems caused by network isolation. You can add a sentinel every 30 seconds. Finally, you can use SENTINEL MASTER mastername to check whether all sentinel have monitored master.

Deleting a sentinel is a bit complicated: because sentinel never deletes a sentinel that already exists, even if it has been out of touch with the organization for a long time.

To delete a sentinel, follow these steps:

Stop the sentinel you want to delete

Send a SENTINEL RESET * command to all other sentinel instances. If you want to reset the sentinel on the specified master, just change the * number to a specific name. Note that you need to send one after another at an interval of not less than 30 seconds.

Check to see if all sentinels have the same current sentinel number. Use SENTINEL MASTER mastername to query.

Delete old master or unreachable slave

Sentinel will always record a Master slaves, even though slave has been out of touch with the organization for a long time. This is useful because the sentinel cluster must be able to reconfigure a slave that is available again.

Also, after failover, the invalid master will be marked as a slave of the new master, so that when it becomes available, the data will be copied from the new master.

Then, sometimes if you want to permanently delete a slave (maybe it used to be a master), you just need to send a SENTINEL RESET master command to all the sentinels, and they will update the slave in the list that replicates master data correctly.

Publish / subscribe

The client can send a command to subscribe to events on a certain channel to a sentinel, and when a specific event occurs, the sentinel notifies all subscribed clients. It should be noted that clients can only subscribe, not publish.

The name of the subscription channel matches the name of the event. For example, the channel named sdown will post all SDOWN-related messages to subscribers.

If you want to subscribe to all messages, simply use PSUBSCRIBE *

The following is the message format of all the messages you can receive if you subscribe to all the messages. The first word is the name of the channel, and the other is the format of the data.

Note: the format of the following instance details is:

@

If the redis instance is a master, messages after @ will not be displayed.

+ reset-master-when master is reset. + slave-when a slave is detected and added to the slave list. + failover-state-reconf-slaves-- when the Failover state becomes reconf-slaves, + failover-detected-- when failover occurs, + slave-reconf-sent-- sentinel sends the SLAVEOF command to reconfigure it + slave-reconf-inprog-- slave is reconfigured to the slave of another master, but data replication has not occurred. + slave-reconf-done-- when slave is reconfigured as slave for another master and data replication has been synchronized with master. -dup-sentinel-- when deleting redundant sentinel on a specified master (this event may occur when a sentinel is restarted). + sentinel-- when master adds a sentinel. + sdown-- when entering SDOWN state;-sdown-- when leaving SDOWN state. + odown-- when entering the ODOWN state. -odown-- when leaving the ODOWN state. + new-epoch-when the current configuration version is updated. + try-failover-meets the failover condition and is waiting for the election of other sentinel. + elected-leader-when elected to execute failover. + failover-state-select-slave-when you start to select a slave to be elected as the new master. No-good-slave-- there is no suitable slave to act as the new master selected-slave-- found a suitable slave to act as the new master failover-state-send-slaveof-noone-- when switching the identity of the slave selected as the new master. Failover-end-for-timeout-when failover fails due to a timeout. Failover-end-when failover completes successfully. Switch-master-when the address of the master changes. Usually this is the message that the client is most interested in. + tilt-- enter Tilt mode. -tilt-- exits Tilt mode. TILT mode

Redis sentinel is very dependent on system time, for example, it uses system time to determine how long an PING reply takes.

However, if the system time is modified, or if the system is very busy, or if the process is blocked, sentinel may not function properly.

When the stability of the system decreases, TILT mode is a kind of protection mode that sentinel can enter. When in TILT mode, sentinel will continue to monitor, but it will not take any other action, and it will not respond to commands such as is-master-down-by-addr, because its ability to detect failed nodes in TILT mode has become untrusted.

If the system returns to normal for 30 seconds, sentinel exits TITL mode.

-BUSY statu

Note: this feature has not been implemented yet.

When a script runs longer than the configured run time, sentinel returns a-BUSY error signal. If this happens before a failover is triggered, sentinel will send a SCRIPT KILL command, and if the script is read-only, it will be executed successfully.

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.