Persistent-aof of Redis

Redis's aof persistence strategy is to record every command sent to the Redis server and save it to a aof file on your hard disk, like a log file, and a command to record one.

aof Settings

The location of the AoF file is the same as the location of the Rdb file, set by the dir parameter, the default file name is Appendonly.aof, and can be modified by the Appendfilename parameter.

aof Test

When a client sends some REDIS commands to the server, Redis logs the commands that are executed to the AoF file as follows:

When the Redis server restarts, the aof file will be executed to achieve the purpose of data recovery.

aof File Rewrite

Why do you want to rewrite. Overrides can remove intermediate execution of data and directly retain final data commands.

Take a chestnut: for example, in the Redis client has executed a series of commands on the key

Set count 1//initial value is 1
INCR count//plus 1
INCR count//plus 1
DECR count//minus 1

This time the result is

Get Count
"2"

Without a aof rewrite, Redis executes every command in the AoF file and eventually gets Count 2 when the AoF file is restored.

After AoF rewrite, it is equivalent to omit the middle calculation process. Setting the computed result directly into Redis is equivalent to executing only one command set Count 2.

You can use the bgrewriteaof command to override the AoF file.

overriding Policies

To override the policy's parameter settings:

Auto-aof-rewrite-percentage

The current aof file size exceeds the percentage of the AoF file size at the time of the previous rewrite, and is rewritten again, based on the aof file size at startup, if not previously overridden.

auto-aof-rewrite-min-size 64MB

Limits the minimum aof file size that is allowed to be overridden, usually when the aof file is small, even if some of the redundant commands are ignored.

RDB Advantages

RDB is a compact file that represents the Redis data for an instant point. RDB files are suitable for backup purposes. For example, you might want to archive the RDB files for the last 24 hours per hour and keep the RDB snapshots for nearly 30 days a day. This allows you to easily recover different versions of the DataSet for disaster tolerance.

RDB is ideal for disaster recovery, as a compact single file that can be transferred to a remote data center, or Amazon S3 (possibly encrypted).

RDB maximizes Redis performance because the only thing that needs to be done when the parent process is persisted is to start (fork) a child process that completes all remaining work. The parent process instance does not need to perform operations such as disk IO.

RDB is faster than aof when restarting an instance of a large dataset.

RDB Disadvantages

RDB may not be very good when you need to minimize data loss when Redis stops working (for example, a power outage). You can configure different save points. However, you typically create a RDB snapshot every 5 minutes or more, so once the Redis stops working for any reason, you'll have to prepare for the last few minutes of data loss.

RDB requires frequent calls to the fork () subprocess to persist to disk. If the dataset is large, fork () is time-consuming, and as a result, Redis will stop serving clients for milliseconds or even seconds when the dataset is very large and CPU performance is not strong enough. AOF also needs fork (), but you can adjust how often you rewrite the log without compromising (trade-off) persistence (durability).

AOF Advantages

Using AOF Redis will be more durable (durable): You can have a number of different fsync strategies: no Fsync, Fsync per second, Fsync every time you request. With the default Fsync policy per second, write performance is still very good (Fsync is done by background threads, the main thread continues to work hard to execute write requests), even if you only lose one second of write data.

The AOF log is an append file, so no positioning is required, and there is no damage during power outages. Even if, for some reason, the end of the file is a write-half command (disk full or otherwise), the Redis-check-aof tool can be easily repaired.

The AoF file contains one operation after another, which is stored in a format that is easy to understand and parse. You can also easily export a aof file. For example, even if you accidentally use the Flushall command to empty everything, if there is no rewrite at this time, you can still save your dataset, you just stop the server, delete the last command, and then restart Redis.

aof Disadvantages

For the same dataset, the AoF file is usually larger than the equivalent RDB file.

AOF may be slower than RDB, depending on the exact fsync strategy. Usually the Fsync is set to once per second, and the performance is still high, and if the Fsync is turned off, it will be as fast as RDB even under high loads. However, even with a large write load, RDB can provide a good maximum latency guarantee.

Rdb and aof how to choose

In general, you should use both of these persistence methods to achieve the same level of data security as PostgreSQL provides.

If you are concerned about your data but can still accept a few minutes of data loss in the event of a disaster, you can use RDB alone.

There are many users who use aof alone, but we do not encourage this because RDB snapshots are often very handy for database backups, faster to boot, and avoid bugs in the AOF engine.