Shulou(Shulou.com)05/31 Report--

How to carry out Redis persistence RDB and AOF analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Redis persistence scheme

Redis is an in-memory database, and the data is stored in memory. In order to avoid the permanent loss of data caused by the exit of the process, it is necessary to save the data in Redis in some form (data or commands) from memory to hard disk on a regular basis. When Redis restarts next time, data recovery is achieved by using persistent files. In addition, for disaster backup, persistent files can be copied to a remote location.

Redis provides several different levels of persistence: one is RDB and the other is AOF.

RDB persistence can generate a point-in-time snapshot of a dataset (point-in-time snapshot) within a specified time interval and save the snapshot of the database (snapshot) to disk in a binary manner.

AOF persistence records all the change operation commands executed by the server, all the commands in the AOF file are saved in the Redis protocol format, and the new commands are appended to the end of the file. Redis can also rewrite (rewrite) the AOF file in the background so that the size of the AOF file does not exceed the actual size required to save the dataset state.

Redis can use both AOF persistence and RDB persistence. In this case, when Redis restarts, it gives priority to using the AOF file to restore the dataset because the dataset saved by the AOF file is usually more complete than the dataset saved by the RDB file. You can even turn off persistence so that the data exists only while the server is running.

It is important to understand the similarities and differences between RDB persistence and AOF persistence, and the following sections describe these two persistence features in detail and explain their similarities and differences.

RDB Snapshot

Let's talk about Redis's first persistence strategy, RDB Snapshots. Redis supports the persistence mechanism of saving snapshots of current in-memory data as a data file, but how does a database with continuous writes generate snapshots? Redis skillfully uses the write-time copy-time (copy on write) mechanism of the fork command to fork the current process into a child process. According to the memory snapshot, the child process persists the data into RDB files.

By default, Redis saves the database snapshot in the root directory in a binary file named dump.rdb. You can specify the save directory through the parameter dir configuration and the file name by dbfilename. You can set Redis, such as "save N M", to automatically save the dataset when this condition is met when there are M changes in the data item within N seconds. For example, you can configure to generate a snapshot when there are 1000 writes within 10 minutes, or when there are 1000 writes within 1 minute. Multiple rules can take effect together, and which rule will take effect when it matches. The definition of these rules is in the Redis configuration file, and you can also set the rules during the Redis runtime through the Redis CONFIG SET command without restarting Redis.

For example, the following setting allows Redis to automatically save a dataset when it meets the condition that "at least 1000 keys have been changed in 60 seconds":

Save 60 1000

You can also manually let Redis save the dataset by calling SAVE or BGSAVE. The SAVE command performs a synchronous operation, saves a snapshot of all data as a RDB file, and rarely uses the SAVE command directly in a production environment, because it blocks all client requests. Do not use it in a production environment, but use the BGSAVE command instead. The execution of the BGSAVE command is done through a fork child process, so the client request is not blocked, only the token child process blocks the server. In addition, when RDB persistence is automatically triggered, Redis also chooses BGSAVE over SAVE for persistence.

Redis automatic RDB persistence is internally implemented through serverCron periodic operation functions, dirty counters, and lastsave timestamps. The serverCron executes once per 100ms to check the server status, including checking whether "save N M" meets the criteria, and if so, performing BGSAVE; and, of course, AOF rewriting checks. The dirty counter is a state maintained by the Redis server, which records how many changes (including additions and deletions) have been made to the server state since the last BGSAVE/SAVE command, and when the BGSAVE/SAVE execution is complete, the dirty is reset to 0. The lastsave timestamp is also a state maintained by the Redis server, recording the last time BGSAVE/SAVE was successfully executed, and the current time minus lastsave needs to satisfy M.

In addition to manual and automatic, there are other situations that trigger BGSAVE:

In the master-slave replication scenario, if the slave node performs a full copy operation, the master node executes the BGSAVE command and sends the rdb file to the slave node.

Rdb persistence is automatically performed when the shutdown command is executed.

Also need to know, because the write operation is carried out in a new process, when generating a new RDB file, the child process generated by Redis will first write the data to a temporary file, and then rename the temporary file to RDB file through atomic rename system calls, so that Redis's RDB file is always available at any time of failure.

