4 ms·
Change the default `stop-writes-on-bgsave-error` to "no" or you're asking for trouble... a ticking time bomb.
by welder 3y ago
Change the default `stop-writes-on-bgsave-error` to "no" or you're asking for trouble... a ticking time bomb.
- chrisbolt 3y agoIsn’t it another ticking time bomb to accept writes that will be lost if the server is shut down?
- GauntletWizard 3y agoExpecting that any key in redis will be there next time you read it is a ticking timebomb. Redis is not a database. It's a cache. Unless you're using AOF mode with fsync always, you can lose writes. If you're doing that, you should be using a real database instead.
- chrisbolt 3y agoThe first line of redis.io: > The open source, in-memory data store
- GauntletWizard 3y agoI don't mean to knock redis. I love redis. I implore you to benchmark Redis in FSYNC_ALWAYS vs Postgres. I encourage you to benchmark it as well with FSYNC_EVERYSEC and understand the tradeoffs that makes - Postgres is still very competitive with EVERYSEC in most workloads, and with a lot less tradeoffs in data reliability.
- yawaramin 3y agoYeah, in-memory. That should tell you it's not a persistent data store.
- deleted 3y ago[deleted]
- welder 3y agoAlso, comment out all `SAVE` to disable snapshotting so you can use the full machine RAM. Otherwise, you have to limit Redis to 50% RAM usage because Redis duplicates the dataset in memory when saving to disk, wasting half the machine's RAM. If you go over 50% RAM usage with snapshotting enabled you risk triggering bgsave error. Finally, check out Redis-compatible alternatives that don't require the data set to fit in RAM. [0] 0: https://github.com/ideawu/ssdb https://github.com/ideawu/ssdb