AOF files are usually bigger than the equivalent RDB files for the same dataset.For instance even if you've accidentally flushed everything using the FLUSHALL command, as long as no rewrite of the log was performed in the meantime, you can still save your data set just by stopping the server, removing the latest command, and restarting Redis again. AOF contains a log of all the operations one after the other in an easy to understand and parse format.The rewrite is completely safe as while Redis continues appending to the old file, a completely new one is produced with the minimal set of operations needed to create the current data set, and once this second file is ready Redis switches the two and starts appending to the new one. Redis is able to automatically rewrite the AOF in background when it gets too big.Even if the log ends with a half-written command for some reason (disk full or other reasons) the redis-check-aof tool is able to fix it easily. The AOF log is an append-only log, so there are no seeks, nor corruption problems if there is a power outage.fsync is performed using a background thread and the main thread will try hard to perform writes when no fsync is in progress, so you can only lose one second worth of writes. With the default policy of fsync every second, write performance is still great. Using AOF Redis is much more durable: you can have different fsync policies: no fsync at all, fsync every second, fsync at every query. AOF also needs to fork() but less frequently and you can tune how often you want to rewrite your logs without any trade-off on durability. fork() can be time consuming if the dataset is big, and may result in Redis stopping serving clients for some milliseconds or even for one second if the dataset is very big and the CPU performance is not great.
0 Comments
Leave a Reply. |