Blocks until the asynchronous replication of all preceding write commands sent by the connection is completed.
WAIT
numreplicas
timeout
This command blocks the current client until all the previous write commands are successfully transferred and acknowledged by at least the specified number of replicas. If the timeout, specified in milliseconds, is reached, the command returns even if the specified number of replicas were not yet reached.
The command will always return the number of
replicas that acknowledged the write commands sent by the current client
before the WAIT
command, both in the case where the
specified number of replicas are reached, or when the timeout is
reached.
A few remarks:
WAIT
returns, all the previous write commands sent
in the context of the current connection are guaranteed to be received
by the number of replicas returned by WAIT
.WAIT
returns the number of replicas reached both
in case of failure and success, the client should check that the
returned value is equal or greater to the replication level it
demanded.Note that WAIT
does not make Valkey a strongly
consistent store: while synchronous replication is part of a replicated
state machine, it is not the only thing needed. However in the context
of Sentinel or Valkey Cluster failover, WAIT
improves the
real world data safety.
Specifically if a given write is transferred to one or more replicas, it is more likely (but not guaranteed) that if the primary fails, we’ll be able to promote, during a failover, a replica that received the write: both Sentinel and Valkey Cluster will do a best-effort attempt to promote the best replica among the set of available replicas.
However this is just a best-effort attempt so it is possible to still lose a write synchronously replicated to multiple replicas.
Since the introduction of partial resynchronization with replicas (PSYNC feature) Valkey replicas asynchronously ping their primary with the offset they already processed in the replication stream. This is used in multiple ways:
WAIT
.In the specific case of the implementation of WAIT
,
Valkey remembers, for each client, the replication offset of the
produced replication stream when a given write command was executed in
the context of a given client. When WAIT
is called Valkey
checks if the specified number of replicas already acknowledged this
offset or a greater one.
Integer reply: the command returns the number of replicas reached by all the writes performed in the context of the current connection.
Integer reply: the number of replicas reached by all the writes performed in the context of the current connection.
O(1)
@blocking @connection @slow
> SET foo bar
OK
> WAIT 1 0
(integer) 1
> WAIT 2 1000
(integer) 1
In the following example the first call to WAIT
does not
use a timeout and asks for the write to reach 1 replica. It returns with
success. In the second attempt instead we put a timeout, and ask for the
replication of the write to two replicas. Since there is a single
replica available, after one second WAIT
unblocks and
returns 1, the number of replicas reached.
COPY, DEL, DUMP, EXISTS, EXPIRE, EXPIREAT, EXPIRETIME, KEYS, MIGRATE, MOVE, OBJECT, OBJECT ENCODING, OBJECT FREQ, OBJECT HELP, OBJECT IDLETIME, OBJECT REFCOUNT, PERSIST, PEXPIRE, PEXPIREAT, PEXPIRETIME, PTTL, RANDOMKEY, RENAME, RENAMENX, RESTORE, SCAN, SORT, SORT_RO, TOUCH, TTL, TYPE, UNLINK, WAITAOF.