Original author, public number [programmer reading], welcome to pay attention to the public number, reprint the article please indicate the source oh.

In the last article, we learned about Redis two different persistence methods, Redis server through persistence, Redis memory persistence to the hard disk, when Redis down, we can restart the Redis server, by the RDB file or AOF file to restore the data in memory.

However, the persistent data is still on only one machine. Therefore, when a hardware failure occurs, such as a motherboard or CPU failure, the server cannot be restarted. What can be done to ensure the data security in the event of a server failure? Or can you quickly recover data? To do this, we need to understand another Redis mechanism: master-slave replication.

What is master-slave replication

The master-slave replication mechanism of Redis enables the slave server to accurately copy the data of the master server, as shown in the following figure:

The figure above shows the situation of one master server and slave server. In fact, one master server can also correspond to multiple slave servers, as shown below:

In addition, the slave server can also have its own slave server, which is called sub-slave. The final data of these sub-slaves can be consistent with that of the master through master/slave replication, as shown in the following figure:

The mode and working principle of master-slave replication

The master-slave replication of Redis is asynchronous, which can be divided into two aspects: one is that the master server is asynchronous when it synchronizes data to the slave, so the master server can still receive other requests; the other is that the slave is also asynchronous when it receives synchronous data.

Copy the way

Redis master/slave replication is classified into the following three modes:

I. When the connection between the master server and slave server is normal, the master server sends a data command flow to the slave server to copy its data changes to the Slave server.

2. When the master server is disconnected from the Slave server for various reasons, the slave server tries to obtain the unsynchronized data again when reconnecting to the master server, that is, partial synchronization, or partial replication.

Three, if not part of the synchronous (such as initial synchronization), will request for full amount of synchronization, the master server own RDB file will be sent to the slave server data synchronization, and record the other written during synchronization, and then sent to the slave server, in order to achieve complete synchronization, the purpose of this approach is called full copy.

The working principle of

The master server records a pseudo-random string replicationId, which is used to identify the current version of the data set. The master server also records a pseudo-random string replicationId, which is used to identify the current version of the data set. The master server also records a pseudo-random string replicationId, which is used to identify the current version of the data set. The replication Id and offset will always be recorded and paired. We can check the replication Id and offset by running the following command:

> info repliaction
Copy the code

If you run the command on the master or slave server through the redis-CLI, information similar to the following is displayed (the information varies with the server data) :

Connected_slaves: 1 slave0: IP = 127.0.0.1 port = 6380, state = online, offset = 9472, lag = 1 master_replid:2cbd65f847c0acd608c69f93010dcaa6dd551cee master_repl_offset:9472Copy the code

When the master and slave are connected properly, the slave uses the PSYNC command to send the replication ID and offset of the old master that it has recorded. The master calculates the data offset between the master and slave. The number of offsets in the buffer is synchronized to the slave, so that the data of the master and slave are consistent.

If the replication referenced by the slave is too old and the data difference between the master and slave is too large, the master and slave will use full replication to synchronize data.

Configure the primary/secondary replication

The master/slave configuration of Redis is very simple. There are two ways to configure the master/slave server. For this example, we will assume that the master server address of Redis is 192.168.0.101.

The client sends the synchronization command

# to clientSaveof 192.168.1.101 6379Copy the code

Slave Server Configures the master server

Redis. conf of the slave server can specify the master server with the saveof option as follows:

Slaveof 192.168.1.101 6379Copy the code

After the preceding two configurations, the master server and slave server can start data synchronization.

Master requirements validation

If the master server does not have a password, you can run the following command on the redis-cli connected to the slave server:

# 
      
        refers to the actual password
      
config set masterauth <password>
Copy the code

Or configure the following options in the slave server’s redis.conf:

# 
      
        refers to the actual password
      
masterauth <password>
Copy the code

Prevent the slave from being cleared

Will the slave be cleared? Does the slave not need to synchronize the master data? How did the backup data get wiped clean?

If the master server disables persistence and automatically restarts after a fault occurs, the Redis memory data on the restarted server will be empty, and the slave server will automatically synchronize the master data. In this case, the data on the slave server will also be cleared.

How do I keep the slaves from being emptied?

If possible (and usually possible), the master server should still enable persistence, so that when the master fails to restart, the data can be quickly recovered, and the slave data that synchronized the master will not be wiped out.

If the master cannot enable persistence, you should not configure the master to restart after failure (some machines are configured to restart automatically). Instead, you should upgrade a slave server to the master server and continue to provide services externally.

Slave is read-only by default

After Redis2.6, the slave read-only mode is enabled by default. You can specify whether to enable the slave read-only mode by using the slave-read-only option in the configuration file:

The default is yes
slave-read-only yes/no 
Copy the code

Alternatively, run the config set command on the client to set whether to enable the read-only mode.

config set slave-read-only no
Copy the code

Note that if the slave server is configured with its own sub-slave server, the sub-slave will only synchronize data from the master server to the slave server, and will not synchronize data written directly to the slave server.

Key expiration problem in primary/secondary replication

As we all know, Redis can limit the lifetime of a key by setting the expiration time of the key. Redis has two mechanisms to deal with the expiration of the key, namely lazy deletion and periodic deletion. After the master-slave replication is configured, the slave server does not have the right to deal with the expiration of the key. Therefore, the master accumulates expired keys and sends the del command to the slave to delete the expired keys.

If the slave server is upgraded to the master server, it will start calculating key expiration times independently, without the help of the master server.

The role of master-slave replication

Save a copy of Redis data

When we persist Redis memory data through RDB or AOF, after all, it is only local and cannot guarantee absolute security. By synchronizing data to slave server, we can keep another data backup and better ensure data security.

Reading and writing separation

After the master/slave replication is configured, if the read/write pressure on the master server is too high, the client can separate read/write data from the master server. When reading data, the client accesses the slave server to reduce the access pressure on the master server.

High availability and failover

The high availability of the server means that the server can provide 7*24 hours uninterrupted service. Redis can manage multiple Redis servers through Sentinel system. When the master server fails, Sentineal will upgrade a slave server to a master server according to certain rules to continue to provide services, implement failover, and ensure the continuity of Redis services.

summary

The master-slave replication of Redis allows us to synchronize the data in Redis to other servers, providing a more secure guarantee for data security. It also allows us to switch servers more quickly and continue to provide services when our servers fail to restart.

Your attention is the biggest encouragement on my writing road!