Update: Redis creator Salvatore Sanfilippo responded to my pull request documenting this method of disabling bgsave with this comment. Since he agrees there should be a community design process around supporting the disabling of persistence in redis, I added a new issue to allow that discussion to happen. Looking forward to seeing the design process and being a part of it.
Update: Initial work on officially supporting a ‘disable persistence’ configuration has begun by Matt Stancliff. See Matt’s work here. This is awesome to see. Thanks Matt!
I spent hours researching and scheming on how to prevent redis from writing any database values to disk, since the redis instance will be handling sensitive information. (In our case we’re storing cvv’s for 60 minutes and due to PCI compliance regarding credit card usage, absolutely cannot write these values to disk - ever.)
Read the docs, the config file, googled, tested, and even tried telling it to write to /dev/null.
Finally the answer came from ‘TheRealBill_here’ on the #redis irc channel:
dbfilename ""
in the config file.
Here’s a link to our whole conversation if you’re interested.
I also submitted a pull request to add a note in the config file for redis.
This answer came to me after I had already made a couple of other decisions about configuring redis to store credit card information:
loglevelhas a default of info, which won’t print each read/write, so we’re good there. Although for our use case we would probably feel comfortable just disabling logging altogether.savedirective is set atsave ""so that snapshotting is definitely disabled.replicationnot in play. When using replication, the master initializes a slave by writing its own database contents to disk, sending the slave that file, and the slave loading the database dump into its database. Obviously, we can’t do that. (Also note that if we did add a slave at some point, it wouldn’t be able to sync with our current config ofdbfilename "". See the log for the error when you callbgsavefromredis-cliyourself.)