Abstract: This article will demonstrate how to configure, implement and implement master/slave replication, Redis master/slave replication three major policies, full replication, partial replication and immediate replication.

This article is shared from huawei cloud community “Real Knowledge comes from Practice: Redis master/slave replication implementation by practice”, original author: A Mengduora A.

Copy the profile

Redis as a non-relational database, its replication function and relational database (MySQL), the function is virtually the same, nothing more than the implementation of the principle is different. Redis’s copy function is unique to other memcached databases.

Redis replication function is the main function, is the basis of cluster, sharding function realization; It is also a strategy for Redis to achieve high availability, such as solving single machine concurrency problems, data security and so on.

The service is introduced

In this environment demonstration, there is a host that has two Redis samples started.

implementation

Redis replication is implemented in the following three ways:

1. Configuration during service startup

This mode enables the primary/secondary replication function by using command line parameters when starting the Redis service. The disadvantage of this method is that configuration persistence cannot be implemented. When the service is stopped, the same command parameters need to be added when the service is started.

1.1 Master server added requirepass in redis.confg in advance.

requirepass 6379
Copy the code

1.2 Starting the secondary Server.

Redis-server --port 6380 --replicaof 192.168.2.102 6379Copy the code

2. Configure the CLI

In this mode, you can use redis- CLI to enter the operation interface and configure. The disadvantage of this approach is that configuration persistence cannot be implemented. When the service is stopped, the same command needs to be executed to start the service.

2.1 Master Server Execution

127.0.0.1:6379> config set requirepass 6379OK
Copy the code

2.2 Executing from the Server.

127.0.0.1:6380> replicaof 192.168.2.102 6379ok127.0.0.1:6380 > config set masterauth 6379OKCopy the code

3. Configure the configuration file

Conf configuration file to implement persistent configuration. It is recommended.

3.1 Configuring the primary server, redis.config.

requirepass 6379
Copy the code

3.2 Configuring the secondary server, redis.config.

6379 replicaof masterauth 192.168.2.102 6379Copy the code

4. Configuration description

1. Masterauth: Set the connection password of redis. Confi. When other clients connect to the server, they need to add passwords to access the server.

2. Requirepass: Set the connection password of the primary server, which is the same as masterauth in 1.

3. Replicaof: specifies the IP address and port number of the replicaof server.

Effect of the test

1. Add data to the primary server.

2. Obtain data from the server.

Realize the principle of

// UML diagram @startuml Secondary server -> primary server: 1 Save the configuration: secondary server > Primary server: 2. Establish socket connection to secondary server > Primary server: 3. Send the ping command. Secondary server > Primary server: 4. Verify permission. Secondary server > Primary server: 5. Synchronize data from secondary server -> primary server: 6. Continuously copy data @endUMLCopy the code

One of the main implementations of master-slave replication is shown in the figure above

1. In the first step, the slave server saves the configuration information of the master server. When the timer inside the slave server is executed, the replication process is triggered.

2. In the second step, the slave server establishes a socket socket byte connection with the master server for master/slave communication. This set of bytes is also used by the master server to send data to the slave server.

3. Step 3: After the socket socket byte connection is successful, the host sends the ping command for authentication. Normally, the host sends the corresponding response. The ping command is used to check whether the socket socket bytes are available and to verify that the primary server accepts the operation command.

4. The fourth step is authentication to check whether the primary node connection password configured on the secondary node is correct.

5. After the authentication is successful, data can be replicated. The primary server performs full replication and sends all data of the primary service to the secondary server. The secondary server saves the data sent by the primary server.

6. Next is the continuous copy operation. The master server performs asynchronous replication, writing data to itself while sending new write commands to the slave server.

Implementation strategy

There are three main methods of Redis master-slave replication. Different methods are used in different scenarios. The three scenarios are as follows:

1. Full replication. Full replication is used when the master/slave replication is established or the slave server is cut off from the master server. When the slave server does not have data from the master server, the master server sends its data to the slave server in RDB files. The slave server clears its data and loads the data from the master server to the slave server.

// uml diagram @startuml Secondary server -> primary server: 1. Psync? -1 Primary server -> Secondary server: 2. Fullsync runid offset Secondary server: 3. Save runid offset primary server: 4. Run bgSave to generate RDB primary server -> Secondary server: 5. Send RDB from slave server: 6. Clear old data from slave server: 7. Load data from master server @endUMLCopy the code

2. Partial copy. Partial replication is used in exceptional situations, such as master/slave delay, or restarting to receive partial data sent by the master server after a slave service outage.

The implementation of partial replication mainly depends on the replication cache, the RUNID of the master service, and the replication offset of the master and slave servers.

Copy cache: When receiving a write command, the master service writes the command to the cache to reduce data loss on the slave server in case of an exception. When the secondary server is connected properly, the primary server sends the data in the cache to the secondary server. The cache here is a long queue.

Primary server RUNID: The primary server generates a unique ID as its own identity after each service is started. The slave server saves the identity and uses the RUNId when sending partial copy commands.

psync runid offset
Copy the code

Offset of master/slave replication: The master/slave service has its own offset after the replication is established. The slave node sends its copy offset to the slave node every second, and the slave node increases its copy offset after the master node sends a write command. The master node also increases its offset each time it executes a write command. The offset here is calculated by summing up the command’s byte length.

3. Asynchronous replication. In asynchronous replication, after a replication relationship is established between the primary and secondary servers, the replication relationship continues.

Scene problem

1. Data security.

Read -read-only yes// Secondary server connection password masterauthCopy the code

2. Data delay. By default, the primary node does not immediately send new data to the secondary server. If this function is enabled, the primary node understands that new data is sent to the secondary server. Default time rejected with the Linux kernel.

// Replication delay repl-disable-tcp-nodelay yesCopy the code

3. The primary and secondary nodes are connected.

Once a connection is established, the primary and secondary nodes periodically simulate each other’s clients to check the service status of each other.

The primary node can be set by setting the repl-ping-replica-period parameter. The default frequency is 10s.

When replConf ACK {offsetid} is executed by the slave node, it also sends its replication offset to the master server. The master server determines the data delay based on the offset. If there is a data delay, the corresponding data will be sent from the data pool of the replication backlog buffer to the slave node.

Click to follow, the first time to learn about Huawei cloud fresh technology ~