Using a Redis server for cache and for microservices interaction is great.
You can use a Redis cluster to ensure high availability in case one of your instances goes down.
See, for example, the related posts I've published:
But what about system restart?
Even if we have a multiple instances cluster, restarting the entire Redis cluster means that the data is lost, as by default, Redis stores the data in memory only.
This is where Redis persistence saves the day.
Redis has two types of persistence:
- RDB - Redis Database Backup file
- AOF - Append Only File
RDB
RDB stores snapshots of the data stored in Redis memory to a binary file named dump.rdb.
The RDB can be configured to run every X seconds and Y updates.
The related Redis configuration is:
# location of the backup files dir /data # create backup once 300 seconds passed if at least 1000 keys were changed save 300 1000 # The filename where to dump the DB dbfilename dump.rdb
The RDB creation is actually performed as a child process fork that handle the backup in the background, so except for the forking time itself (which might be meaningful if using a Redis instance with high memory consumption), the impact is low.
Using RDB means that we have a backup of the database once in a while, but in case of system crash all of the updates since the last backup are lost.
AOF
AOF writes any update to a text log file in an append mode. Upon restart, redis replays the commands to create the state in memory.
In case the Redis process was terminated in the middle of AOF append, the last record in the file might be corrupt, but Redis can overcome this issue automatically.
The AOF can be configured to commit to the disk using one of the following modes:
The related configuration is:
Using AOF means that you gain higher durability level than RDB, but the performance and AOF size are higher. Use AOF if data loss is to be avoided as possible with a reasonable cost.
In case the Redis process was terminated in the middle of AOF append, the last record in the file might be corrupt, but Redis can overcome this issue automatically.
The AOF can be configured to commit to the disk using one of the following modes:
- always - slow and safe, write for each key update
- everysec - once in a second
- no - trust the OS to commit to the disk ,should be once in ~30 seconds
The related configuration is:
# location of the AOF files dir /data appendonly yes appendfilename "appendonly.aof" # rewrite the AOF in the following cases auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # automatic recover/ignore a corrupt AOF last record aof-load-truncated yes # appendfsync always # appendfsync everysec # appendfsync no
Using AOF means that you gain higher durability level than RDB, but the performance and AOF size are higher. Use AOF if data loss is to be avoided as possible with a reasonable cost.
Which method to use?
Redis documentation recommends the following:
- Use RDB only if data loss is not critical
- Otherwise use RDB and AOF
Why use both?
The Redis engineers claim the RDB is still required for manual backups that you should perform yourself (out of scope of the Redis process).
Final Notes
To investigate an active Redis instance configuration, use the config get CLI, for example:
127.0.0.1:6379> CONFIG GET save 1) "save" 2) "60 1"
Alternatively, use the config get * CLI to view the entire configuration.
For more details, check the Redis persistence documentation, and the Redis documented configuration file.
No comments:
Post a Comment