Merge pull request #212776 from flang-msft/fxl---Error-in-High-availability-and-disaster-recovery-doc-

fxl---Error in "High availability and disaster recovery" doc

Author: Court72

articles/azure-cache-for-redis/cache-high-availability.md

@@ -2,6 +2,7 @@
 title: High availability for Azure Cache for Redis
 description: Learn about Azure Cache for Redis high availability features and options
 author: flang-msft
+
 ms.service: cache
 ms.topic: conceptual
 ms.date: 03/29/2022
@@ -12,7 +13,7 @@ ms.author: franlanglois
 
 As with any cloud systems, unplanned outages can occur that result in a virtual machines (VM) instance, an Availability Zone, or a complete Azure region going down. We recommend customers have a plan in place to handle zone or regional outages.
 
-This article presents the information for customers to create a *business continuity and disaster recovery plan* for their Azure Cache for Redis, or Azure Cache for Redis Enterprise implementation.
+This article presents the information for customers to create a _business continuity and disaster recovery plan_ for their Azure Cache for Redis, or Azure Cache for Redis Enterprise implementation.
 
 Various high availability options are available in the Standard, Premium, and Enterprise tiers:
 
@@ -28,11 +29,11 @@ Various high availability options are available in the Standard, Premium, and En
 
 Applicable tiers: **Standard**, **Premium**, **Enterprise**, **Enterprise Flash**
 
-Azure Cache for Redis, in the Standard or Premium tier, has a high availability architecture that ensures your managed instance is functioning, even when outages affect the underlying virtual machines (VMs). Whether the outage is planned or unplanned outages, Azure Cache for Redis delivers much greater percentage availability rates than what's attainable by hosting Redis on a single VM.
+Azure Cache for Redis has a high availability architecture that ensures your managed instance is functioning, even when outages affect the underlying virtual machines (VMs). Whether the outage is planned or unplanned outages, Azure Cache for Redis delivers much greater percentage availability rates than what's attainable by hosting Redis on a single VM.
 
-An Azure Cache for Redis in the Standard or Premium tier runs on a pair of Redis servers by default. The two servers are hosted on dedicated VMs. Open-source Redis allows only one server to handle data write requests.
+An Azure Cache for Redis in the applicable tiers runs on a pair of Redis servers by default. The two servers are hosted on dedicated VMs. Open-source Redis allows only one server to handle data write requests.
 
-With Azure Cache for Redis, one server is the *primary* node, while the other is the *replica*. After it provisions the server nodes, Azure Cache for Redis assigns primary and replica roles to them. The primary node usually is responsible for servicing write and read requests from  clients. On a write operation, it commits a new key and a key update to its internal memory and replies immediately to the client. It forwards the operation to the *replica* asynchronously.
+With Azure Cache for Redis, one server is the _primary_ node, while the other is the _replica_. After it provisions the server nodes, Azure Cache for Redis assigns primary and replica roles to them. The primary node usually is responsible for servicing write and read requests from  clients. On a write operation, it commits a new key and a key update to its internal memory and replies immediately to the client. It forwards the operation to the _replica_ asynchronously.
 
 :::image type="content" source="media/cache-high-availability/replication.png" alt-text="Data replication setup":::
 
@@ -41,7 +42,16 @@ With Azure Cache for Redis, one server is the *primary* node, while the other is
 >
 >
 
