Detailed Redis master-slave replication

The article was first published on the public account "Mushroom can't sleep"

Preface

Redis's master-slave replication is similar to MySQL, and it mainly plays a role in data backup and read-write separation. Therefore, master-slave replication is very important for Redis, and whether it is an interview or a general job, it is Redis master-slave replication 160d9262f15343, so let’s take a look at how Redis master-slave replication is implemented. Right.

What is Redis master-slave replication?

In Redis, we can let one server replicate another server through the SLAVEOF command or slaveof option. The replicated server is called " master server ", and the server that initiates the replication is called " slave server ". This model of server composition is called " master-slave replication ".

Redis master-slave replication has the following characteristics:

• Redis uses asynchronous replication, and the slave and master asynchronously confirm the amount of data processed.
• A master can have multiple slaves.
• The slave can accept connections from other slaves. In addition to multiple slaves that can be connected to the same master, slaves can also be connected to other slaves in a cascading-like structure. Since Redis 4.0, all sub-slaves will receive exactly the same replication stream from the master.
• Redis replication is non-blocking on the master side. This means that the master can continue to process query requests during the initial synchronization or partial resynchronization of one or more slaves.
• Most of the replication on the slave side is also non-blocking. Of course, this is configurable. If the configuration in 160d9262f154fb redis.conf non-blocking , the old data set can be used to process query requests; if the configuration is blocking , the slave will return an error to the client.

How to achieve master-slave replication?

Assuming there are two Redis servers, the addresses are 127.0.0.1:6379 and 127.0.0.1:12345 , if you execute the following command 127.0.0.1:12345

127.0.0.1:12345> SLAVEOF 127.0.0.1 6379
OK

Then the server 127.0.0.1:12345 is the slave server of 127.0.0.1:6379 The data of the master and slave servers will be consistent
For example, the main server stores data:

127.0.0.1:6379> set msg "hello world"
OK

Then you can get the data directly from the server:

127.0.0.1:12345>get msg
"hello world"

The same is true for deleting data, the master and slave will be consistent.

Principle of master-slave replication

First of all, Redis replication is divided into synchronization (sync) and command propagation (command propagate) two operations:

• The synchronization operation is used to update the status of the slave server database to the status of the master server.
• Command propagation is the opposite. It is mainly used to make the master and slave return to a consistent process when the database status of the master server changes, causing the database status of the master and slave servers to be inconsistent.

Next, talk about these two kinds of replication in detail.

Synchronize

Text explanation:

1. The client sends the SLAVEOF command to the slave server, and first determines whether it is the first copy. The first copy is usually the beginning of the establishment of a master-slave relationship.
2. This is the first replication: Will the slave server send PSYNC to the master server? -1 command, request the main server to perform complete resynchronization operation.
3. After the main server receives the complete resynchronization request, it will execute the BGSAVE command in the background, generate a RDB file in the background, and use a copy all the backlogged buffer records executed from now.
4. After the BGSAVE command is executed, the master server will send the RDB file and the write command recorded in the buffer to the slave server, and will also return +FULLRESYNC [master server ID] [copy offset] (as shown in the figure) to the slave server The offset is one).
5. After receiving it from the server, it will load the RDB file and execute the write command given by the main server to achieve the same data state as the main server.
6. If it is not the first replication, then the slave server may be disconnected, resulting in inconsistent data status with the master server, and the data of the master server needs to be synchronized. Then the slave server will follow the steps below to request partial synchronization.
7. Send PSYNC [main server ID] [replication offset] to the main server (this is passed from the main server during the first replication), main server ID , the main server before disconnection, used to locate Synchronize that primary server; replication offset is the location of the last synchronization, used to locate the specific synchronization location.
8. After the master server receives the command from the slave server and finds the corresponding synchronization location, it will send the +CONTINUE command to the slave server, indicating that the slave server will perform part of the synchronization operation, and then the master server will save it in the replication backlog buffer Area corresponds to copy and send it to the slave server, but if the data after the offset cannot be found, complete synchronization will be performed, so that the slave server can be consistent with the master server status.

Command propagation

After the master-slave server synchronizes successfully, it will not maintain this state consistently. The master server may execute the write command, and the master-slave data will not be consistent.
In order to deal with this kind of problem, the master server will send the write commands it executes to the slave server. After the slave server executes these commands, the data of the master and slave server is consistent with .

In the command propagation phase, the slave server will send commands to the master server at a frequency of once per second by default:
REPLCONF ACK <replication_offset>
<replication_offset> is the current replication offset from the server.
Sending the REPLCONF ACK command has three functions for the master and slave servers:

• Check the network status of the master and slave servers.
• Assist in the realization of min-slaves option.
• The detection command is lost.

Keyword explanation

1. main server ID : used to identify a server.
2. Each server, whether it is a master server or a slave server, has its own unique server ID.
3. The ID is generated when the server starts, and consists of 40 random hexadecimal characters.
4. Copy backlog buffer : Copy backlog buffer is a fixed-length, first-in-first-out (FIFO) queue maintained by the master server, the default size is 1MB. as follows:

Offset	...	10086	10087	10088	10089	...
Byte value	...	3	'\r'	'\n'	'$'	...

to sum up

Redis master-slave replication is mainly achieved through the PSYNC command.
The copy is divided into partial copy and complete copy .
Partial copying is achieved by copying the offset, copying the backlog buffer, and the server ID.
Complete replication is achieved through RDB and the replication backlog buffer.
Master-slave replication mainly solves the problems of data backup and separation of read and write.

At last

If you think the article is helpful to you, like, follow, and forward them all~

You can go to the public Mushroom can't sleep see, more exciting content is waiting for you.