This method of persistence is called snapshot. However, we can clearly see that RDB has its shortcomings, that is, once there is a problem with the database, then the data saved in our RDB file is not new, and all the data from the last RDB file generation to Redis downtime has been lost. In some businesses, if you can tolerate data loss during the interval, we also recommend that these businesses use RDB for persistence, because the cost of enabling RDB is not high. But for other applications that have high requirements for data security and cannot tolerate data loss, RDB is powerless, so Redis introduces another important persistence mechanism, AOF log persistence.

In order to reduce the size of RDB files as much as possible, Redis uses LZF algorithm to compress RDB files by default. Although compression is time-consuming, it can greatly reduce the size of RDB files, so compression is turned on by default, and the parameter is rdbcompression. It is important to note that the compression of RDB files is not for the entire file, but for strings in the database, and only if the string reaches a certain length (20 bytes).

In addition to compression, you can also verify the RDB file, through the parameter rdbchecksum setting, the default is yes. Works when writing and reading files, shutting down checksum brings about a 10% performance improvement when writing and starting files, but cannot be detected when data is corrupted.

In addition, whether the Redis stops executing the write command when an error occurs in bgsave. Redis provides a parameter stop-writes-on-bgsave-error, set to yes, then when there is a problem with the hard disk, it can be found in time to avoid a large number of data loss; set to no, then Redis ignores the error of bgsave to continue to execute write commands, when monitoring the Redis server's system (especially the hard disk), this option is considered to be set to no.

Tell me about the cost of FORK?

The parent process can create a child process through the fork operation, and the first generation Unix system implemented a silly process creation: when the fork system call was executed, the kernel copied the entire user space of the parent process and allocated the copied share to the child process. This behavior is very time-consuming because it needs to complete the following tasks: assigning pages to the child process's page table, assigning pages to the child process's page table, initializing the child process's page table, and copying the parent process's page to the child process's corresponding page.

Fork () for Linux is now implemented using a copy-on-write (copy-on-write) page. Copying while writing is a technique that can postpone or even avoid copying data. The kernel does not copy the entire process address space at this time, but allows the parent and child processes to share the same copy. Data is copied only when it needs to be written, so that each process has its own copy. That is, resources are replicated only when they need to be written, and before that, they are only shared as read-only. This technique delays the copy of the page in the address space until the write actually occurs. So even if fork processes with large memory, the memory consumption and time consumption are very small.

Now, although the child process does not copy the data space of the parent process during fork, it will copy the memory page table (the page table is equivalent to the index and directory of memory); the larger the data space of the parent process, the larger the memory page table, and the more time it takes to copy fork. This problem is also one of the reasons why Redis memory should not be too large, and of course, the extended failure recovery time is also one of the reasons why Redis memory should not be too large.

AOF log

From the above analysis, we know that RDB snapshots have a high probability of losing data that was recently written and has not yet been saved to the snapshot. Although data security is not the most important consideration for some programs, snapshots are not suitable for those programs that pursue data security. Since version 1.1, Redis has added a more real-time persistence method, that is, AOF persistence. The full name of the AOF log is append only file, and we can tell from the name that it is an appended log file. Compared with RDB, AOF has better real-time performance, so it has become the mainstream persistence scheme.

The difference between AOF file and binlog of MySQL database is that AOF is a plain text format, which has the advantages of good compatibility, strong readability, easy to deal with, simple operation to avoid secondary overhead and so on. It records Redis standard commands one by one. Enable AOF persistence command as follows:

Appendonly yesappendfilename "appendonly.aof"

From now on, whenever Redis executes a command that changes the dataset (such as SET), the command is appended to the end of the AOF file. In this way, when Redis is restarted, the program can reconstruct the dataset by re-executing the commands in the AOF file.

Since each write command of Redis needs to be recorded, AOF does not need to be triggered. The following describes the execution process of AOF:

Command append (append)

Redis appends the write command to the buffer first instead of writing directly to the file, mainly to avoid writing the write command directly to the hard disk every time, causing the hard disk IO to become the bottleneck of the Redis load.

File write (write) and file synchronization (sync)

Redis provides a variety of file synchronization policies for AOF cache, which involves the write function and fsync function of the operating system, as described below:

In order to improve the efficiency of file writing, in modern operating systems, when users call the write function to write data to a file, the operating system usually temporarily stores the data in a memory buffer. When the buffer is filled or exceeds the specified time limit, the buffer data is actually written to the hard disk. Although this operation improves efficiency, it also brings security problems: if the computer stops, the data in the memory buffer will be lost; therefore, the system also provides synchronization functions such as fsync and fdatasync, which can force the operating system to immediately write the data in the buffer to the hard disk, thus ensuring the security of the data.

