diff --git a/content/operate/rs/clusters/optimize/wait.md b/content/operate/rs/clusters/optimize/wait.md index f2ff666c66..21e1d70978 100644 --- a/content/operate/rs/clusters/optimize/wait.md +++ b/content/operate/rs/clusters/optimize/wait.md @@ -1,62 +1,54 @@ --- -Title: Use the WAIT command for strong consistency +Title: Use the WAIT command to improve data safety and durability alwaysopen: false categories: - docs - operate - rs description: Use the wait command to take full advantage of Redis Enterprise Software's - replication based durability. + replication-based durability. linkTitle: WAIT command weight: $weight --- Redis Enterprise Software comes with the ability to replicate data to another replica for high availability and persist in-memory data on -disk permanently for durability. With the WAIT command, you can +disk permanently for durability. With the [`WAIT`]({{}}) command, you can control the consistency and durability guarantees for the replicated and persisted database. -Any updates that are issued to the database are typically performed with -the following flow shown below; +## Non-blocking Redis write operation -1. Application issues a write, -1. Proxy communicates with the correct master "shard" in the system - that contains the given key, -1. The acknowledgment is sent to proxy once the write operation - completes +Any updates that are issued to the database are typically performed with the following flow: + +1. Application issues a write. +1. Proxy communicates with the correct primary shard in the system that contains the given key. +1. The acknowledgment is sent to proxy after the write operation completes. 1. The proxy sends the acknowledgment back to the application. -Independently, the write is communicated from master to replica and -replication acknowledges the write back to the master. These are steps 5 -and 6. +Independently, the write is communicated from the primary shard to the replica, and +replication acknowledges the write back to the primary shard. These are steps 5 and 6. Independently, the write to a replica is also persisted to disk and acknowledged within the replica. These are steps 7 and 8. {{< image filename="/images/rs/weak-consistency.png" >}} -With the WAIT command, applications can ask to wait for +## Blocking write operation on replication + +With the [`WAIT`]({{}}) or [`WAITAOF`]({{}}) commands, applications can ask to wait for acknowledgments only after replication or persistence is confirmed on -the replica. The flow of a write operation with the WAIT command is -shown below: - -1. Application issues a write, -1. Proxy communicates with the correct master "shard" in the system - that contains the given key, -1. Replication communicated the update to the replica shard. -1. Replica persists the update to disk (assuming AOF every write setting - is selected). -1. The acknowledgment is sent back from the replica all the way to the - proxy with steps 5 to 8. - -With this flow, the application only gets the acknowledgment from the -write after durability is achieved with replication to the replica and to -the persistent storage. +the replica. The flow of a write operation with `WAIT` or `WAITAOF` is: + +1. The application issues a write. +1. The proxy communicates with the correct primary shard in the system that contains the given key. +1. Replication communicates the update to the replica shard. +1. If using `WAITAOF` and the AOF every write setting, the replica persists the update to disk before sending the acknowledgment. +1. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8. + +The application only gets the acknowledgment from the write after durability is achieved with replication to the replica for `WAIT` or `WAITAOF` and to the persistent storage for `WAITAOF` only. {{< image filename="/images/rs/strong-consistency.png" >}} -With the WAIT command, applications can have a guarantee that even under -a node failure or node restart, an acknowledged write is recorded. +The `WAIT` command always returns 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. In Redis Enterprise Software, the number of replicas is always 1 for databases with high availability enabled. -See the WAIT command for details on the new durability and -consistency options. +See the [`WAITAOF`]({{}}) command for details for enhanced data safety and durability capabilities introduced with Redis 7.2. diff --git a/content/operate/rs/databases/durability-ha/consistency.md b/content/operate/rs/databases/durability-ha/consistency.md index b31e7c15bd..6535614e68 100644 --- a/content/operate/rs/databases/durability-ha/consistency.md +++ b/content/operate/rs/databases/durability-ha/consistency.md @@ -5,50 +5,47 @@ categories: - docs - operate - rs -description: Explains the order write operations are communicated from app to proxy - to shards for both the weak consistency model and the strong consistency model. +description: Explains the order write operations are communicated from app to proxy to shards for both non-blocking Redis write operations and blocking write operations on replication. linkTitle: Consistency weight: 20 --- Redis Enterprise Software comes with the ability to replicate data to another database instance for high availability and persist in-memory data on -disk permanently for durability. With the WAIT command, you can +disk permanently for durability. With the [`WAIT`]({{}}) command, you can control the consistency and durability guarantees for the replicated and persisted database. -Any updates that are issued to the database are typically performed with -the following flow shown below; +## Non-blocking Redis write operation -1. Application issues a write -2. Proxy communicates with the correct primary (also known as master) "shard" in the system that contains the given key -3. The shard writes the data and sends an acknowledgment to the proxy -4. The proxy sends the acknowledgment back to the application -5. The write is communicated from master to replica -6. Replica acknowledges the write back to the master -7. The write to a replica is persisted to disk -8. The write is acknowledged within the replica +Any updates that are issued to the database are typically performed with the following flow: + +1. The application issues a write. +2. The proxy communicates with the correct primary (also known as master) shard in the system that contains the given key. +3. The shard writes the data and sends an acknowledgment to the proxy. +4. The proxy sends the acknowledgment back to the application. +5. The write is communicated from the primary shard to the replica. +6. The replica acknowledges the write back to the primary shard. +7. The write to a replica is persisted to disk. +8. The write is acknowledged within the replica. {{< image filename="/images/rs/weak-consistency.png" >}} -With the WAIT command, applications can ask to wait for +## Blocking write operation on replication + +With the [`WAIT`]({{}}) or [`WAITAOF`]({{}}) commands, applications can ask to wait for acknowledgments only after replication or persistence is confirmed on -the replica. The flow of a write operation with the WAIT command is -shown below: +the replica. The flow of a write operation with `WAIT` or `WAITAOF` is: -1. Application issues a write, -2. Proxy communicates with the correct master "shard" in the system that contains the given key, -3. Replication communicated the update to the replica shard. -4. Replica persists the update to disk (assuming AOF every write setting is selected). -5-8. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8. +1. The application issues a write. +2. The proxy communicates with the correct primary shard in the system that contains the given key. +3. Replication communicates the update to the replica shard. +4. If using `WAITAOF` and the AOF every write setting, the replica persists the update to disk before sending the acknowledgment. +5. The acknowledgment is sent back from the replica all the way to the proxy with steps 5 to 8. -With this flow, the application only gets the acknowledgment from the -write after durability is achieved with replication to the replica and to -the persistent storage. +The application only gets the acknowledgment from the write after durability is achieved with replication to the replica for `WAIT` or `WAITAOF` and to the persistent storage for `WAITAOF` only. {{< image filename="/images/rs/strong-consistency.png" >}} -With the WAIT command, applications can have a guarantee that even under -a node failure or node restart, an acknowledged write is recorded. +The `WAIT` command always returns 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. In Redis Enterprise Software, the number of replicas for HA enabled databases is always 1. -See the WAIT command for details on the new durability and -consistency options. +See the [`WAITAOF`]({{}}) command for details for enhanced data safety and durability capabilities introduced with Redis 7.2. diff --git a/static/images/rs/strong-consistency.png b/static/images/rs/strong-consistency.png index 6dca6d6c1c..ceaa1aef1f 100644 Binary files a/static/images/rs/strong-consistency.png and b/static/images/rs/strong-consistency.png differ diff --git a/static/images/rs/weak-consistency.png b/static/images/rs/weak-consistency.png index f89dbb2492..21b21a2325 100644 Binary files a/static/images/rs/weak-consistency.png and b/static/images/rs/weak-consistency.png differ