Can the AOF Log be the Backup

[Kevin Johnson]

Hello,

The Redis documentation on persistence states this:

"There are many users using AOF alone, but we discourage it since to have an RDB snapshot from time to time is a great idea for doing database backups, for faster restarts, and in the event of bugs in the AOF engine."

1. Assuming there aren't "bugs in the AOF engine", why can't the AOF log serve as a back up?

2. I was also wondering if the Redis server blocks during the AOF fsync process much like it does when RDB snapshotting?

Thanks!

-Kevin

[hva...@gmail.com]

I can't speak for the writers of the documentation, but what I see in that one sentence is the assumption that a Redis server process is writing to an AOF without a BGREWRITEAOF event for a long time.  The resulting AOF will likely be large (taking longer to load) and will have obsolete keys and obsolete values for some/many keys.  The obsolete keys and/or values are ones that were created and then deleted while Redis was writing to the AOF.  Restoring from the AOF will still create the keys and then delete them because the creation and deletion commands are present in the AOF.  Keys that have many updates (like counters) will have the original values and each update in the AOF, not just the values at the time of the crash.  Having these obsolete keys/values in the AOF is not harmful to restoring the Redis database, it just means the AOF is bigger and slower to load.  This will be a big issue for some situations and a small issue for other situations.

Generally, performing an fsync() call on an open file descriptor does not block the process that makes the call.  The kernel performs it's work of flushing the buffered data onto the disk in separate threads that don't block Redis.

[Kevin Johnson]

Thanks for your reply!

Right now we are going to try operating with AOF persistence only, coupled with daily RDB snapshots.