Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice

Introduction to replication

As a non-relational database, Redis has the same replication function as that of a relational database (MySQL), nothing more than a different realization principle. The replication function of Redis is also unique to other memory databases (memcached).

The main role of the Redis replication function is the basis for the realization of clustering and sharding functions; it is also a strategy for Redis to achieve high availability, such as solving single-machine concurrency problems, data security and other issues.

Service Introduction

In the environment demonstration of this article, there is a host and two Redis examples are started.

Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice


Method to realize

Redis replication can be implemented in the following three ways:

1. Configure when the service starts

This method uses command line parameters to start the master-slave replication function when starting the Redis service. The disadvantage of this method is that it cannot achieve configuration persistence. When the service is stopped and the service is started, the same command parameters need to be added.

1.1 The master server adds the requirepass item in redis.confg in advance.

requirepass 6379

1.2 Start the slave server.

redis-server --port 6380 --replicaof 192.168.2.102 6379

2. Command line configuration

This method uses redis-cli to enter the operation line interface for configuration. The disadvantage of this method is that it cannot achieve configuration persistence. When the service is stopped, the same command needs to be executed to start the service.

2.1 The master server executes.

127.0.0.1:6379> config set requirepass 6379OK

2.2 Execute from the server.

127.0.0.1:6380> replicaof 192.168.2.102 6379OK127.0.0.1:6380> config set masterauth 6379OK

3. Configuration file configuration

This method is set through the redis.conf configuration file, which can realize the persistence of the configuration and is a recommended method.

3.1 Configure the main server, redis.config.

requirepass 6379

3.2 Configure the slave server, redis.config.

masterauth 6379replicaof 192.168.2.102 6379

4. Configuration instructions

1. masterauth: set the redis.confi connection password, if this value is set. When other clients connect to the server, they need to add a password before they can access it.

2. requirepass: Set the connection password of the master server, which is consistent with masterauth in 1.

3. Replicaof: Connect from the server to the server's IP address + port number.

Effect test

1. Add data to the main server.

Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice


2. Get data from the server.

Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice


Realization principle

Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice


// uml diagram @startuml slave server -> master server: 1. Save the configuration
Slave server -> master server: 2. Establish a socket connection
Slave server -> master server: 3. Send ping command
Slave server -> master server: 4. Authorization verification
Slave server -> master server: 5. Synchronize data
Slave server -> master server: 6. Continuously copy data @enduml

The main implementation process of master-slave replication is as shown in the figure above:

1. In the first step, the slave server saves the configuration information of the master server. After saving, when the timer inside the slave server is executed, the replication process will be triggered.

2. In the second step, the slave server will first establish a socket socket connection with the master server for master-slave communication. Later, the master server sends data to the slave server through this set of bytes.

3. In the third step, after the socket socket is successfully connected, the authentication ping command is sent. Under normal circumstances, the main server will send the corresponding response. The function of the ping command is to ensure whether the socket socket bytes can be used, and also to verify whether the main server accepts operation commands.

4. The fourth step, followed by authentication verification, is to determine whether the master node connection password configured by the slave node is correct.

5. The fifth step, after the authentication is successful, you can start copying data. The master server will perform a full copy at this time, sending all the data of the master service to the slave server, and the slave server saves the data sent by the master server.

6.接下来就是持续复制操作。主服务器会进行异步复制,一边将写的数据写入自身,同时会将新的写命令发送给从服务器。

实现策略

Redis主从复制主要分为三种弄策略方式,不同的策略方式都是针对不同的场景下进行使用。三种场景方式分别如下:

1.全量复制。全量复制用在主从复制刚建立时或者从切主服务器时,从服务器没有主服务器的数据,主服务器会将自身的数据通过rdb文件方式发送给从服务器,从服务器会清空自身数据,接着将主服务器发送的数据加载到自身中。

Everyone is talking about the principle of Redis master-slave replication, let me summarize the practice


// uml图@startuml从服务器->主服务器: 1.psync ? -1主服务器->从服务器: 2.fullsync runid offset
从服务器: 3.保存 runid offset
主服务器: 4.执行bgsave生成rdb
主服务器->从服务器: 5.发送rdb
从服务器: 6.清空自身老数据
从服务器: 7.加载主服务器数据@enduml

2.部分复制。部分复制用在一些异常情况下,例如主从延迟、从服务宕机之后重新启动接收主服务器发送的部分数据。

部分复制的实现主要依赖于复制缓存区、主服务的runid、主从服务器各自的复制偏移量(offset)。

复制缓存区:主服务在接收写命令时,会将命令写入缓存区,以便从服务器在异常情况下,减少数据的丢失。当从服务器正常连接之后,主服务器会将缓存区内的数据发送给从服务器。这里的缓存区是一个长队列。

主服务器runid:主服务器会在每次服务启动之后,会生成一个唯一的ID,作为自身标识。从服务器会将该标识保存起来,发送部分复制命令时,会使用该runid。

psync runid offset

Master-slave replication's respective offset: After the master-slave service establishes the replication, it will have its own offset. The slave node will send its own replication offset to the slave node every second. After the master node sends a write command, the slave node will also increase its own replication offset. The master node will also increase its own offset after each write command. The offset here is calculated by accumulating the byte length of the command.

3. Asynchronous replication. Asynchronous replication is for the master-slave server to maintain the replication relationship after the replication relationship is established.

Scene problem

1. Data security.

// From the server read only replica-read-only yes// From the server connection password masterauth

2. Data delay.

By default, if the master node has new data, it will not be sent to the slave server immediately. If it is turned on, it will be sent to the slave server immediately. The default time is rejected with the Linux kernel.

// Replication delay repl-disable-tcp-nodelay yes

3. The connection status of the master and slave nodes.

Once the master-slave node establishes a connection, it will imitate the other party's client periodically to detect the other party's service status. The master node can be set by setting the repl-ping-replica-period configuration parameter. The default frequency is 10s.

When the slave node executes replconf ack {offsetid}, it will also send its own replication offset to the master server, and the master server will determine the data delay based on the offset. If there is a data delay, the corresponding data will be reissued to the slave node from the data sink in the copy backlog buffer.


Guess you like

Origin blog.51cto.com/15128443/2665207