Nothing written to disk
The right answer for a pure cache, and data loss for anything else
- durability
- none
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.
Worked setups you can load into the form above. Each one is a decision the generator makes differently, and the reason it makes it.
The right answer for a pure cache, and data loss for anything else
The strongest durability, and roughly an order of magnitude slower
These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.