The problem/use-case that the feature addresses

There's a purely synchronous SAVE operation and async background operations, BGSAVE and BGREWRITEAOF. Using the latter is recommended as SAVE will block out all other activity until it completes. However the two BG operations only schedule the action, they do not wait for it to finish so it's up to the user to poll via LASTSAVE for completion. Even the manual suggests:

A client may check if a BGSAVE command succeeded reading the LASTSAVE value, then issuing a BGSAVE command and checking at regular intervals every N seconds if LASTSAVE changed. (https://redis.io/commands/lastsave)

It'd be nice to issue a command that will not block the server, but complete when the the save operation has completed. That way the client does not have to poll.

This is a particular pain in backup scripts as blindly copying the current state of the RDB / AOF files is not correct. They need to be persisted prior to the copy to ensure that the backup reflects the state of the server prior to the backup.

Description of the feature

Save RDB or rewrite the AOF file with a command that will not block the server and return back success when it completes. This will make it easier to use in backup scripts as we can run that command prior to copying the RDB / AOF files and ensure that we have everything up to the start of the backup persisted.

This could be done with an additional argument "WAIT", e.g. BGSAVE WAIT or BGREWRITEAOF WAIT

Alternatives you've considered

Writing a wrapper script that does the polling. Would be useful for older versions.

Could also add this as part of the redis-cli with the polling logic in the client. That would allow the recent client to work with older servers and leverage the newer feature.

Comment From: yoav-steinberg

Using LASTSAVE with a script that waits for it to be updated should be fine. An even simpler solution can be to use the INFO PERSISTENCE command and polling the rdb_bgsave_in_progress until it's 0. I don't see much value in adding a blocking command here when it's easy to poll without any real implications.

Comment From: svoop

Here's a simple example using INFO PERSISTENCE I use to have a backup prepare script trigger a snapshot and then wait for completion:

echo "BGSAVE" | redis-cli >/dev/null
finished=0
while [ $finished -eq 0 ]; do
  sleep 2
  echo "INFO PERSISTENCE" | redis-cli | grep -q "rdb_bgsave_in_progress:1"
  finished=$?
done

As a side note: It doesn't produce an infinite loop if Redis is down.

Comment From: yoav-steinberg

@svoop Thanks, good script. Just note that there are a few minor issues with the script above that might not be relevant in your case, but still worth mentioning: - The initial BGSAVE command might fail (for example if redis is doing an AOF rewrite or some module is doing some fork work). In that case you'll detect you're finished but actually you never started. - If the background saving failed for some reason you might also want to check rdb_last_bgsave_status and rdb_last_save_time. - If the saving is really quick you might be waiting 2 secs needlessly. In some cases it might be better to poll INFO PERSISTENCE before the sleep.

Comment From: svoop

@yoav-steinberg Thanks for your valid remarks, indeed, the are not important in my case since a skipped backup doesn't hurt and I monitor the dumps as they go offsite. However, this is most likely not the case for everybody using BGSAVE, therefore:

I don't see much value in adding a blocking command here when it's easy to poll without any real implications.

Not that easy after all: To make it 100% fail proof, you'd have to check whether the BGSAVE fails, then monitor three values rdb_bgsave_in_progress, rdb_last_bgsave_status and rdb_last_save_time and (if you don't want to waste time) poll in short intervals. And all that for RDB, it gets worse if you choose to add AOF to the mix.

I see the point of the OP @sehrope, it would be nice to have a simple backup (and restore) command which is not blocking the database, but waiting for everything to finish and then returns red or green, maybe even for RDB only or RDB+AOF.

As of now, you find backup script gists online with close to 50 LOC, quite complex and therefore error prone for such a simple task IMO.