Saving best practices

[David Gonzalez]

It seems like the "save" command [1] isn't something you want to do in a production env due to its performance (blocking) impacts, but rather we prefer the async bgsave [2]

If I wanted to "save" after every transaction, is it appropriate in redis to issue a bgsave command after each set of set/del/etc. Or is it more appropriate to use snapshotting:

[1] http://redis.io/commands/save

[2] http://redis.io/commands/bgsave

[David Gonzalez]

posted too soon - darn chrome shortcuts :)

Full question:

It seems like the "save" command [1] isn't something you want to do in a production env due to its performance (blocking) impacts, but rather we prefer the async bgsave [2]

If I wanted to "save" after every transaction, is it appropriate in redis to issue a bgsave command after each set of set/del/etc. Or is it more appropriate to use snapshotting:   save 60 1000

What is the "usual" way of persisting changes changes in redis for data updates that you know you will want to persist (rather than treating redis as a more transient cache).

[1] http://redis.io/commands/save

[2] http://redis.io/commands/bgsave

[Sam Hendley]

This is one of the tricky bits about using redis well. You can "tune" your persistence requirements to match your usecase. I would recommend looking at configuring your server with AOF with an fsync every second. Its a question of how important your data really is. One technique is to put the critical, can't lose any, data on a different server and configure that with the super slow but guaranteed fysnc all commands settings. 

http://redis.io/topics/persistence

--
You received this message because you are subscribed to the Google Groups "Jedis" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jedis_redis...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Gonzalez]

Sam,

Thanks for the info. I read up on persistence a bit more and AOF (appendfsync everysec) seems pretty reasonable for a durable dataset. With AOF it doesnt appear there is a need to call SAVE/BGSAVE, since all writes automatically get written to the AOF.

Out of curiosity, can there be serious real performance implications of calling BGSAVE after each write (non RDB mode) -- it seems like with RDB mode, the preferred method is to save periodically (config set save X Y) rather than immediately.  Is there a particularly common use case where bgsave is used to force persistence? Ex. Certain writes mode actual "data" and other data is cache data.

Thanks!