Nothing written to disk
The right answer for a pure cache, and data loss for anything else
- durability
- none
Redis Persistence Config Generator
Choose a durability level and get the AOF and RDB settings that deliver it, with the resources they need stated rather than assumed. Both mechanisms fork, and the fork is what sizing usually misses.
persistence.conf
updates as you typeExamples
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
Every write waits for an fsync
The strongest durability, and roughly an order of magnitude slower
- durability
- strict
Common mistakes
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
Sizing the machine for the dataset and not the fork
A background save forks, and copy-on-write means the extra memory is proportional to the writes during the save. On a write-heavy instance that approaches a second copy.
Instead:Size for the peak during a save.
Choosing appendfsync always for safety
It costs roughly an order of magnitude in throughput to remove a one second window that almost nobody actually needs removed.
Instead:Use everysec unless you can state why one second matters.
Turning off stop-writes-on-bgsave-error
It is usually turned off to stop an alert. It makes a failed save silent, so a full disk produces no symptom until the snapshot is needed.
Instead:Leave it on and fix the underlying failure.
Backing up by copying the AOF while it is being written
The copy can land mid-rewrite and be unusable. There is no lock to tell you this happened.
Instead:Copy the RDB, or use BGSAVE and copy the result.
AOF and RDB do different jobs, and both cost a fork
The two are usually presented as alternatives. They are better understood as a recovery mechanism and a backup mechanism, and most production instances want both.
The AOF is what you recover from
It is a log of every write, replayed on startup. With appendfsync everysec the worst case is one second of writes, which is what makes it the recovery path rather than the snapshot.
The RDB is what you copy off the box
A single compact file at a point in time. It loads much faster than replaying an AOF and it is what a backup job should take. It is a poor recovery mechanism precisely because it is point in time.
appendfsync always is not the safe default
It makes every write wait for an fsync, costing roughly an order of magnitude in throughput. It is the strongest durability Redis offers and it is rarely what was intended: everysec is the default because losing at most one second is usually the right trade.
Peak disk is not the dataset size
A rewrite writes a new AOF while the old one still exists, so peak disk is roughly the dataset plus the RDB plus two AOF copies. A full disk during a rewrite stops writes with a MISCONF error, which is a confusing symptom for a disk problem.
Rewrites are triggered by growth, not by the clock
auto-aof-rewrite-percentage 100 means rewrite when the file has doubled since the last one. The interval therefore depends entirely on the write rate, so an instance can go from one rewrite a day to one every few minutes when traffic changes.
Related redis tools
Redis RDB and AOF Size Calculator The fork needs memory, not disk Redis Config File Generator A redis.conf with the reasons in it Redis Maxmemory Config Generator The limit, and the headroom it needs Redis TLS Config Generator Encrypted, and the old port actually closed Redis Sentinel Config Generator Failover that can actually be authorised Redis Cluster Config Generator Three primaries, and the bus port open
All 53 redis tools