The problem/use-case that the feature addresses

It just came to my mind that if shutdown-on-sigint/shutdown-on-sigterm = save on an instance with AOF turned on, we could actually start from RDB and get two things for free: - PSYNC possibility - Faster startup (well, the shutdown will be slower, so this one just balance things out)

We need to delete the AOF on successful SAVE for shutdown and load from RDB when no AOF found in order to have those benefits.

Description of the feature

When there's a successful SAVE on shutdown, simply delete AOF. On start, load RDB if no AOF found (we may need to create a config as it's a breaking change)

Alternatives you've considered

  • Implement PSYNC from AOF.
  • Implement blocking REWRITEAOF on shutdown instead, where it generates an RDB as base file and that would be used for PSYNC.

Additional information

Redis documentation already suggests a mitigation for PSYNC when restarting from AOF: https://redis.io/docs/manual/replication/ "It is not possible to partially sync a replica that restarted via the AOF file. However the instance may be turned to RDB persistence before shutting down it, than can be restarted, and finally AOF can be enabled again."

This feature will actually just automate those steps, no need for manual intervention to get PSYNC.

Comment From: oranagra

For this to work properly, on startup we'll need to do this (to avoid an AOFRW on startup): 1. detect the fact that AOF is enabled, but the AOF file is missing and an RDB file is found. 2. when done loading the RDB file, we'll need to copy (or hard link) the RDB file to the AOF folder and create a manifest around it.

Now that we have multi-part AOF, and the overheads of AOF are lower, I think we want to generally discourage use both RDB and AOF persistence side by side. Instead the snapshotting configurations (save) can trigger an AOFRW (if you already bother to make a snapshot, you might as well also reduce the AOF size). Then, SHUTDOWN SAVE could do an AOFRW instead of generating an RDB file, which will result in a fast startup from AOF and no need for the hard link i mentioned above. We could even make that SHUTDOWN SAVE a non-blocking one (in the spirit of #9872, we can initiate an AOFRW, keep processing traffic, even write commands, and then terminate when the rewrite is completed).

Comment From: oranagra

btw, i realize that we already have an issue on this topic: #9795