The synchronization file policy of the AOF cache is controlled by the parameter appendfsync, and the values are as follows:

Always: immediately after the command is written into aof_buf, the system fsync operation is called to synchronize to the AOF file, and the thread returns after the fsync is completed. In this case, every time there are write commands have to be synchronized to the AOF file, the hard disk IO has become a performance bottleneck, Redis can only support about a few hundred TPS writes, seriously reducing the performance of Redis; even if you use solid state disk (SSD), you can only handle tens of thousands of commands per second, and will greatly reduce the life of SSD.

No: the write operation of the system is called after the command is written into aof_buf, and the fsync synchronization of AOF files is not performed. Synchronization is the responsibility of the operating system, and the synchronization period is usually 30 seconds. In this case, the time of file synchronization is uncontrollable, and there will be a lot of data accumulated in the buffer, so the data security can not be guaranteed.

Everysec: the system write operation is called after the command is written into aof_buf, and the thread returns after the write is completed; the fsync synchronization file operation is called once per second by a special thread. Everysec is a compromise between the above two strategies and a balance between performance and data security, so it is the default configuration of Redis and our recommended configuration.

File rewriting (rewrite)

Because AOF works by constantly appending commands to the end of the file, the size of the AOF file becomes larger and larger as the number of write commands increases. For example, if you call INCR 100 times on a counter, the AOF file needs to use 100 records (entry) just to save the current value of the counter. In practice, however, a single SET command is sufficient to hold the current value of the counter, and the remaining 99 records are actually redundant. In addition, there are some out-of-date data, invalid data can also be removed.

Too large AOF files will not only affect the normal operation of the server, but also cause the data recovery time to be too long. To handle this situation, Redis supports an interesting feature to rebuild AOF files without interrupting the service client. Execute the BGREWRITEAOF command, and Redis will generate a new AOF file that contains the minimum number of commands needed to rebuild the current dataset.

The AOF REWRITE (rewrite) generation process, similar to RDB snapshots, skillfully takes advantage of the write-time replication mechanism. It is also a child process of fork (where the main thread is blocked), which writes to the new AOF file according to the command merge rule according to the memory snapshot. When the main process fork continues to accept requests after completing the child thread, all write commands are still written to the AOF buffer (aof_buf) and synchronized to the hard disk according to the appendfsync policy to ensure the correctness of the original AOF mechanism. However, because fork operations use write-time replication technology, child processes can only share in-memory data during fork operations. Because the parent process is still responding to the command, Redis uses the AOF rewrite buffer (aof_rewrite_buf) to keep this part of the new log from being lost during the generation of the new AOF file. That is, during the execution of bgrewriteaof, the write command of Redis is appended to both aof_buf and aof_rewirte_buf buffers.

When the child process finishes writing the new AOF file, it signals to the parent process that the parent process updates the statistics, which can be viewed through info persistence. The parent process then writes the data from the AOF rewrite buffer to the new AOF file, which ensures that the database state saved by the new AOF file is consistent with the current state of the server. Then call the atomic rename command to replace the old AOF file with the new AOF file to complete the AOF rewrite.

Note here because the main process appends the aof_rewrite_buf cache to the new log file. When the main process appends the log, it will not process other requests, and if the aof_rewrite_buf is particularly large, for example, hundreds of M, it may also cause the Redis to become unresponsive for several seconds or even tens of seconds.

As we can see from the above process, both RDB and AOF operations are sequential IO operations with high performance. In the case of database recovery through RDB files or AOF logs, the data is also sequentially read and loaded into memory. So it will not cause random reading of the disk.

The trigger of file rewriting can be divided into manual trigger and automatic trigger:

Manual trigger: directly invokes the bgrewriteaof command, which executes somewhat like bgsave: both allow child processes to do specific work, and all block only when fork.

Automatic trigger: determine the trigger time according to auto-aof-rewrite-min-size and auto-aof-rewrite-percentage parameters, as well as aof_current_size and aof_base_size status.

Auto-aof-rewrite-min-size represents the minimum volume of the file when performing an AOF rewrite, and the default value is 64MB.

Auto-aof-rewrite-percentage represents the ratio of the current AOF size (that is, aof_current_size) to the last AOF size (aof_base_size) when performing an AOF rewrite, that is, the growth ratio reaches the set value.

