Redis is an advanced key value database. The data is stored in memory. Fast speed is an advantage, but the data changes rapidly. How to save the data? This is the redis persistence mechanism summarized today.

What is persistence?

Normal redis data is stored in memory. In case of a redis outage or restart, the data will be lost. Therefore, it is necessary to store the data. The process of backing up the data to disk is called redis persistence.

After the redis installation is completed, all configurations are in redis Conf file, which stores various configurations of RDB and AOF persistence mechanisms.

RDB(snapshot)

The full name is redis database, which writes the data set Snapshot in memory to disk within the specified time interval, that is, the Snapshot snapshot in jargon, and saves it in dump RDB binary file. It directly reads the Snapshot file into memory during recovery;

• How do I turn it on?

Automatic trigger

1. On redis In the conf configuration file, search the keyword save to see the persistence mode of RDB, as shown in the following figure:

The above figure shows the RDB trigger mechanism. The default values are the above three cases:

Trigger condition	explain
save 900 a	If at least one key changes (CUD) within 900 seconds, the rdb file is rewritten
save 300 10	If at least 10 key s change (CUD) within 300 seconds, rewrite the rdb file
save 60 10000	If at least 10000 key s change (CUD) within 60 seconds, rewrite the rdb file

If you don't want to open it, just comment out a few.

In addition to automatic triggering, manual triggering can also be selected

Manually trigger the - save command

Directly execute the Save command to save successfully. Each time the command is executed, all redis memory will be snapped into a new rdb file, overwriting the original rdb snapshot file. The default mode is bgsave, asynchronous operation.

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [9:49:44] C:127
$ redis-cli
127.0.0.1:6379> save
OK

See the update time of RDB, as shown in the figure:

Manually trigger the - bgsave command

COW mechanism
As the name suggests, copy on write can still handle write commands normally while generating snapshots.
The generation of rdb files is not completed by the main process, but by the child process generated by the main process fork. The main process is still executing data operation commands.

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [10:26:47] C:127
$ redis-cli
127.0.0.1:6379> bgsave
Background saving started

save VS bgsave

command	save	bgsave
IO type	synchronization	asynchronous
Block other redis commands	yes	no (there will be a short block when the fork function is called in the generation sub process)
Complexity	O(n)	O(n)
advantage	No additional memory is consumed	Do not block client commands
shortcoming	Blocking client commands	fork subprocess is required, which consumes memory

• How to close?
  Simply comment out the corresponding save command.

AOF(append-only file)

RDB, the snapshot function is not very durable. If Redis goes down, the server will certainly lose the data recently written and not saved to the snapshot. Therefore, a new persistence method is added to record it to appendonly In AOF (write to os cache first and write to disk regularly)

Enable AOF persistence

redis. In the conf file, modify appendonly yes/no to yes.
Restart redis and you will find the aof file.
PS: if it is restarted and still not found, execute the following two commands:

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [11:43:03]
$ redis-cli config set appendonly yes
OK
# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [11:43:20]
$ redis-cli config set save ""
OK

Viewing aof files

We execute a set huo 111 command, and then view the aof file:

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [11:47:09]
$ redis-cli
127.0.0.1:6379> set huo 111
OK
# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [11:47:29]
$ cat appendonly.aof
*3
$3
set
$3
huo
$3
111

This is data in the format of resp protocol. The number represented by * indicates how many parameters the command has;
The number behind $represents how many characters this parameter has.

You can determine how often fsync is sent to the disk through configuration. The configuration command is still redis Conf.

# appendfsync always
appendfsync everysec
# appendfsync no

command	explain
appendfsync always	Execute new commands once, very slow but also very safe
appendfsync everysec	fsync once per second is fast enough, and only 1 second of data will be lost in case of failure
appendfsync no	Never fsync, leaving the data to the operating system for processing is faster, but less secure, and is not adopted

AOF override

Imagine such a scenario, such as the principled operation of string, incr

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [11:59:45]
$ redis-cli
127.0.0.1:6379> incr huocount
(integer) 1
127.0.0.1:6379> incr huocount
(integer) 2
127.0.0.1:6379> incr huocount
(integer) 3
127.0.0.1:6379> incr huocount
(integer) 4
127.0.0.1:6379> incr huocount
(integer) 5

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [12:00:22]
$ cat appendonly.aof
$3
huo
$3
111
*2
$4
incr
$8
huocount
*2
$4
incr
$8
huocount
*2
$4
incr
$8
huocount
*2
$4
incr
$8
huocount
*2
$4
incr
$8
huocount

The fastest way is to set huocount=5. There is also a corresponding configuration to control the automatic rewriting frequency of AOF.

#aof files will not be rewritten automatically until they reach at least 64. If the file is too small, the recovery speed is very fast, and rewriting is of little significance
auto-aof-rewrite-percentage 100
#If the aof file size has increased by 100% since the last rewriting, the rewriting is triggered again
auto-aof-rewrite-min-size 64mb

The rewriting process is still the main process, and a child process is fork ed out for execution, which will not have much impact on normal commands such as redis. If the file is too small, it doesn't matter whether it is rewritten or not. Automatic rewriting needs to meet the conditions, so there must be a manual rewriting command: bgrewriteaof
PS: the mixed mode will be described below. I am demonstrating 6.0 redis. The mixed mode is enabled by default. Therefore, when I execute the rewrite command, the aof file will change to binary mode and can no longer be viewed in cat

RDB VS AOF

Command RDB	AOF
boot priority	low
volume	Small
Recovery speed	fast
Data security	Easy to lose data

Mixed persistence

After understanding the advantages and disadvantages of the two kinds of persistence, it is found that the mixed use effect is better. Redis 4.0 adopts mixed persistence.

aof-use-rdb-preamble yes/no

The mixed persistent AOF file structure is as follows:

The commands of the new operation will continue to be stored in the AOF file in the AOF style, and the previous commands will be stored in the RDB binary file.

# huoyajing @ huoyajingdeMBP in /usr/local/redis-6.0.15 [14:15:50]
$ cat appendonly.aof
REDIS0009�	redis-ver6.0.15�
redis-bits�@�ctime�w�!aused-mem�po�
                                   aof-preamble���huo�huocount��g�r�ÁwJ*2
*3
$3
set
$6
huohuo
$3
232