Shulou(Shulou.com)06/01 Report--

This article mainly explains "AOF persistence Analysis of Redis". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "AOF persistence Analysis of Redis".

AOF persistence

Different from snapshot persistence, AOF persistence writes the executed command to the end of the aof file. During recovery, you only need to execute the write command from beginning to end to recover the data. AOF is not enabled by default in redis, so you need to enable it manually as follows:

Open the redis.conf configuration file and change the value of the appendonly attribute to yes, as follows:

Appendonly yes

Several other AOF-related properties are as follows:

Appendfilename "appendonly.aof" # appendfsync alwaysappendfsync everysec# appendfsync nono-appendfsync-on-rewrite noauto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

The meanings of these attributes are as follows:

1.appendfilename represents the filename of the generated AOF backup file.

2.appendfsync indicates the timing of backup, always means backup every time a command is executed, everysec means backup every second, and no means handing over the backup time to the operating system.

3.no-appendfsync-on-rewrite indicates whether a synchronization operation is performed when the aof file is compressed.

4. The last two lines of configuration indicate the timing of the compression of the AOF file, which we will talk about in more detail later.

At the same time, in order to avoid the impact of snapshot backups, we close snapshot backups as follows:

Save "# save 900" save 300 1 "save 60 10000

At this point, when we perform data operations in redis, the configuration file appendonly.aof for AOF is automatically generated, as follows:

Notice that there is no dump.rdb file at this time. When we shut down and restart redis, we will find that the previous data is still there. This is the result of AOF backup.

Several key points of AOF backup

1. Through the above introduction, friends have learned that there are three values for appendfsync, and our preferred everysec,always option in the project will seriously reduce the performance of redis.

two。 With everysec, we may lose 1 second of data in the worst case.

Rewriting and Compression of AOF Files

AOF backup has many obvious advantages as well as disadvantages, which is file size. With the operation of the system, AOF files will become larger and larger, and even fill the whole computer hard disk. The rewriting and compression mechanism of AOF files can alleviate this problem to some extent.

When the backup file of AOF is too large, we can send a bgrewriteaof command to redis to rewrite the file, as follows:

127.0.0.1 6379 > BGREWRITEAOFBackground append only file rewriting started (0.71s)

The implementation principle of bgrewriteaof is the same as that of bgsave mentioned above, so I won't repeat it here, so the problems in the implementation of bgsave also exist here.

Bgrewriteaof can also be executed automatically, and the automatic execution time depends on auto-aof-rewrite-percentage and auto-aof-rewrite-min-size configuration. Auto-aof-rewrite-percentage 100indicates that when the current aof file size exceeds how many percent of the aof file size of the last rewrite, it will be rewritten again. If it has not been rewritten before, it is based on the aof file size at startup. The size of the AOF file is also required to be at least 64m (auto-aof-rewrite-min-size 64mb).

Best practic

1. If redis only acts as a caching server, then no persistence method can be used.

two。 Both persistence methods are enabled at the same time. In this case, when redis is restarted, the AOF file will be loaded first to recover the original data, because under normal circumstances, the dataset saved in the AOF file is more complete than that saved in the RDB file; when the data in RDB is incomplete, the server restart will only look for the AOF file when using both. Should we just use AOF? The authors recommend not, because RDB is more suitable for backing up databases (AOF is constantly changing and bad backup), restarting quickly, and there is no potential bug for AOF, leaving it as a precaution.

3. Because RDB files are used only for backup purposes, it is recommended that only RDB files be persisted on slave and backed up once in 15 minutes, leaving only the rule of save 9001.

4. If Enalbe AOF, the advantage is that in the worst case, the data will only be lost for no more than two seconds, and the startup script is relatively simple to load only your own AOF file. The first cost is that it brings continuous IO, and the other is that the blocking caused by AOF rewrite finally writing the new data generated in the rewrite process to the new file is almost inevitable. As long as the hard drive permits, the frequency of AOF rewrite should be reduced as much as possible. The default value of 64m for the basic size of AOF rewriting is too small and can be set to more than 5G. The override can be changed to the appropriate value when the default exceeds 100% of the original size.

5. If you don't have Enable AOF, you can just rely on Master-Slave Replication to achieve high availability. Saving a large amount of IO also reduces the system fluctuations caused by rewrite. The cost is that if the Master/Slave is dumped at the same time, more than ten minutes of data will be lost, and the startup script will have to compare the RDB file in the two Master/Slave and load the newer one.

Thank you for reading, the above is the content of "AOF persistence Analysis of Redis". After the study of this article, I believe you have a deeper understanding of the AOF persistence analysis of Redis, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.