Two ways of Redis persistence for RDB and AOF

Original link: http://www.cnblogs.com/tdws/p/5754706.html

The persistence of Redis does not require too much involvement by our developers, what are we going to do? In addition to an in-depth understanding of the role of RDB and AOF , the rest is based on the actual situation to develop appropriate strategies, and more complex, that is, to customize a high-availability, data security Strategy .

RDB: The snapshot form is to save the current state of memory directly in the RDB, save the policy is to save a bit of time

AOF: Command line form, execute a command, directly put the command into a AOF file, save the policy is the default one second to save the command, data security, performance is almost

By default, rdb,aof is not turned on.

First look at the RDB persistence mode:

in the RDB mode , you have two options, one is to manually execute the persisted data command to have Redis take a snapshot of the data, and the other is to automatically persist the data according to the policy of the configuration file you configured to achieve certain conditions of the policy. You still have two options for manually executing the persistence command, which is the save Command and the bgsave command.

The Save Operation Works in the Redis main thread, so it blocks other request operations and should be avoided.

(by default, persisted to the dump.rdb file, and after the Redis restart, automatically read the file, it is learned, usually 10 million of the string type key,1GB Snapshot file, synchronized to memory time is 20-30 seconds )

BgSave is called fork, which produces the child process, and the parent process continues to process the request. The child process writes the data to a temporary file and, after writing, replaces the original. rdb file. When fork occurs, the parent-child process memory is shared, so in order to not affect the child process to do the data snapshot, during this time the modified data will be copied one copy, not into the shared memory. Therefore, the data persisted by the RDB is the data when the fork occurs. Persist data under such conditions and lose data for a period of time if it is down due to certain circumstances. If your situation is less sensitive to data loss, you can get lost from a traditional database or lose part of it, then you can choose the Rdb persistence method.

Talk about the policy of the configuration file, in fact it is the same as the Bgsave command persistence principle.

This is the default policy for profiles, and the relationship between them is or, every second of every minute, changes at least one key value during this time, making a snapshot. Or every 300 seconds , 10 key values are changed to take a snapshot. or every 60 seconds, change at least 10,000 key values, take a snapshot.

here's a aof. Snapshot mode:

Aof,append only file.

The appendonly in the configuration file is modified to Yes. After you turn on aof persistence, every command you execute will be recorded in the appendonly.aof file. In fact, instead of writing the command to the hard disk file immediately, it writes to the hard disk cache, and in the next policy, configures how long to write from the hard disk cache to the hard disk file. So under certain conditions, there will still be data loss, but you can greatly reduce the loss of data.

Here is the policy for configuring AOF persistence. Redis uses everysecby default, which means that it is persisted once per second, and always is written to the AoF file immediately per operation. And no is not active synchronous operation, is the default of 30s a time. of course always must be the lowest efficiency, the individual think everysec is enough, the data security can be high.

Redis also allows us to use both methods, and then restart Redis to recover data from aof because aof is less costly than RDB data.

difference and deep understanding:

Each time the RDB makes a snapshot, all the information for the entire dataset is re-recorded. The RDB is faster when recovering data, maximizes Redis performance, and has no performance impact on the parent process.

AOF The command operations of Redis in an orderly manner. There is little data loss in the event of an accident. He keeps adding operational logging to the AoF file, and you might say how big the file is. Yes, it does get huge, but Redis has an optimized strategy, such as your operation on a key1 key, set Key1 001, set Key1 002, set Key1 003. The result of the optimization is to remove the first two, the configuration of the specific optimization in the configuration file corresponding to the

The former refers to how much more than the last aof rewrite aof file size, will be optimized again, if not rewritten, then start with the main. The latter is limited to the minimum aof file size allowed for rewriting. bgrewriteaof command is to manually rewrite the command, will fork the child process, in the temporary file to rebuild the state of the database, the original aof has no effect, when the old state is rebuilt, the fork after the occurrence of a period of time data will be appended to the temporary file, Finally, replace the original aof file, and the new command continues to append to the new aof file.

Two ways of Redis persistence for RDB and AOF