❝This article explains the knowledge points Introduction to persistence RDB AOF The difference between RDB and AOF Persistence application scenarios
❞
❝Kaka compiled a roadmap to create an interview guide, and prepared to write articles according to this roadmap. Later, I found that I was adding knowledge points that were not supplemented. I also look forward to your partners joining in to help add some information. See you in the comments section!
❞
centos7.0 redis4.0 redis storage directory:/usr/local/redis redis.conf storage directory:/usr/local/redis/data
All data in redis is stored in memory. If redis crashes, the data will be lost. Redis persistence is to save data on disk. The working mechanism that uses permanent storage media to save data processes and restore the saved data at a specific time is called persistence.
What is saved in the persistence process?
The first snapshot form stores data results and focuses on the data, which is the RDB discussed below
The second operation process stores the operation process. The storage structure is complex and the focus is The point is the data operation process, which is the AOF
Now we set a value and then save it. There will be a file of dump6379.rdb under /usr/local/redis/data
In fact, this data recovery is different from other relationships There is basically no need to do anything to restore a large database. Just restart it
This picture Sourced from online videos. The execution of the save command will block the current redis server until the current RDB process is completed, which may cause long-term blocking. This command is basically abandoned and no longer used during the work process. Will replace all
with bgsaveWhen bgsave is executed in redis, it will return directly A Background saving started
At this time we are taking a look at the log file. The bgsave command is optimized for the save blocking problem
<span style="display: block; background: url(https://my-wechat.mdnice.com/point.png); height: 30px; width: 100%; background-size: 40px; background-repeat: no-repeat; background-color: #272822; margin-bottom: -7px; border-radius: 5px; background-position: 10px 10px;"></span><code class="hljs" style="overflow-x: auto; padding: 16px; color: #ddd; display: -webkit-box; font-family: Operator Mono, Consolas, Monaco, Menlo, monospace; font-size: 12px; -webkit-overflow-scrolling: touch; letter-spacing: 0px; padding-top: 15px; background: #272822; border-radius: 5px;"><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 900 1<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 300 10<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">save</span> 60 10000<br/><span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">stop-writes-on-bgsave-error</span> <span class="hljs-selector-tag" style="color: #f92672; font-weight: bold; line-height: 26px;">yes</span><br/></code>
save [Time] [Number of key changes]
That is to say, there are 10 in 300 seconds If the key value changes, bgsavewill be executed in the background.
Execute a redis command
redis’s AOF will refresh the command buffer AreaThen synchronize to the .aof file configured in redis.conf according to certain policies appendonly yes|no
appendfsync always| everysec | no
Then use restart the redis service, you can use it in usr/local/redis/data You can see the appendonly.aof file in the directoryThen we execute a command on the redis client and check it out. You can see that the data will be stored in the appendonly.aof file.
Let’s look at a case first. After we repeatedly set the name key , open the appendonly.aof file to view, you can see that there are three operations, but these three operations are all modified by one key! Can't we only save the last key? With this question, we continue to look down
As commands continue to be written to AOF, the file will become larger and larger. In order to solve this problem, redis introduces the AOF rewriting mechanism to compress the file size. AOF file rewriting is the process of converting data in the redis process into write commands and synchronizing them to the new AOF file. Simply put, it converts the execution results of several commands on the same data into the execution records of the instructions corresponding to the final result data.
For example, we executed the set name command three times above, but in the end we only need the data of the last execution. That is, we only need the last execution record.
hdel, srem
. Set a key value multiple times, etc. lpush list a lpush lsit b lpush list c
can be converted For lpush list a b c
.However, in order to prevent client buffer overflow caused by excessive data volume, each instruction of list, set, hash, zset
types can write up to 64 elementsCommand: bgrewriteaof
Then we 3- For the question 5, we execute the bgrewriteaof command on the command line and then check the appendonly.aof file
After the execution, we will find that the file has become smaller and there is only one command in the file
Configuration: auto-aof-rewrite-percentage 100 | auto-aof-rewrite-min-size 64mb
Trigger comparison parameters: aof_current_size | aof_base_size
When aof_current_size > auto-aof-rewrite-min-size 64mb will start rewriting
This picture comes from the Internet
##❝Persistence in learning, persistence in blogging, and persistence in sharing are the beliefs that Kaka has always adhered to since his career. I hope that Kaka’s articles can be seen in the huge Internet Bringing you a little help. See you in the next issue. ❞
The above is the detailed content of This article will take you to understand the complete version of Redis persistence.. For more information, please follow other related articles on the PHP Chinese website!