AOF rewriting, that is, the bgrewriteaof operation, will be triggered automatically only if both auto-aof-rewrite-min-size and auto-aof-rewrite-percentage parameters are met.

The parameters can be viewed through the config get command:

127.0.0.1) CONFIG GET auto-aof-rewrite-min-size1) "auto-aof-rewrite-min-size" 2) "64000000" 127.0.1) CONFIG GET auto-aof-rewrite-percentage1) "auto-aof-rewrite-percentage" 2)

The status can be viewed through info persistence:

127.0.0.1 purl 6379 > info persistence# Persistenceaof_enabled:1aof_rewrite_in_progress:0aof_rewrite_scheduled:0aof_last_rewrite_time_sec:0aof_current_rewrite_time_sec:-1aof_last_bgrewrite_status:okaof_last_write_status:okaof_current_size:40876638aof_base_size:2217565aof_pending_rewrite:0aof_buffer_length:0aof_rewrite_buffer_length:0aof_pending_bio_fsync:0aof_delayed_fsync:0

In addition, in the aof rewrite process, whether to adopt the incremental "file synchronization" strategy is controlled by the parameter aof-rewrite-incremental-fsync, which defaults to "yes" and must be yes. During the rewrite process, file synchronization occurs for every 32m of data, which reduces the number of "aof large file" writes to the disk.

The bgrewriteaof mechanism, which rewrites aof in a child process, does not block the processing of the remaining commands by the main process, and solves the problem that the aof file is too large. Now there is a problem, both the bgrewriteaof operation and the main process write aof file operation, both of which will operate on disk, while bgrewriteaof will often involve a large number of disk operations, which will cause the main process to block when writing aof file, and now the no-appendfsync-on-rewrite parameter comes out.

If this parameter is set to no, it is the safest way not to lose data, but to tolerate blocking. What if it is set to yes? This is equivalent to setting appendfsync to no, which means that no disk operation is performed, but the buffer is written, so this does not cause blocking (because there is no competing disk), but if the Redis dies at this time, the data will be lost. How much data is lost? Under the default settings of Linux's operating system, up to 30 seconds of data will be lost. Therefore, if the application system cannot tolerate delay and can tolerate a small amount of data loss, it is set to yes. Set to no if the application system cannot tolerate data loss.

AOF refresh policy?

As mentioned earlier, in AOF, if the file synchronization policy of the AOF buffer is everysec, in the main thread, the system write operation is called after the command is written to aof_buf, and the main thread returns after the write is completed; the fsync synchronization file operation is called once per second by a special file synchronization thread. The problem with this approach is that if the load on the hard disk is too high, the fsync operation may exceed 1s; if the Redis main thread continues to write commands to aof_buf at a high speed, the load on the hard disk may become larger and higher, and the IO resources may be consumed faster; if the Redis process exits abnormally at this time, more and more data will be lost, which may be much more than 1s.

For this reason, the processing strategy of Redis is as follows: each time the main thread performs AOF, it compares the time when the last fsync succeeded; if it is less than 2s from the last time (that is, a delay of 1s), the main thread returns directly; if it exceeds 2s, the main thread blocks until the last fsync synchronization is completed. Therefore, if the system hard disk load causes the fsync speed to be too slow, it will cause the main thread of Redis to block; in addition, with everysec configuration, AOF may lose up to 2s of data instead of 1s. Specific Analysis of Redis AOF Refresh Strategy

AOF appends the method to locate the blocking problem and monitors the aof_delayed_fsync in the info Persistence. When the AOF append blocking occurs (that is, the main thread waits for fsync to block), the index accumulates. In addition, the Redis log when AOF is blocked: Asynchronous AOF fsync is taking too long (disk is busy?). Writing the AOF buffer without waiting for fsync to complete, this may slow down Redis.

If AOF additional blocking occurs frequently, the hard disk load of the system is too large; you can consider replacing the hard disk with faster IO, or use the IO monitoring and analysis tool to analyze the IO load of the system.

What's the difference for pipelining?

For the operation of pipelining, the specific process is that the client sends N commands at a time, and then waits for the return results of these N commands to be returned together. By adopting pipilining, it means giving up the confirmation of the return value for each command. Because in this case, N commands are executed in the same execution. So there may be some deviation when setting appendfsync to everysec, because these N commands may take more than 1 second or even 2 seconds to execute. But what can be guaranteed is that the longest time will not exceed the execution time of these N commands.

