Knowing the details of redis RDB, you can step on many holes less

In the use of Redis In the process of , Have you ever encountered the following problems ：

• Turn on RDB Discs , Frequent request timeouts occur in business .

• except save and bgsave command , What other actions will trigger RDB Discs ？

• Yes flushall, Find out flushall The data written before came out again .

• restart Redis After instance , Data loss is found .

With these questions , Let's talk RDB Some of the details of .

Trigger RDB There are two commands for file creation ,save and bgsave.

save We know that the entire instance will be blocked , It's not usually possible to use .

bgsave Commands are generated in the background RDB file ,Redis Can still handle client requests .

But there is no guarantee that bgsave Does not affect the Redis All client requests , It's generating RDB In the process of ,Redis Meeting fork Make a sub process , Child processes and parent processes share memory address space , It can ensure that the child process has the same memory data as the parent process . But in fork Child process , The operating system needs to copy the memory page table of the parent process to the child process . If the whole Redis The instance takes up a lot of memory , Then its memory page table will be very large , The replication time will also be relatively long .

meanwhile , This process will consume a lot of CPU resources , Before the copy is complete , The parent process will also be blocked , Unable to process client request .

perform fork after , Child processes can scan Redis All data in , Then write all the data to RDB file .

after , The parent process still handles client requests . The parent process is processing the write command , Will reallocate the new memory address space , Request new memory usage from the operating system , No longer shared with child processes . such , The memory of the parent and child processes will gradually separate , The parent process will request new memory space and change memory data , The memory data of child processes will not be affected .

It can be seen that , It's generating RDB When you file , Not only consumption CPU resources , It also needs to consume more memory space .

The top is “ Turn on RDB Discs , Frequent request timeouts occur in business ” Why . Usually in a production environment , We should also avoid master On the example RDB.

Well, except save and bgsave command , What other common triggers RDB Well ？ Here is a summary of several situations , It's also a problem “ except save and bgsave command , What other actions will trigger RDB Falling plate ？” The answer ：

1 Configured with RDB The condition of falling disc

For example, the configuration file configures save xxx xxx, Or the command line is executed config set save “xxx xxx”, Both indicate that RDB Discs .

For example, configuration save 900 1

said 900 Second if there is at least 1 individual key Change in value of , Do it once bgsave.

We mentioned earlier bgsave It also affects client requests , So it's not recommended to master Add this parameter to the , For data backup , The advice is only in slave increase save Parameters .

2 Master slave copy

When the master-slave replication relationship is created for the first time , Will be executed in the main database bgsave Command to generate RDB file , Then it is passed to the slave database , Load from library RDB file , To complete the transmission of a full amount of data .

So at the peak of business visits , And the amount of data is relatively large , Not recommended in master To create a slave.

3 Redis In execution flushall command

Configured with RDB The condition of falling disc , In execution flushall On command , There will be one RDB Discs , But the content is empty . The aim is to RDB The file is also emptied .

however , If RDB and AOF When both are closed , There will be the following ：

127.0.0.1:6301> set aaa 111
OK
127.0.0.1:6301> set bbb 111
OK
127.0.0.1:6301> bgsave
Background saving started
127.0.0.1:6301> flushall
OK
127.0.0.1:6301> config get save
"save"
""
127.0.0.1:6301> config get appendonly
"appendonly"
"no"
127.0.0.1:6301> shutdown

Restart Redis

127.0.0.1:6301> keys *
"aaa"
"bbb"

Will see us empty Redis Previously written data . Obviously illogical .

This is because it's starting Redis when , The... Under the data directory will be loaded RDB file , And this RDB File is flushall Before execution bgsave Generated , In other words, you will see the emptiness Redis Previously written data . This is also true. “ Yes flushall, Find out flushall The data written before came out again ” Why .

So when the instance is not enabled RDB and AOF Under the circumstances , If you execute 了 flushall command , It is suggested that we implement it again bgsave, Give Way RDB The file is also emptied .

In addition, it also tested the opening AOF, close RDB The situation of ：

127.0.0.1:6301> set aaa 111
OK
127.0.0.1:6301> set bbb 111
OK
127.0.0.1:6301>  bgsave
Background saving started
127.0.0.1:6301> flushall
OK
127.0.0.1:6301> config get save
"save"
""
127.0.0.1:6301> config get appendonly
"appendonly"
"yes"
127.0.0.1:6301> shutdown

start-up Redis

127.0.0.1:6301> keys *
(empty list or set)

After restarting, you will not see flushall Previously written data , because Redis stay Load on startup RDB After the document , It will also be loaded during execution RDB after AOF New operations in . and flushall The operation is recorded in AOF In file .

4 Normally closed

We do this by executing shutdown Normally shut down Redis when , Not all cases will be executed once RDB Drop plate , Here we will analyze different configurations , After restart .

4.1 AOF and RDB Both open

127.0.0.1:6301> set bbb 111
OK
127.0.0.1:6301> config get save
"save"
"1800 1"
127.0.0.1:6301> config get appendonly
"appendonly"
"yes"
127.0.0.1:6301> shutdown

start-up Redis

127.0.0.1:6301> get bbb
"111"

This situation is executed once during shutdown RDB Discs , Load on startup RDB file , Ensure data consistency before and after restart .

4.2 AOF and RDB All have not been opened

127.0.0.1:6301> set ccc 111
OK
127.0.0.1:6301> config get save
"save"
""
127.0.0.1:6301> config get appendonly
"appendonly"
"no"
127.0.0.1:6301> shutdown

Then start Redis

127.0.0.1:6301> get ccc
(nil)

Found before restart ccc Of key Has been lost , So in master Did not open RDB The situation of , It needs to be actively executed before closing bgsave, Otherwise, data will be lost . This is also “ restart Redis After instance , Data loss is found ” Why .

4.3 AOF close ,RDB Opening situation

127.0.0.1:6301> set ddd 111
OK
127.0.0.1:6301> config get save
"save"
"1800 1"
127.0.0.1:6301> config get appendonly
"appendonly"
"no"
127.0.0.1:6301> shutdown

start-up Redis

127.0.0.1:6301> get ddd
"111"

This kind of situation will write RDB, Data is not lost after restart .

4.4 AOF Turn on ,RDB Closed condition

127.0.0.1:6301> set eee 111
OK
127.0.0.1:6301> config get save
"save"
""
127.0.0.1:6301> config get appendonly
"appendonly"
"yes"
127.0.0.1:6301> shutdown

start-up Redis

127.0.0.1:6301> get eee
"111"

This will not happen though RDB Discs , But because the previous operations have been written AOF, stay Redis Startup time , Will load AOF The data in , Therefore, it will be consistent with the data before closing .

The source code attachment has been packaged and uploaded to Baidu cloud , You can download it yourself ～

link : https://pan.baidu.com/s/14G-bpVthImHD4eosZUNSFA?pwd=yu27
Extraction code : yu27
Baidu cloud link is unstable , It may fail at any time , Let's keep it tight .

If Baidu cloud link fails , Please leave me a message , When I see it, I will update it in time ～

Open source address
Code cloud address ：
http://github.crmeb.net/u/defu

Github Address ：
http://github.crmeb.net/u/defu

link ：https://mp.weixin.qq.com/s/RiOD50FnmbWfpHzyk5nFdA