1

I was reading this article about Tarantool and they seem to say that AOF and WAL log are not working the same way.

Tarantool: besides snapshots, it has a full-scale WAL (write ahead log). So it can secure data persistency after each transaction out-of-the-box. Redis: in fact, it has snapshots only. Technically, you have AOF (append-only file, where all the operations are written), but it requires manual control over it, including manual restore after reboot. Simply put, with Redis you need to manually suspend the server now and then, make snapshots and archive AOF.

Could someone explain more clearly what is the different between the 2 strategy and how each work at a high level.

I always assumed that Redis AOF was working the same way to a SQL database transaction log such as implemented in Postgresql but I might have been wrong.

skyde
  • 2,816
  • 4
  • 34
  • 53

2 Answers2

6

AOF is the main persistence option for Redis. Any time there's a write operation that modifies the dataset in memory, that operation is logged. So during a restart, Redis will replay all of the operations to reconstruct the dataset. You also have 3 different fsync configuration policies to choose from (no, everysec, always). FWIW, it is usually advised to use both AOF + RDB in the event you want a good level of data-safety. This is kind of outside of the scope of your question, but figured i'd mention it.

Main Redis Persistence Docs

Redis Persistence Demystified

Tarantool's uses something called a "WAL writer". This will run in a separate thread and log requests that manipulate data "insert and update requests". On restart, Tarantool recovers by reading the WAL file and replaying each of the requests.

Tarantool Persistence Docs

There's a difference in the internals obviously, but at a high level they are pretty similar. The persistence comparison in the article is pretty odd and simply not true.

For more information on the low level differences, refer to the docs listed above.

Hope that helps

davissp14
  • 765
  • 4
  • 13
2

Redis:

  • IIRC, Redis writes log in the same thread it serves requests. That leads to stall if disk is slow for some reason (RDB write, AOF rewrite): single write operation could freeze whole serving thread until write syscall finished.
  • Redis could not use AOF for replication restore because AOF doesn't contain operation position. Replica can rely only on master's memory buffer and re-request full snapshot if buffer were not large enough to hold operations since previous snapshot were started. I had once non-restored replica during half-an-hour until I recognize it and increased master's buffer size manually.

Tarantool:

  • Tarantool writes WAL in a separate thread, transaction thread talks to it asynchronously. There could be many write operations waiting for WAL simultaneously, and read operation aren't blocked at all.
  • Tarantool stores LSN in WAL, and replica could use WAL for restoration even it were down for hours. Replica even has no operation "re-request snapshot" because in practice it never lags so far that there is no enough WAL on master.
funny_falcon
  • 427
  • 3
  • 11