-If the *primary* node in a cache is unavailable, the *replica* promotes itself to become the new primary automatically. This process is called a *failover*. The replica waits for a sufficiently long time before taking over in case that the primary node recovers quickly. When a failover happens, Azure Cache for Redis provisions a new VM and joins it to the cache as the replica node. The replica does a full data synchronization with the primary so that it has another copy of the cache data.
+If the _primary_ node in a cache is unavailable, the _replica_ automatically promotes itself to become the new primary. This process is called a _failover_. A failover is just two nodes, primary/replica, trading roles, replica/primary, with one of the nodes possibly going offline for a few minutes. In most failovers, the primary and replica nodes coordinate the handover so you have near zero time without a primary.
+
+The former primary goes offline briefly to receive updates from the new primary. Then, the now replica comes back online and rejoins the cache fully synchronized. The key is that when a node is unavailable, it's a temporary condition and it comes back online.
+
+A typical failover sequence looks like this, when a primary needs to go down for maintenance:
+
+1. Primary and replica nodes negotiate a coordinated failover and trade roles.
+1. Replica (formerly primary) goes offline for a reboot.
+1. A few seconds or minutes later, the replica comes back online.
+1. Replica syncs the data from the primary.
 
 A primary node can go out of service as part of a planned maintenance activity, such as an update to Redis software or the operating system. It also can stop working because of unplanned events such as failures in underlying hardware, software, or network. [Failover and patching for Azure Cache for Redis](cache-failover.md) provides a detailed explanation on types of failovers. An Azure Cache for Redis goes through many failovers during its lifetime. The design of the high availability architecture makes these changes inside a cache as transparent to its clients as possible.
 
@@ -70,14 +80,14 @@ A zone redundant cache provides automatic failover. When the current primary nod
 
 ### Enterprise and Enterprise Flash tiers
 
-A cache in either Enterprise tier runs on a Redis Enterprise *cluster*. It always requires an odd number of server nodes to form a quorum. By default, it has three nodes, each hosted on a dedicated VM.
+A cache in either Enterprise tier runs on a Redis Enterprise _cluster_. It always requires an odd number of server nodes to form a quorum. By default, it has three nodes, each hosted on a dedicated VM.
 
-- An Enterprise cache has two same-sized *data nodes* and one smaller *quorum node*.
+- An Enterprise cache has two same-sized _data nodes_ and one smaller _quorum node_.
 - An Enterprise Flash cache has three same-sized data nodes.
 
-The Enterprise cluster divides Azure Cache for Redis data into partitions internally. Each partition has a *primary* and at least one *replica*. Each data node holds one or more partitions. The Enterprise cluster ensures that the primary and replica(s) of any partition are never collocated on the same data node. Partitions replicate data asynchronously from primaries to their corresponding replicas.
+The Enterprise cluster divides Azure Cache for Redis data into partitions internally. Each partition has a _primary_ and at least one _replica_. Each data node holds one or more partitions. The Enterprise cluster ensures that the primary and replica(s) of any partition are never collocated on the same data node. Partitions replicate data asynchronously from primaries to their corresponding replicas.
 
-When a data node becomes unavailable or a network split happens, a failover similar to the one described in [Standard replication](#standard-replication-for-high-availability) takes place. The Enterprise cluster uses a quorum-based model to determine which surviving nodes participates in a new quorum. It also promotes replica partitions within these nodes to primaries as needed.
+When a data node becomes unavailable or a network split happens, a failover similar to the one described in [Standard replication](#standard-replication-for-high-availability) takes place. The Enterprise cluster uses a quorum-based model to determine which surviving nodes participate in a new quorum. It also promotes replica partitions within these nodes to primaries as needed.
 
 ## Persistence
 
@@ -126,9 +136,9 @@ For more information on force-unlinking, see [Force-Unlink if there's region out
 
 Applicable tiers: **Standard**, **Premium**, **Enterprise**, **Enterprise Flash**
 
-If you experience a regional outage, consider recreating your cache in a different region and updating your application to connect to the new cache instead. It's important to understand that data will be lost during a regional outage. Your application code should be resilient to data loss.
+If you experience a regional outage, consider recreating your cache in a different region, and updating your application to connect to the new cache instead. It's important to understand that data will be lost during a regional outage. Your application code should be resilient to data loss.
 
-Once the affected region is restored, your unavailable Azure Cache for Redis is automatically restored and available for use again. For more strategies for moving your cache to a different region, see [Move Azure Cache for Redis instances to different regions](./cache-moving-resources.md).
+Once the affected region is restored, your unavailable Azure Cache for Redis is automatically restored, and available for use again. For more strategies for moving your cache to a different region, see [Move Azure Cache for Redis instances to different regions](./cache-moving-resources.md).
 
 ## Next steps