What if the AOF file goes wrong?

The server may stop while the program is writing to the AOF file, and if the downtime causes an error in the AOF file (corrupt), then Redis will refuse to load the AOF file when it is restarted, thus ensuring that the consistency of the data will not be broken. When this happens, you can fix the faulty AOF file by creating a backup of the existing AOF file. Then use the redis-check-aof-fix program that comes with Redis to repair the original AOF file.

Then optionally use diff-u to compare the backup of the repaired AOF file with the original AOF file to see the differences between the two files. Restart the Redis server again, wait for the server to load the repaired AOF file, and restore the data.

However, if the end of the AOF file is incomplete (the tail of the file is easily incomplete due to sudden machine downtime, etc.), and the aof-load-truncated parameter is enabled, a warning will be output in the log. Redis ignores the tail of the AOF file and starts successfully. The aof-load-truncated parameter is enabled by default.

Advantages and disadvantages of RDB and AOF

What are the advantages of RDB?

RDB is a very compact (compact) file, small in size and fast in network transmission. It saves the data set of Redis at some point in time. This kind of file is very suitable for backup, and the recovery speed is much faster than AOF. Of course, one of the most important advantages of RDB over AOF is that it has relatively little impact on performance. The only thing the parent process has to do when saving the RDB file is to fork a child process, and then the child process will handle all the rest of the save work, and the parent process does not have to perform any disk Ihop O operations.

What are RDB's shortcomings?

The fatal disadvantage of RDB files is that the persistence mode of its data snapshots determines that real-time persistence cannot be done. Today, when the data is becoming more and more important, a large amount of data loss is often unacceptable, so AOF persistence has become the mainstream. In addition, RDB files need to meet specific formats and have poor compatibility (for example, the old version of Redis is not compatible with the new version of RDB files).

What are the advantages of AOF?

Corresponding to RDB persistence, AOF has the advantages of supporting second persistence and good compatibility. You can set different fsync policies, such as no fsync, fsync per second, or fsync each time a write command is executed. AOF's default policy is to fsync once per second. In this configuration, Redis can still maintain good performance, and even if a failure occurs, it will only lose data for up to one second. The AOF file is an append-only log file (append only log), so writing to the AOF file does not require seek, even if the log contains commands that are not fully written for some reason (such as disk full at write time, write outage, etc.), the redis-check-aof tool can easily fix this problem.

Redis can automatically rewrite AOF in the background when the AOF file becomes too large: the new AOF file after rewriting contains the minimum set of commands needed to recover the current dataset. The entire rewrite operation is perfectly safe because Redis continues to append commands to existing AOF files during the creation of new AOF files, and existing AOF files will not be lost even if downtime occurs during rewriting. Once the new AOF file is created, Redis switches from the old AOF file to the new AOF file and starts appending the new AOF file. The AOF file saves all writes to the database in an orderly manner, which are saved in the format of the Redis protocol, so the contents of the AOF file are easy to read and parse. Exporting (export) the AOF file is also very simple: for example, if you accidentally execute the FLUSHALL command, but as long as the AOF file is not rewritten, simply stop the server, remove the FLUSHALL command at the end of the AOF file, and restart Redis, and you can restore the dataset to the state it was before the FLUSHALL execution.

What are AOF's shortcomings?

The volume of AOF files is usually larger than that of RDB files, and the recovery speed is slow. For the same dataset, depending on the fsync strategy used, AOF may be slower than RDB. In general, the performance of fsync per second is still very high, and turning off fsync can make AOF as fast as RDB. In addition, AOF has experienced such bug in the past, because of individual commands, when the AOF file is reloaded, the dataset cannot be restored as it was when it was saved. Although this kind of bug is not common in AOF files, it is almost impossible for RDB to have this kind of bug by comparison.

Which one should I use, RDB or AOF?

First of all, it is important to understand that whether it is RDB or AOF, there is a performance price to enable persistence: for RDB persistence, on the one hand, the Redis main process will block when bgsave performs fork operations, on the other hand, the child process will also bring IO pressure to write data to the hard disk. But RDB is a good choice if the business can tolerate data loss for a few minutes to more than 10 minutes (without using a standby library); otherwise, choose AOF.

