Redis high availability realizes master-slave sentinel cluster

Overview

Redis is highly available, mainly involving persistence, replication (master-slave replication), sentinel (automatic failover), clustering (write load balancing and single-machine storage capacity limitations).

Persistence is further expanded, here will only introduce other Redis solutions

1. Redis replication master-slave mode

1.1 How to enable

  • Configuration file: conf file configuration added replicaof <masterip><masterport>
  • Start command:redis-server xxx replicaof <masterip><masterport>
  • Client command: execute commands through the client replicaof <masterip><masterport>

1.2 Copy phase

  • establish connection
  • The slave node saves the IP and port of the master node;
  • Establish a socket connection and be responsible for subsequent copy work (receive RDB files, receive command propagation)
  • The master node sends a ping command to check whether the socket can process the request normally
  • Authentication;
  • The slave node sends the listening port number to the master node
  • Data synchronization, the slave node sends the psync command to the master node to decide whether to copy in full or in part
  • Command propagation, the slave node receives the write command sent by the master node; maintains the heartbeat PING and REPLCONF ACK

1.3 Copy method

1.3.1 Full copy

The master node receives the full copy request, executes bgsave to generate the RDB file, and uses a buffer (copy buffer) to record the write commands executed from now on.

Receive the RDB file from the node, clear the original old data, and restore to the state when the master node executes bgsave

The master node copies the buffer write commands to the slave node, and the slave node executes these commands

If AOF is turned on from the slave node, bgrewriteaof is triggered to ensure that the AOF file is consistent with the master node

1.3.2 Partial copy

The implementation of partial replication relies on three important concepts

Copy offset offset, the number of bytes passed by the master node and the slave node, determine whether they are the same, if they are different, take the data from the replication squeeze buffer to copy to the slave node, you can set repl-backlog-size to modify the buffer Zone size

Copy the backlog buffer, the FIFO queue maintained by the master node, the default is 1MB, and backup the data that the master node recently sent to the slave node. If the difference between the offset in the buffer of the master node and the offset in the buffer of the slave node is too large, a full copy is required.

Server running ID, Redis will automatically generate a random ID (runid) when it starts. When the first replication, the slave node saves the runid sent by the master node; when the connection is disconnected and reconnected, the slave node will send this runid to the master node. The master node then judges whether to perform partial replication. If the runid is the same as before, then judge whether the replication buffer of the master and slave nodes supports partial replication.

If the runid is different, then the full copy will be performed directly; if the buffer offset gap is too large, the full copy will also be performed

1.4 Problems in application

1.4.1 Delay causes inconsistency between master and slave

  • Optimize the network environment between the master and slave nodes (such as deployment in the same computer room);
  • Monitor the delay of the master and slave nodes (by offset). If the delay of the slave node is too large, notify the application to no longer read data through the slave node;
  • Use the cluster to expand the write load and read load at the same time.

2. Redis Sentianl sentinel mode

The sentinel mode is based on master-slave replication and focuses on high availability. When the master is down, the sentinel node will automatically upgrade the slave to the master and continue to provide services to the outside world.

2.1 Overview

Sentinel provides the following functions:

  • Monitoring: The sentinel will constantly check whether the master node and slave node are operating normally
  • Automatic failover: When the master node fails to work normally, the sentry will choose to upgrade the slave node with the highest priority to the master node, and copy other slave nodes from the new master node
  • Configuration provider: When the client is initialized, the address of the master node can be found through the sentinel
  • Notification: The sentinel can notify the client of the result of the failover

Timed tasks: 3 timed tasks are maintained in the sentinel node. Send the info command to the master node to obtain the latest master-slave structure; obtain the information of other sentinel nodes through the publish and subscribe function; perform heartbeat detection by sending a ping command to other nodes to determine whether to go offline.

Subjective offline: In the heartbeat detection task, if other nodes do not respond for more than a certain period of time, the node that has not responded is considered to be offline.

Objective offline: After the sentinel node objectively goes offline to the master node , it will ask other sentinel nodes about the status of the master node through the sentinel is-master-down-by-addr command. If it is judged that the sentinel node offline reaches a certain value, Then the main node is objectively offline. The concept that the master node has when it is objectively offline is used for subsequent failover; while the slave node or sentinel node fails, and subsequent objective offline and failover will not be performed.

Sentinel leader node: Multiple sentries will elect a sentinel as the leader, which will perform subsequent failovers. The election algorithm is not Raft.

Failover election rules:

  1. Troubleshoot unhealthy slave nodes that have been offline
  2. Choose the one with the highest priority, which is controlled by the parameter replica-priority
  3. If 2 is the same, choose the one with the largest offset
  4. If 3 is the same, choose the one with the smallest runid

3. Redis Cluster cluster mode

image.png


Redis Cluster uses virtual slot partitioning and maps the Key to 16384 slots.

Among them, the Master Node is responsible for processing client read and write requests, and the Replica Node is responsible for replicating to the master node.

The slave node of the cluster will only replicate the master node by default, but will not process any command request sent by the client; whenever the slave node receives a command request, it will only send a redirect message to the client

reference

After reading this article, you are basically done with Redis master-slave replication