Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What is the master-slave synchronization and sentinel mode in Redis

2025-04-12 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

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

This article mainly explains "what is the master-slave synchronization and sentinel mode in Redis". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Next, let the editor take you to learn "what is the master-slave synchronization and sentinel mode in Redis?"

Master-slave synchronization

Master-slave synchronization (master-slave replication) is not only the cornerstone of Redis highly available services, but also the most basic of multi-machine operation.

We call the node where the primary data is stored (master) and the other replica nodes that replicate the data of the master node (slave), as shown in the following figure:

In Redis, a master node can have multiple slave nodes, and one slave node can also be the master node of other servers, as shown in the following figure:

The advantages of master-slave synchronization

Master-slave synchronization has the following three advantages:

Performance: with master-slave synchronization, you can assign the query task to the slave server and use the master server to perform write operations, which greatly improves the efficiency of running the program and allocates all the pressure to each server.

High availability: when there is master-slave synchronization, when the master server node goes down, the slave node can be quickly promoted to the master node, saving valuable time for the downtime recovery of the Redis server

Prevent data loss: when the master server disk is broken, other slave servers still retain the relevant data, so that all data will not be lost.

Turn on master-slave synchronization

Running settings from the server

While Redis is running, we can use the replicaof host port command to set ourselves as the slave server of the target IP.

If the master service sets a password, you need to enter the password of the master server from the slave server and use the config set masterauth master service password command

After executing the replicaof command, the slave server's data is emptied and the master service synchronizes its copy of the data to the slave server.

Set up the slave server at startup

You can use the command redis-server-- port 6380-- replicaof 127.0.0.1 6379 to set yourself as a slave to the target server.

Data synchronization

Complete data synchronization

When there is a new slave server connection, in order to ensure the consistency of multiple databases, the master server will execute a bgsave command to generate a RDB file, and then send it to the slave server in the way of Socket. After receiving the RDB file from the slave server, all the data will be loaded into its own program to complete a full data synchronization.

Partial data synchronization

Before Redis 2.8, every time the slave server goes offline and then comes back online, the master server performs a full data synchronization, and then if this happens in a relatively short offline time, it is very clumsy and uneconomical to synchronize all data with only a small amount of data out of sync, which is optimized in Redis 2.8s.

The optimization method of Redis 2.8is that when the slave service is offline, the master server will store the offline write commands in a queue of a specific size, which can guarantee the first-in-first-out execution order. When the slave server rewrites and resumes the online service, the master service will determine whether the commands are still in the queue during the offline period, and if so, send the data in the queue directly to the slave server. This avoids the waste of resources for full synchronization.

The queue size for storing offline commands defaults to 1MB, and users can modify the configuration item repl-backlog-size for the queue size.

Diskless data synchronization

In the first master-slave connection, a RDB file will be generated first, and then the RDB file will be sent to the slave server. If the master server is a non-solid state disk, the system's IUniver O operation is very high.

Redis 2.8.18 added diskless copy function, diskless copy function will not create RDB files locally, but will derive a child process, and then by the child process through Socket, directly write the RDB file to the slave server, so that the master server can complete the data synchronization with the slave server without creating the RDB file.

To use the no-copy feature, simply set the value of the configuration item repl-diskless-sync to yes, which defaults to no.

Query the role of the server

Use the role command to query the master-slave role information of the current server.

Turn off master-slave synchronization

You can use the replicaof no one command to stop replication from the server.

After executing the replicaof no one command, I changed from server to master server.

The conversion of the server type will not affect the data, and the data of this server will be retained.

Matters needing attention

Data consistency problem

When the slave server has completed the data synchronization with the master server, the new commands will be sent to the slave server asynchronously. In this process, there will be temporary data inconsistency in the master-slave synchronization. For example, if the master server goes down before the asynchronous synchronization occurs, it will cause data inconsistency.

Read-only from the server

By default, the master server in replication mode can perform both write and read operations, while the slave server can only perform read operations.

You can execute the config set replica-read-only no command on the slave server to turn on write mode from the slave server, but note the following:

Data written on the slave server will not be synchronized to the master server

The data on the master server can overwrite the slave server when the key value is the same.

During a full data synchronization, the slave server data is emptied.

Copy changes to the command

The copy command used before Redis 5.0is slaveof, but it was changed to replicaof after Redis 5.0.We should try to use replicaof in the higher version (Redis 5+), because the slaveof command may be abandoned at any time.

Sentinel mode

Master-slave replication mode is the basis of Redis multi-machine operation, but this mode itself has a fatal problem. When the master node collapses, it needs human intervention to restore the normal use of Redis.

We need an automated tool, Redis Sentinel (Sentinel Mode), to automate manual processes and give Redis automatic disaster recovery (failover) capabilities.

The Sentinel is equivalent to a monitoring task on the master-slave server. Once the master server is found to be down, quickly start the corresponding rules to upgrade a slave server to the master server, without human intervention, more stable and faster.

The minimum allocation unit of Redis Sentinel is one master and one slave.

Redis Sentinel building

To start Sentinel with the command. / src/redis-sentinel sentinel.conf, you must set up a sentinel.conf file when you start it, and this configuration file must contain the information of the listening master node:

Sentinel monitor master-name ip port quorum

Where:

Master-name means to give the monitored master section a name.

Ip represents the IP of the primary node

Port represents the port of the primary node

Quorum means to confirm the number of Sentinel of the primary node offline. If quorum is set to 1, as long as a Sentinel determines that it is offline, it can be confirmed that it is really offline.

