Backup of Redis

The Redis backup feature is very simple to use. Configuring a master-slave backup mechanism makes the Redis slave server exactly the same as the primary server. The following is a very important description of Redis backup.
Redis uses asynchronous backups. Starting with version 2.8, the slave periodically receives a certain amount of data from the backup stream.

• Master stations can have multiple slave stations.
• The slave is able to receive connection requests from other slave stations. In addition to connecting multiple slave stations to the same master station, the slave can also connect to other slave stations to form a graph structure.
• Redis backups are non-blocking on the main station. This means that the master can continue to process requests when there is a slave that performs the initial synchronization.
• It is also non-blocking at the slave terminal. When the slave is performing the initial synchronization, it can still process the request with the old version of the dataset, as long as you have configured this in redis.conf. Instead, you can configure the slave to return an error to the client when the backup stream is stopped. However, after the initial synchronization, the old data set must be deleted and the new data set must be loaded. During this time, the slave will block the next connection request.
• Backups can be used for scaling, so that multiple slave stations can handle requests for read-only types (for example, time-consuming sort operations can be sent offline to multiple slave stations) or data redundancy.
• You can avoid the overhead of writing all the data to the hard drive by backing up: Simply configure the master redis.conf file to remove the save operation (comment out all the save instructions), and then connect to the last slave that was configured as a timed save. To use this configuration, you must ensure that the master does not restart automatically (please read the next section for more information)

Security of Backup when master shutdown is persisted

In configurations that use Redis backup, it is highly recommended that you turn on persistence on the master. If persistence is not allowed for reasons similar to potential concerns, the master should be configured to avoid automatic restarts.
To get a better understanding of why it is dangerous to automatically restart a persistent master configuration, please read the following failed model. In these models, the master and all of its slave data are cleared:

1. We configure a node A as the master, turn off its persistence, and nodes B and C are backups of Node A.
2. A crashed. Because a is configured to automatically reboot the system, A's process restarts. However, because persistence is off, the data set is empty when all nodes are restarted.
3. Nodes B and C are backed up from a, but a is empty, so they delete copies of their data.

Even if the Redis Sentinel has high availability, it is dangerous to turn off persistence on the master and allow the process to restart automatically. For example, if the master reboot is too fast for Sentinel to detect an error, the scenario described by the error model above will also occur.
Data security is always important, and in the case of backup, it is forbidden to configure the master as a configuration that does not persist and allows the instance to be restarted.

How does a Redis backup work?

When you configure a slave, it sends a sync command based on the connection. It doesn't care if it's the first time it's connected or a reconnection.
The master then starts saving the environment and puts all newly received commands that change the dataset into a buffer. After the background is saved, the master migrates the database files to the slave and loads them into memory. From the station, save the database file to the hard disk. The master will send commands for all buffers to the slave station. This is done through a command flow, in the same format as the Redis protocol itself.
You can experiment with Telnet. Connect Telnet to the Redis port while having the server do some work, and then perform the Sync command. You'll see a large chunk of data being transferred, and all commands received by the master will be re-executed on the Telnet session.
The slave automatically re-connects when the link between the master and the slave is suspended for some reason. If the master receives multiple synchronization requests from the current slave, it performs a background save to process all requests.
When the connection is hung off the master and slave reconnection, a full synchronization is usually performed. Starting from the redis2.8 version, however, a partial synchronization is also possible.

Partial synchronization

Starting with version 2.8, when a backup is hung up, the master and slave typically continue to backup without requiring a full synchronization.
This can be achieved by creating a block of memory in the master station that is used to store the backup stream. There is a consensus between the master and all slave stations on the backup offset and the operating ID of the main station. So when the link hangs, the slave will re-connect and request the master to continue the backup. If the run ID of the master remains intact and the offset is still available on the backup memory block, the backup resumes from the point that was hung out. If any of these conditions are not met, a full synchronization is performed (this is the normal behavior of the 2.8 version). Because the running ID of the connected master is not stored on the instance's hard disk, a full synchronization is required when rebooting from the station.
Partial synchronization This new feature uses the Psync command internally, while the old implementation uses the Sync command. It is important to note that the 2.8 version of the slave can detect if the server it is connected to supports Psync, and if not, use sync.

Backup without a hard drive

Typically, a full backup needs to create an RDB file on the hard disk and then load the Rdb file from the hard disk to send data to the slave.
This is a very stressful operation for the main station due to the low speed of the hard drive. The 2.8.18 version is the first to attempt to support a version without a hard disk backup. In this configuration the neutron process sends the RDB file directly over a network cable to the slave, without the need for the hard disk as intermediate storage.
This feature catalog is still experimental.

Configuration

To configure the backup is simple, you only need to add the following line to the slave configuration file
Slaveof 192.168.1.1 6379
Of course you have to replace the 192.168.1.1 6379 with your master IP address (or hostname) and port. Again, you can call the Slaveof command, and the master will start synchronizing with the slave.
There are also some parameters for coordinating the backup memory block that the master obtains from memory to perform partial synchronization. Please refer to the redis.fonf examples in the Redis version for more information.
No hard disk backup can be turned on by repl-diskless-sync parameters. The delay begins to transfer data in order to wait for more inbound arrivals, and the delay function is turned on via repl-diskless-sync-delay parameters. Please refer to the redis.conf examples in the Redis version for more information.

Read-only slave

Starting with the 2.6 version of Redis, the slave support is set to read-only and is turned on by default. This behavior redis.conf is controlled by the options in the file slave-read-only and can be turned on or off by the Config set command at run time.
Read-only slave will reject all write commands, so it is impossible to write to a slave, because this will return an error. This is not to say that this feature is intended to expose a slave instance to a network or to a client in an untrusted network, because administrative commands such as Debug or config are still available. However, the security of a read-only instance may be implemented by disabling these commands, which requires the use of directives in the redis.conf file rename-command .
You might wonder why you can restore a read-only setting so that the slave instance can be the target of a write operation. However, if the slave and master are either synchronized or restarted from the station, the writes are discarded. Just allow some reasonable use cases to store temporary data to writable slave. This feature may be removed later.

Configure a Slave that can authenticate to the master station

If your main station needs a password to process the request, configure the slave to use this password in all synchronization operations.
To implement this on a running instance, enter on the Redis client:

set masterauth <password>

Want to permanently set it up and add it to your config file

<password>

Write is allowed on a backup with n connections

This can be configured starting with the 2.8 version of Redis, allowing the Redis master to accept write requests only when at least N slave connections to the master station.
Then, because Redis uses asynchronous backups, it is not possible to guarantee that the slave really receives a given write operation, so there is often a window of data loss.
This feature works like this:

• The Redis slave pings the master one time per second to inform the master of the processing progress of the backup stream.
• The Reids master logs the ping that was sent from each slave station.
• The user can configure the minimum number of slave values, and the Slave ping command time gap can not exceed the maximum number of seconds.

A write operation can be accepted if there are at least n slave stations and the time gap is less than m seconds.
You can think of it as a "C" loose version of the CAP theory, where consistency is not guaranteed for a given write, but at least the number of data loss can be guaranteed to be strictly controlled within a given number of seconds.
If the condition is not met, the master will reply to an error and the write is not accepted.
There are two configuration parameters that can be used for this feature:

min-slaves-to-writenumberofmin-slaves-maxnumberofseconds>

For more information, see the example in the redis.fonf that comes with the Redis version.

Backup of Redis