Redis data persistence

Redis data persistence

In general, there are two persistence solutions: RDB and AOF.
The RDB method creates a time point-based snapshot for the dataset at a certain interval.
The AOF method records the write operations received by the Server to log files. When the Server restarts, It replays these write operations to recreate the dataset. This method is similar to the statement-based binlog in MySQL. When the log size increases, Redis can re-write the log in the background.
If you only want data to exist during Server running, you can disable the two persistence schemes. You can enable both AOF and RDB data persistence solutions in the same Redis instance. In this case, when Redis restarts, The AOF file will be used to reconstruct the original dataset, because the AOF method can guarantee data integrity to the maximum extent in RDB mode.

Advantages and disadvantages of the two-minute solution
Advantages of RDB
RDB is a compact copy of Redis Data Set Based on time points, and is very suitable for backup scenarios. For example, you can archive a small RDB file every hour, archive a large RDB file every day, and archive a larger RDB file every month. In this way, you can select different backup versions to recover data when necessary.
RDB is ideal for disaster recovery because it is a compact file that is easy to transmit to a remote data center or Amazon S3.
The RDB mode has low overhead. In this mode, the Redis parent process only needs to open up a sub-process to do the rest.
Compared with AOF, RDB can restore data faster when the dataset is large.

Disadvantages of RDB
RDB is not the best solution if you want to avoid data loss when Redis stops working (such as unexpected power outages. For example, a snapshot is usually created every five minutes or longer. If Redis is not properly disabled, data in the last few minutes may be lost.
The RDB method often calls the fork () function to open up sub-processes for persistence. When the dataset is large and the CPU performance is not strong enough, the fork () call may take a lot of time, which may cause Redis to fail to serve the clients in several milliseconds or even one second. AOF also needs to call fork (), but can adjust the frequency of rewriting logs without affecting data persistence.

AOF advantages
When using the AOF method, Redis persistence is more reliable: There are three different fsync policies available: no fsync at all, fsync every second, and fsync at every query. The default value is fsync every second. At this time, the write performance is still good, And the write operation may be lost for one second in the worst case.
AOF logs are generated by append only. Therefore, there are no random access problems or damages caused by unexpected power outages. Even if for some reason (such as full disk) logs end with a half-written command, you can still use the redis-check-aof tool to quickly fix the problem.
When the AOF log grows, Redis can automatically rewrite the AOF log in the background. It is completely secure to re-write logs when Redis continues to append the old AOF log files. Redis uses the minimum command that can reconstruct the current dataset to generate a new log file. Once the new log file is created, Redis starts to append logs to the new log file.
AOF log format is easy to understand and parse. This is useful in some scenarios. For example, you cannot use the FLUSHALL command to clear all the data, and AOF logs are not overwritten, you can simply stop the Redis Server and remove the last FLUSHALL command in the log to restart the Redis Server to recover data.

AOF disadvantages
The same dataset AOF file is much larger than the RDB file.
Based on the fsync method, AOF may be much slower than RDB. When no fsync at all is used, the performance of AOF is basically the same as that of RDB. When fsync every second is used, the performance is decreased but still high, and the performance is low when fsync at every query is used. However, the RDB method can minimize the latency at high loads.
Some specific commands may have bugs, so that the same dataset cannot be rebuilt when AOF logs are reloaded. Such a bugs is very rare and has been fully tested through the test suite. This type of bugs is almost impossible for RDB. More clearly: Redis AOF incrementally updates the existing status and RDB snapshots are re-created each time. In terms of concept, the RDB method is more robust. However, pay attention to two points: each time the AOF log is overwritten by Redis, the log is re-generated by the actual data containing the dataset, compared with the append AOF file method, this method can effectively reduce the probability of bugs appearing. in actual application scenarios, no user reports about AOF damage have been received.

How to Choose persistence mode?
Depends on the Specific Application Scenario. Generally, two methods can be used at the same time. If you are concerned about data but can still tolerate data loss for several minutes, you can simply use the RDB method. Many users only use the AOF method. This method is not recommended. On the one hand, creating an RDB snapshot at a certain interval is an excellent way to create a data backup and quickly restore data, on the one hand, you can avoid the possible bugs in the AOF mode. For the above reasons, the AOF and RDB methods may be combined into one in the future.

RDB persistence settings
By default, Redis creates a data snapshot named dump. rdb in binary format on the disk. You can create a snapshot every N seconds through the configuration file and at least M changes on the dataset, whether to compress the data, the snapshot name, and the working directory where the snapshot is stored. The default configuration of redis 2.4.10 is as follows:

# Create a snapshot when at least one key changes after 900 seconds
Save 900 1
# Create a snapshot when at least 10 keys change after 300 seconds
Save 300 10
# Create a snapshot 60 seconds later when at least 10000 keys change
Save 60 10000
# Disable RDB persistence by commenting on all rows starting with save
# Compressing data when creating a snapshot
Rdbcompression yes
# Snapshot name
Dbfilename dump. rdb
# Directory for storing snapshots (AOF files will also be stored in this directory)
Dir/var/lib/redis/

For more information about configuration parameters, see the description in redis. conf.

In addition to setting through the configuration file, you can also manually execute commands to create snapshots.
The SAVE command executes a synchronization operation to SAVE snapshots of all data in the instance as RDB files. Generally, the SAVE command is not directly used in the production environment, because all client requests are blocked and can be replaced by the BGSAVE command. Create a data snapshot in the BGSAVE background. The status code of the name execution result is returned immediately. Redis opens up a sub-process, the parent process continues the corresponding client request, the sub-process saves the database to the disk and then exits. The client can check whether the operation is successful by executing the LASTSAVE command.

Workflow for creating RDB snapshots
When Redis needs to dump the dataset to the disk, the following process is performed:
Redis forks a sub-process;
Child processes write data sets to temporary RDB files;
The child process writes a new RDB file and replaces the old RDB file.
This method enables Redis to take advantage of the copy-on-write mechanism.

Install and test Redis in Ubuntu 14.04

Redis cluster details

Install Redis in Ubuntu 12.10 (graphic explanation) + Jedis to connect to Redis

Redis series-installation, deployment, and maintenance

Install Redis in CentOS 6.3

Learning notes on Redis installation and deployment

Redis. conf

For more details, please continue to read the highlights on the next page:

1 2 Next Page