For AOF persistence, the frequency of writing data to the hard disk is greatly increased (seconds under everysec policy), IO pressure is greater, and may even cause AOF additional blocking problem (this blocking will be described in more detail later). In addition, the rewriting of AOF files is similar to RDB's bgsave, there will be blocking in fork and IO pressure problems in child processes. Relatively speaking, because AOF writes data to the hard disk more frequently, it has a greater impact on the performance of the Redis main process.

In the actual production environment, there will be a variety of persistence strategies depending on the amount of data, application security requirements, budget constraints, etc., such as not using any persistence at all, using one of RDB or AOF, or enabling RDB and AOF persistence at the same time. In addition, the choice of persistence must be considered together with the master-slave strategy of Redis, because master-slave replication and persistence also have the function of data backup, and the host master and slave slave can independently choose the persistence scheme. For example, completely turn off master persistence (including RDB and AOF), which can maximize the performance of master; while slave can only turn on AOF. However, in this case, if the master service is down due to a failure, if there is an automatic pull mechanism in the system (that is, restart the service after it is detected that the service is stopped), the master will be automatically restarted. Since there are no persistent files, the data will be empty after master restart, and the slave synchronization data will also become empty, which means data loss. So try to avoid this situation.

The interaction between RDB and AOF?

In a Redis with a version number greater than or equal to 2.4, BGREWRITEAOF cannot be executed during BGSAVE execution. Conversely, BGSAVE cannot be executed during BGREWRITEAOF execution. This prevents two Redis background processes from doing a large number of I-do operations on the disk at the same time.

If the BGSAVE is executing and the user explicitly invokes the BGREWRITEAOF command, the server will reply to the user with an OK status and inform the user that the BGREWRITEAOF is scheduled for execution: once the BGSAVE execution is complete, the BGREWRITEAOF will officially start. When Redis starts, if both RDB persistence and AOF persistence are turned on, the program will give priority to using the AOF file to recover the dataset, because the data saved by the AOF file is usually the most complete.

RDB and AOF data Import

What is the use of these persistent data? of course, it is used for data recovery after restart. Redis is an in-memory database, whether it is RDB or AOF, it is only a measure to ensure data recovery. So when Redis uses RDB or AOF for recovery, it reads the RDB or AOF file and reloads it into memory. Compared to the startup time of databases such as MySQL, it takes a lot longer, because MySQL does not need to load data into memory.

But relatively speaking, when MySQL provides services after startup, its accessed hot data will also be slowly loaded into memory, which is usually called preheating, and its performance will not be too high until the prefetch is completed. The advantage of Redis is that it loads the data into memory at one time and warms up at one time. In this way, as long as the startup of Redis is completed, the speed of providing services is very fast.

However, there are some differences in startup time between using RDB and using AOF. The startup time of RDB is shorter for two reasons. One is that there is only one record for each piece of data in the RDB file, unlike the AOF log, which may have multiple operations of one piece of data. So each piece of data only needs to be written once. Another reason is that the storage format of RDB files is the same as the encoding format of Redis data in memory, so there is no need for data encoding. The CPU consumption is much less than the load of the AOF log.

Note: when redis starts, if both rdb persistence and aof persistence are turned on, then the program will first use aof to recover the dataset, because the data saved in aof is usually the most complete. If the aof file is missing, the database content is empty after startup.

Note: if you want to switch the running redis database from RDB to AOF, it is recommended to use dynamic switching first, and then modify the configuration file to restart the database. (you cannot directly modify the configuration file and restart the database, otherwise the data in the database will be empty.)

In Redis 2.2 or above, you can switch from RDB to AOF without rebooting:

Create a backup of the latest dump.rdb file and put the backup in a safe place. Execute the following two commands:

127.0.1 CONFIG SET appendonly yes127.0.0.1:6379 6379 > CONFIG SET dir / apps/redis/data/redis-8836127.0.0.1:6379 > CONFIG SET appendonly yes127.0.0.1:6379 > CONFIG SET save ""

Ensure that the number of keys in the database does not change after the command is executed. Make sure that the write command is correctly appended to the end of the AOF file.

In step 2, the AOF function is enabled, and Redis blocks until the initial AOF file is created, after which Redis continues to process command requests and begins to append write commands to the end of the AOF file.

Step 3 is used to turn off the RDB function, which is optional, or you can use both RDB and AOF persistence functions if you prefer.

After reading the above, have you mastered how to analyze Redis persistence RDB and AOF? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.