Shulou(Shulou.com)05/31 Report--

This article introduces the knowledge of "how to understand the Sentinel Mode in Redis". Many people will encounter this dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

In Redis master-slave mode, once the master node fails, the slave node can be promoted to the master node, and at the same time, the client should be informed to update the master node address, which is generally not feasible. Therefore, Redis provides a Redis Sentinel sentinel mechanism to solve this problem.

The problem of master-slave replication

1. The benefits of master-slave replication

If the master node fails, the slave node will be upgraded to the master node.

Expand the reading ability of the master node and share the pressure of the master node

two。 Existing problems

The process of upgrading the master node from the slave node requires human intervention, while changing the client Redis service address

The write capacity and storage capacity of the master node are limited by a single machine.

Performance impact: when Redis replication is interrupted, the slave node initiates psync. At this time, if the synchronization is not successful, the full synchronization will be carried out, and the full backup of the main database may cause stutters in milliseconds or seconds.

Sentinel implementation principle 1. Some concepts and main functions

Monitoring: constantly check whether the master-slave server is running properly

Notification: if one node fails, other nodes will be notified

Automatic failover: when the master node does not work properly, it will automatically fail over and upgrade from one of the slave nodes to the master node.

Configuration provider: instead of configuring a single node, the client is a collection of Sentinel nodes

Subjective referral and objective referral

Generally speaking, each Sentinel node constantly sends PING to other Sentinel nodes and Redis nodes to confirm whether it is online by replying or not.

Subjective referral: applicable to all master and slave nodes. If Sentinel does not receive a valid reply from the target node within down-after-milliseconds milliseconds, the node will be determined to be subjectively offline.

Objective offline: it is only used for the primary node. If the primary node fails, the Sentinel node will ask other Sentinel nodes to judge the status of the node through the sentinel is-master-down-by-addr command. If more than the number of nodes determines that the primary node is unreachable, the Sentinel node will determine that the primary node is objective offline.

two。 working principle

Each Sentinel sends PING instructions to other Sentinel nodes and Redis master-slave nodes at a frequency of once / s.

If an instance has a distance from the last valid reply PING command to down-after-milliseconds, the instance is marked by Sentinel as subjectively offline.

If a primary server is marked as subjectively offline, then all Sentinel nodes of the primary server are being monitored to confirm that the primary server has entered the subjective offline state once per second.

If more than the number of nodes determines that the primary node is unreachable, the Sentinel node will determine that the primary node is objective offline.

When the primary server is marked as objective offline, Sentinel sends INFO commands to the desired server of the offline server, changing from 10 / s to 1 / s.

The status of the master node is negotiated between the Sentinel nodes. If the master node is in the SDOWN state, the vote automatically selects a new master node. Point the remaining slave node to the new master node for data replication.

When there is not enough Sentinel to allow the primary server to go offline, the objective offline state of the primary server will be removed. When the primary server returns a valid reply to the Sentinel PING command, the subjective offline state of the primary server is removed.

3. Message loss

Redis adopts the master-slave replication mode. Once the master node dies, the data being synchronized by the slave node may be lost. The greater the delay, the more data is lost.

Redis provides two configuration items to restrict the request processing of the main library, namely min-slaves-to-write and min-slaves-max-lag.

Min-slaves-to-write: this configuration item sets the minimum number of slave libraries that the master database can synchronize.

Min-slaves-max-lag: this configuration item sets the maximum delay (in seconds) for sending ACK messages from the slave to the master during data replication between the master and slave libraries.

The requirement of the combination of these two configuration items is that there are at least N slave libraries connected to the master library, and the delay of ACK messages when copying data with the master library cannot exceed T seconds, otherwise, the master library will no longer receive requests from the client.

Therefore, Sentine cannot guarantee that messages will not be lost at all, but it can also ensure that messages are not lost as much as possible.

This is the end of "how to understand the Sentinel Mode in Redis". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.