Redis Persistent RDB

First, RDB Redis DataBase

The RDB persistence performs point-in-time snapshots of your dataset at specified intervals.

Writes a snapshot of an in-memory dataset to disk at a specified time interval, which is the jargon-snapshot snapshot, which restores the snapshot file directly to memory.

Second, how is the backup implemented?

Redis creates (fork) a child process to persist, writes the data to a temporary file, finishes the persistence process, and replaces the last persisted file with the temporary file, instead of the incremental on the original file, instead of all the backups. Throughout the process, the main process is not performing any IO operations, which ensures very high performance. If large-scale data recovery is required, and the integrity of data recovery is not very sensitive, the RDB approach is more efficient than the AOF approach.

• The disadvantage of an RDB is that the last persisted data may be lost. There is time interval, the server down, it is possible to lose, stand down must lose data

Third, about fork (bifurcation; divergence)

In a Linux program, fork () produces a child process that is exactly the same as the parent process, but the child process will then exec the system call, and for efficiency reasons, the "write-time Replication technology" is introduced in Linux, and the parent and child processes generally share the same piece of physical memory . Only the contents of the segments of the process space are to be changed, the contents of the parent process will be copied to the Wahabbi write disk, fork when the pressure on the memory is very large, performance killing device.

Contact the fork in GitHub

The role of fork is to replicate a process that is the same as the current process. All data for the new process (variables, environment variables, program counters, etc.) are consistent with the original process, but it is a completely new process and as a child of the original process

Iv. configuration file snapshotting See RDB settings

Save policy for Rdb

An RDB is a compressed, SNAPSHOT,RDB data structure for the entire memory, which can be configured with a composite snapshot trigger condition, by default

was changed 10,000 times in 1 minutes,

or changed 10 times in 5 minutes,

or changed 1 times in 15 minutes.

Disabled: If you want to disable the policy for RDB persistence, as long as you do not set any save instructions or pass an empty string parameter to save

Dynamic all methods to stop an RDB save rule: redis-cli config set save ""

Iv. how to trigger an RDB snapshot

1. Default snapshot configuration in configuration file

Profile name in redis.conf, default to Dump.rdb

2. Command Save vs Bgsave

Save: Save, account for the main process, other regardless, later operation all blocked, performance kill device

Bgsave:redis the snapshot operation asynchronously in the background, and the snapshot can also respond to client requests. The Lastsave command can be used to obtain the last time the snapshot was successfully executed background background storage

3, execute Flushall command, also will produce Dump.rdb file, but inside is empty, meaningless

The saved file for the Rdb

When Redis is unable to write to the disk, simply turn off the Redis write operation,

If not set, easy to lead to data consistency problem, background error is not timely modification prone to disaster disaster

Accident case: minicomputer Disk Cleanup, backup data background error, the actual lack of backup successfully resulting in data loss

When an RDB is saved, the file is compressed, but it takes up the CPU

For snapshots stored on disk, you can set whether to compress storage. If so, Redis will use

The LZF algorithm is compressed. If you do not want to consume the CPU to compress, you can set to turn off this function

After storing the snapshot, you can also have Redis use the CRC64 algorithm for data validation, but doing so will increase the performance cost by approximately 10%, and if you want to get maximum performance gains, you can turn off this feature

The save path to the Rdb file can also be modified. Default is the directory where the command line is located at Redis startup

V. Backup and recovery of the RDB

Backup: The directory of RDB files is queried by Config get dir, and the *.rdb files are copied to other places.

Recovery: Turn off Redis First, copy the backup files to the working directory,

Start Redis and backup data will load automatically

Vi. Small summary of the RDB

Advantage: Save disk space

Fast recovery, which is a mirror for large-scale data recovery

Low requirements for data integrity and consistency

Disadvantages:

• Backups are made at a certain interval during the backup cycle, so if Redis is accidentally down, all modifications after the last snapshot are lost.
• While Redis uses write-time copy technology when fork, it consumes CPU performance if the data is large.

Redis Persistence

Redis provides a different range of persistence options:

• the RDB persistence performs point-in-time snapshots of your dataset at specified intervals.
• the AOF persistence logs every write operation received by the server, that'll be play Ed again at server startup, reconstructing the original dataset. Commands is logged using the same format as the Redis protocol itself, in an append-only fashion. Redis is able to rewrite the log in background when it gets too big.
• if you wish, you can disable persistence @ all, If you want your data to just exist as Long as the server is running.
• it is possible to combine both AOF and RDB in the same instance. Notice that, ' in ' when Redis restarts the AOF file'll be used to reconstruct the original dataset since it's G Uaranteed to is the most complete.

The most important thing to understand are the different trade-offs between the RDB and AOF persistence. Let's start with RDB:

RDB Advantages

• rdb is a very compact single-file point-in-time representation of your Redis data. RDB files is perfect for backups. For instance want to archive your RDB files every hour for the latest hours, and to save an RDB snapshot every Day for. This allows-easily restore different versions of the data set in case of disasters.
• rdb is very good for disaster recovery, being a single compact file can transferred T o Far data centers, or on Amazon S3 (possibly encrypted).
• rdb maximizes Redis performances since the only work of the Redis parent process needs to D O In order to persist are forking a child that would do all the rest. The parent instance would never perform disk I/O or alike.
• RDB allows faster restarts with big datasets compared to AOF.

RDB Disadvantages

• RDB isn't good if you need to minimize the chance of data loss in case Redis stops working (for example after a power out Age). You can configure different save points where an RDB are produced (for instance after at least five minutes and 10 0 writes against the data set, but can has multiple save points). However you ' ll usually create an RDB snapshot every five minutes or more, so in case of Redis stopping working without a C Orrect shutdown for any reason you should is prepared to lose the latest minutes of data.
• RDB needs to fork () often in order to persist on disk using a child process. Fork () can be time consuming if the dataset is big, and could result in Redis to stop serving clients for some millisecond O R even for one second if the datasets are very big and the CPU performance not great. AOF also needs to fork () but what can tune how often are want to rewrite your logs without any trade-off on durability.

Http://redis.io/topics/persistence

Redis Persistent RDB