If the primary node server Redis has a password, the sentinel.conf must contain the following:

Sentinel monitor mymaster 127.0.0.1 6379 1sentinel auth-pass mymaster pwd654321

Start the Sentinel cluster

We will not start only one Sentinel in the production environment, because if we start a Sentinel, if it goes down unfortunately, it will not be able to provide automatic disaster recovery service, which is not in line with our purpose of high availability, so we will start multiple Sentinel on different physical machines to form Sentinel clusters to ensure the high availability of Redis services.

The way to start a Sentinel cluster is simple, just like the way we started a single server above, we only need to monitor multiple Sentinel to a master server node, then multiple Sentinel will automatically discover each other and form a Sentinel cluster.

In general, if the number of Sentinel clusters is an odd number greater than 1, the parameter of quorum is set to half plus 1. For example, 5 is set to 3 and 7 is set to 4.

Two concepts: subjective referral and objective referral.

When a Sentinel in a Sentinel cluster thinks that the primary server has been offline, it marks the primary server as subjective offline (Subjectively Down,SDOWN), and then asks other Sentinel in the cluster whether it also thinks that the server has been offline. When the number of Sentinel that agrees that the primary server has been offline reaches the number specified by the quorum parameter, Sentinel will mark the corresponding primary server as objective offline (Objectively down,ODOWN). And then start failing it over.

Master service election rules

New primary node election priority setting

The replica-priority option in redis.conf sets the priority of running for the new primary node. Its default value is 100. its maximum value is 100. the smaller the value, the higher its weight.

New election rules for master node

The election of the new master node will exclude the unqualified slave nodes, and then the remaining slave nodes will be selected according to priority.

Slave nodes with the following conditions are excluded:

Eliminate all suspicions that have been offline and have not replied to heartbeat testing for a long time from the server

Exclude all slave servers that have not communicated with the master server for a long time and whose data status is out of date.

Exclude all servers with a priority (replica-priority) of 0.

Eligible slave node election order:

The slave node with the highest priority will be the new master node.

If the priority is equal, the replication offset is judged, and the slave node with the largest offset wins.

If both of the above conditions are the same, select the minimum ID randomly generated by the Redis runtime as the new primary server.

The old master node is back online.

If the previous master node comes back online, it will run as a slave node in master-slave server mode.

The working principle of Sentinel

First, each Sentinel sends a PING command to known master servers, slave servers, and other Sentinel instances at a frequency of once per second.

If the last valid reply to the PING command takes longer than the value configured by down-after-milliseconds (the default is 30s), then this instance will be 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 indeed entered the subjective offline state at a frequency of once per second.

If a sufficient number of Sentinel (quorum configuration values) agree with this judgment within a specified time frame, then the primary server is marked as objective offline. At this point, all Sentinel will automatically select a new master node according to the rule negotiation.

Note: a valid PING reply can be: + PONG,-LOADING, or-MASTERDOWN. If the return value is not the above three replies, or if the PING command is not replied within the specified time, then Sentinel considers the reply returned by the server to be invalid (non-valid).

Sentinel command operation

Instead of just one server, Sentinel can monitor multiple primary nodes. To monitor multiple master nodes, you only need to set multiple sentinel monitor master-name ip port quorum in the configuration file, and we use master-name to distinguish between different master nodes.

Query the information of all monitored master servers

Sentinel masters

Query the information of a master node

Sentinel master master-name

View the IP and port of a master node

Sentinel get-master-addr-by-name master-name

Query the information of slave nodes

Sentinel replicas mymaster or sentinel slaves master-name

Query other Sentinel information in the Sentinel cluster

Sentinel sentinels master-name

Check the number of Sentinel available

Sentinel ckquorum master-name

Forced failover

Sentinel failover master-name

Modify configuration information online

If you need to modify the configuration file of Sentinel before Redis 2.8.4, you need to restart Sentinel.

After Redis 2.8.4, we can modify the configuration file online.

Increase the monitoring master node

The sentinel monitor mymaster IP Port Quorum command.

Remove the monitoring of the primary node

Use the sentinel remove master-name command.

Modify quorum parameters

Use the sentinel set master-name quorum n command.

The quorum parameter is used to indicate the number of Sentinel that confirms that the master node is offline. If quorum is set to 1, it means that as long as one Sentinel confirms the subjective offline, the master node will be offline objectively (truly).

All the above changes to the configuration file are automatically refreshed to the physical configuration file sentinel.conf

Code actual combat

Import redis.clients.jedis.Jedis;import redis.clients.jedis.JedisSentinelPool;import utils.Config;import java.util.HashSet;import java.util.Set;public class SentinelExample {/ / master name private static String _ MASTER_NAME = "mymaster"; public static void main (String [] args) {/ / Sentinel configuration information Set set = new HashSet (); / / connection information ip:port set.add ("127.0.0.1 mymaster") / / create Sentinel connection pool JedisSentinelPool jedisSentinel = new JedisSentinelPool (_ MASTER_NAME, set, Config.REDIS_AUTH); / / get Redis client Jedis jedis = jedisSentinel.getResource (); / / set element String setRes = jedis.set ("key", "Hello, redis."); System.out.println (setRes) / / get the element System.out.println (jedis.get ("key"));}} at this point, I believe you have a better understanding of "what is the master-slave synchronization and sentinel mode in Redis". You might as well do it in practice! Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

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.

Views: 220

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report