Redis Data Backup and recovery

Redis Data backup and recovery Persistence of

RDB Mode (default)

The persistence of the RDB approach is accomplished through snapshots (snapshotting), and Redis automatically snaps and stores all data in memory to the hard disk when certain conditions are met. The conditions for snapshots can be customized by the user in the configuration file, consisting of two parameters: time and number of changed keys. Snapshots are taken when the number of keys changed in the specified time is greater than the specified number. The RDB is the Redis default, with 3 conditions already preset in the configuration file:

Save 900 1    # 900 seconds with at least 1 keys changed to snapshot
save   # 300 seconds with at least 10 keys changed then snapshot
save 60 10000 # Snapshots with at least 10,000 keys changed in 60 seconds

There can be multiple conditions, a "or" relationship, and a snapshot if one of the conditions is met. If you want to disable automatic snapshots, simply remove all the save parameters.

Redis the snapshot file is stored in the Dump.rdb file in the current directory (which can be viewed by config get dir), and you can specify the storage path and file name of the snapshot file separately by configuring Dir and dbfilename two parameters.

Redis the process of implementing a snapshot Redis use the fork function to copy a copy of the current process (the parent process); The parent process continues to receive and process commands from the client, and the child process begins writing the in-memory data to a temporary file on the hard disk; When the child process finishes writing all the data, it replaces the old Rdb file with the temporary file, and the snapshot operation completes.

The operating System (Unix-like operating system) uses a write-time replication (Copy-on-write) policy when performing fork, that is, the moment that the fork function occurs, the parent-child process shares the same memory data, and when it wants to change one piece of data (such as executing a write command), The operating system copies the piece of data to ensure that the data of the child process is unaffected, so the new Rdb file stores the memory data that executes the fork moment.

Redis does not modify the Rdb file while the snapshot is in progress, only to replace the old file with the new one at the end of the snapshot, which means that the Rdb file is complete at any time. This allows us to implement a Redis database backup through a timed backup of RDB files. The Rdb file is a binary format that is compressed (you can configure the Rdbcompression parameter to disable compression to save CPU usage), so the space occupied is less than the size of the data in memory and is more conducive to transmission.

In addition to automatic snapshots, you can also manually send the Save or bgsave command to allow Redis to perform a snapshot, the difference between the two commands is that the first is a snapshot of the main process, blocking other requests, which can be snapshot operations through the fork child process. The redis reads the RDB snapshot file and loads the data from the hard disk into memory after it is started. This time is different depending on the size of the data and the performance of the structure and server. It takes 20-30 seconds to load a snapshot file with a record of 10 million string type keys and a size of 1GB into memory. Persistence through RDB means that once the redis exits unexpectedly, all data changed since the last snapshot is lost. This requires the developer to set the automatic snapshot conditions in a way that can be used to control the possible data loss in an acceptable range according to the specific application situations. If the data is important enough to withstand any loss, consider using the AOF approach to persist.

AoF Way

By default, Redis does not open aof (append only file), and can be opened by the AppendOnly parameter in redis.conf:

AppendOnly Yes

At startup, Redis executes the commands in the AoF file one at a time to load data from the hard disk into memory, which is slower to load than RDB.

When AoF is turned on, each time a command that changes the data in Redis is executed, Redis writes the command to the AoF file on the hard disk. The aof file is saved in the same location as the Rdb file, set by the Dir parameter, and the default filename is appendonly.aof, which can be modified by the Appendfilename parameter:

Appendfilename appendonly.aof

Configure Redis to automatically override aof file conditions

Auto-aof-rewrite-percentage  # When the current aof file size exceeds the size of the AoF file at the time of the last rewrite, it is rewritten again, if not previously overridden, based on the aof file size
at startup Auto-aof-rewrite-min-size 64MB   # minimum aof file size allowed to be overridden

Configure the mechanism for the system to refresh the hard disk cache after you write the aof file

# Appendfsync always   # Every write is performed synchronously, the safest and slowest
Appendfsync everysec   # Perform a sync operation every second
# Appendfsync no       # Do not take the initiative to synchronize operations, but completely to the operating system to do (that is, every 30 seconds), the fastest and most insecure

Redis allows both aof and RDB to be opened at the same time, ensuring data security and making backup operations easy. After restarting Redis, Redis uses the aof file to recover the data, because the persistence of the AoF method may lose less data replication

With the persistence feature, Redis guarantees that data will not be lost (or a small amount of damage) even in the event of a server reboot. However, because the data is stored on a single server, if the hard disk of this server fails, it can also cause data loss. To avoid a single point of failure, we want to replicate the database to multiple replicas to deploy on different servers, even if one server fails, and the other server continues to provide services. This requires that when the database on one server is updated, the updated data can be automatically synchronized to other servers, and Redis provides the process of replication (replication) to automate synchronization. Configuration Method

Adding slaveof Master-ip master-port from the configuration file of the database from the configuration file, the primary database does not need to be configured

Using command line arguments--slaveof MASTER-IP Master Port when starting redis-server with command-line arguments

Redis-server--port 6380--slaveof 127.0.0.1 6379

slaveof master-ip master-port by command

redis>slaveof 127.0.0.1 6379

Slaveof NO One can be the current database to stop receiving synchronization from other databases, turn to the main database advantages and application Scenarios

Read-write separation enables read-write separation through replication to increase server load capacity. In common scenarios, the frequency of reading is greater than the written, when a single redis can not cope with a large number of Read requests (especially the more resource-intensive requests, such as the sort command, etc.) through the replication function to build multiple from the database, the primary database for write operations, and read from the database.

Persistent persistence from a database is usually relatively time-consuming, and in order to improve performance, you can create one (or several) from the database through the replication feature, enabling persistence from the database, and disabling persistence in the primary database. Restarting the database when you crash from the database automatically synchronizes the data, so you don't have to worry about data loss. And when the primary database crashes, the need to use the slaveof NO one command from the database will be promoted from the database to the main database to continue the service, and after the original primary database is started using the slaveof command to set it to the new primary database from the database, you can synchronize the data back.
If found wrong, please tap, welcome message exchange, thank you