Here is the scenario: the client needs one way to ensure that even in the event of a crash, Redis does not lose the data the client just wrote.

Setting appendonly to true and appendfsync to always seems to be the closest solution. However, there is stil the possibility that Redis crashes just after responding to the client with "OK" and before persisting the data to disk. There would be no way for the client to know that the data is lost, which will lead to inconsistent behavior (from the client's view).

As far as I'm concerned, an option to make Redis respond after fsync should resolve the issue (or maybe an additional WAITFSYNC command).

Comment From: yossigo

@ouromoros The OK reply is placed in the client output buffer but it is not written to the socket until fsync is done. There is a write barrier mechanism in the event loop built for this purpose.

Comment From: ShooterIT

Yes, redis does much work to guarantee to call fsync AOF if clients receive reply.

hi @yossigo I noticed we only judge the return of write(https://github.com/redis/redis/blob/unstable/src/aof.c#L453) but not judge the return of fsync. SoI submit a PR https://github.com/redis/redis/pull/8347, redis also exits for fsync error when the aof sync policy is always just like occurring write error

Comment From: ShooterIT

WAITFSYNC command

One way i think of to avoid decreasing performance too much, just like writeOptions.sync = true of leveldb/rocksdb

config set appendfsync always
set $key $value

And we may need to reset old configuration of appendfsync if needed.

Comment From: yossigo

@ShooterIT Another possible approach we've discussed in the past is to hold back replies based on the required offset.

Basically you can think of it as an extension to AOF_FSYNC_EVERYSEC as fsync still happens in the background and does not block the main thread. However, client replies are associated with a specific fsync and are delayed until the operation related to the replies is committed to disk.

A specific user will still experience the latency fsync invovles, but the server as a whole will be able to serve more requests and have better throughput.

Comment From: ShooterIT

Thanks @yossigo that's a good idea to satisfy users' fsync requirements and only block specific clients instead of entire server.

Comment From: yossigo

Closing this issue as TLDR; the original concern is not an issue - appendfsync always guarantees replies are delivered after fsync.