Merge pull request #92070 from abinav2307/main

Court72 · web-flow · commit 1fe32bfaf90f · 2022-04-27T10:50:15.000-06:00
Update distribute-data-globally.md
diff --git a/articles/cosmos-db/distribute-data-globally.md b/articles/cosmos-db/distribute-data-globally.md
@@ -46,7 +46,7 @@ As you add and remove regions to and from your Azure Cosmos account, your applic
 
 **Build highly available apps.** Running a database in multiple regions worldwide increases the availability of a database. If one region is unavailable, other regions automatically handle application requests. Azure Cosmos DB offers 99.999% read and write availability for multi-region databases.
 
-**Maintain business continuity during regional outages.** Azure Cosmos DB supports [automatic failover](how-to-manage-database-account.md#automatic-failover) during a regional outage. During a regional outage, Azure Cosmos DB continues to maintain its latency, availability, consistency, and throughput SLAs. To help make sure that your entire application is highly available, Cosmos DB offers a manual failover API to simulate a regional outage. By using this API, you can carry out regular business continuity drills.
+**Maintain business continuity during regional outages.** Azure Cosmos DB supports [service-managed failover](how-to-manage-database-account.md#automatic-failover) during a regional outage. During a regional outage, Azure Cosmos DB continues to maintain its latency, availability, consistency, and throughput SLAs. To help make sure that your entire application is highly available, Cosmos DB offers a manual failover API to simulate a regional outage. By using this API, you can carry out regular business continuity drills.
 
 **Scale read and write throughput globally.** You can enable every region to be writable and elastically scale reads and writes all around the world. The throughput that your application configures on an Azure Cosmos database or a container is provisioned across all regions associated with your Azure Cosmos account. The provisioned throughput is guaranteed up by [financially backed SLAs](https://azure.microsoft.com/support/legal/sla/cosmos-db/v1_3/).
 
diff --git a/articles/cosmos-db/high-availability.md b/articles/cosmos-db/high-availability.md
@@ -88,7 +88,7 @@ Service-managed failover allows Cosmos DB to fail over the write region of multi
 Refer to [How to manage an Azure Cosmos DB account](./how-to-manage-database-account.md) for the instructions on how to enable multiple read regions and service-managed failover.
 
 > [!IMPORTANT]
-> It is strongly recommended that you configure the Azure Cosmos accounts used for production workloads to **enable automatic failover**. This enables Cosmos DB to failover the account databases to available regions automatically. In the absence of this configuration, the account will experience loss of write availability for all the duration of the write region outage, as manual failover will not succeed due to lack of region connectivity.
+> It is strongly recommended that you configure the Azure Cosmos accounts used for production workloads to **enable service-managed failover**. This enables Cosmos DB to failover the account databases to available regions automatically. In the absence of this configuration, the account will experience loss of write availability for all the duration of the write region outage, as manual failover will not succeed due to lack of region connectivity.
 
 ### Multiple write regions
 Azure Cosmos DB can be configured to accept writes in multiple regions. This is useful to reduce write latency in geographically distributed applications. When a Cosmos DB account is configured for multiple write regions, strong consistency isn't supported and write conflicts may arise. Refer to [Conflict types and resolution policies when using multiple write regions](./conflict-resolution-policies.md) for more information on how to resolve conflicts in multiple write region configurations.
@@ -107,7 +107,7 @@ Multi-region accounts will experience different behaviors depending on the follo
 | Configuration | Outage | Availability impact | Durability impact| What to do |
 | -- | -- | -- | -- | -- |
 | Single write region  | Read region outage | All clients will automatically redirect reads to other regions. No read or write availability loss for all configurations, except 2 regions with strong consistency which loses write availability until the service is restored or, if **service-managed failover** is enabled, the region is marked as failed and a failover occurs. | No data loss. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support read traffic. <p/> When the outage is over, re-adjust provisioned RUs as appropriate. |
-| Single write region | Write region outage | Clients will redirect reads to other regions. <p/> **Without service-manages failover**, clients will experience write availability loss, until write availability is restored automatically when the outage ends. <p/> **With service-managed failover** clients will experience write availability loss until the services manages a failover to a new write region selected according to your preferences. | If strong consistency level isn't selected, some data may not have been replicated to the remaining active regions. This depends on the consistency level selected as described in [this section](consistency-levels.md#rto). If the affected region suffers permanent data loss, unreplicated data may be lost. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support read traffic. <p/> Do *not* trigger a manual failover during the outage, as it will not succeed. <p/> When the outage is over, re-adjust provisioned RUs as appropriate. Accounts using SQL APIs may also recover the non-replicated data in the failed region from your [conflicts feed](how-to-manage-conflicts.md#read-from-conflict-feed). |
+| Single write region | Write region outage | Clients will redirect reads to other regions. <p/> **Without service-managed failover**, clients will experience write availability loss, until write availability is restored automatically when the outage ends. <p/> **With service-managed failover** clients will experience write availability loss until the services manages a failover to a new write region selected according to your preferences. | If strong consistency level isn't selected, some data may not have been replicated to the remaining active regions. This depends on the consistency level selected as described in [this section](consistency-levels.md#rto). If the affected region suffers permanent data loss, unreplicated data may be lost. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support read traffic. <p/> Do *not* trigger a manual failover during the outage, as it will not succeed. <p/> When the outage is over, re-adjust provisioned RUs as appropriate. Accounts using SQL APIs may also recover the non-replicated data in the failed region from your [conflicts feed](how-to-manage-conflicts.md#read-from-conflict-feed). |
 | Multiple write regions | Any regional outage | Possibility of temporary write availability loss, analogously to single write region with service-managed failover. The failover of the [conflict-resolution region](#conflict-resolution-region) may also cause a loss of write availability if a high number of conflicting writes happen at the time of the outage. | Recently updated data in the failed region may be unavailable in the remaining active regions, depending on the selected [consistency level](consistency-levels.md). If the affected region suffers permanent data loss, unreplicated data may be lost. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support additional traffic. <p/> When the outage is over, you may re-adjust provisioned RUs as appropriate. If possible, Cosmos DB will automatically recover non-replicated data in the failed region using the configured conflict resolution method for SQL API accounts, and Last Write Wins for accounts using other APIs. |
 
 ### Additional information on read region outages
@@ -158,7 +158,7 @@ The following table summarizes the high availability capability of various accou
 
 * To ensure high write and read availability, configure your Azure Cosmos account to span at least two regions and three, if using strong consistency. Remember that the best configuration to achieve high availability for a region outage is single write region with service-managed failover. To learn more, see [Tutorial: Set up Azure Cosmos DB global distribution using the SQL API](tutorial-global-distribution-sql-api.md).
 
-* For multi-region Azure Cosmos accounts that are configured with a single-write region, [enable service-managed failover by using Azure CLI or Azure portal](how-to-manage-database-account.md#automatic-failover). After you enable automatic failover, whenever there's a regional disaster, Cosmos DB will fail over your account without any user inputs.
+* For multi-region Azure Cosmos accounts that are configured with a single-write region, [enable service-managed failover by using Azure CLI or Azure portal](how-to-manage-database-account.md#automatic-failover). After you enable service-managed failover, whenever there's a regional disaster, Cosmos DB will fail over your account without any user inputs.
 
 * Even if your Azure Cosmos account is highly available, your application may not be correctly designed to remain highly available. To test the end-to-end high availability of your application, as a part of your application testing or disaster recovery (DR) drills, temporarily disable automatic-failover for the account, invoke the [manual failover by using PowerShell, Azure CLI or Azure portal](how-to-manage-database-account.md#manual-failover), then monitor your application's failover. Once complete, you can fail back over to the primary region and restore automatic-failover for the account.
 
@@ -173,7 +173,7 @@ For single-region accounts, clients will experience loss of read and write avail
 
 Multi-region accounts will experience different behaviors depending on the following table.
 
-| Write regions | Automatic failover | What to expect | What to do |
+| Write regions | Service-Managed failover | What to expect | What to do |
 | -- | -- | -- | -- |
 | Single write region | Not enabled | In case of outage in a read region when not using strong consistency, all clients will redirect to other regions. No read or write availability loss. No data loss. When using strong consistency, read region outage can impact write availability if fewer than two read regions remaining.<p/> In case of an outage in the write region, clients will experience write availability loss. If strong consistency level isn't selected, some data may not have been replicated to the remaining active regions. This depends on the consistency level selected as described in [this section](consistency-levels.md#rto). If the affected region suffers permanent data loss, unreplicated data may be lost. <p/> Cosmos DB will restore write availability automatically when the outage ends. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support read traffic. <p/> Do *not* trigger a manual failover during the outage, as it will not succeed. <p/> When the outage is over, re-adjust provisioned RUs as appropriate. |
 | Single write region | Enabled | In case of outage in a read region when not using strong consistency, all clients will redirect to other regions. No read or write availability loss. No data loss. When using strong consistency, read region outage can impact write availability if fewer than two read regions remaining.<p/> In case of an outage in the write region, clients will experience write availability loss until Cosmos DB automatically elects a new region as the new write region according to your preferences. If strong consistency level isn't selected, some data may not have been replicated to the remaining active regions. This depends on the consistency level selected as described in [this section](consistency-levels.md#rto). If the affected region suffers permanent data loss, unreplicated data may be lost. | During the outage, ensure that there are enough provisioned RUs in the remaining regions to support read traffic. <p/> Do *not* trigger a manual failover during the outage, as it will not succeed. <p/> When the outage is over, you may move the write region back to the original region, and re-adjust provisioned RUs as appropriate. Accounts using SQL APIs may also recover the non-replicated data in the failed region from your [conflicts feed](how-to-manage-conflicts.md#read-from-conflict-feed). |
@@ -193,4 +193,4 @@ Next you can read the following articles:
 
 * [How to configure your Cosmos account with multiple write regions](how-to-multi-master.md)
 
-* [SDK behavior on multi-regional environments](troubleshoot-sdk-availability.md)
+* [SDK behavior on multi-regional environments](troubleshoot-sdk-availability.md)
diff --git a/articles/cosmos-db/how-to-manage-database-account.md b/articles/cosmos-db/how-to-manage-database-account.md
@@ -49,9 +49,9 @@ Open the **Replicate Data Globally** tab and select **Enable** to enable multi-r
 
 :::image type="content" source="./media/how-to-manage-database-account/single-to-multi-master.png" alt-text="Azure Cosmos account configures multi-region writes screenshot":::
 
-## <a id="automatic-failover"></a>Enable automatic failover for your Azure Cosmos account
+## <a id="automatic-failover"></a>Enable service-managed failover for your Azure Cosmos account
 
-The Automatic failover option allows Azure Cosmos DB to failover to the region with the highest failover priority with no user action should a region become unavailable. When automatic failover is enabled, region priority can be modified. Account must have two or more regions to enable automatic failover.
+The Service-Managed failover option allows Azure Cosmos DB to failover to the region with the highest failover priority with no user action should a region become unavailable. When service-managed failover is enabled, region priority can be modified. Account must have two or more regions to enable service-managed failover.
 
 1. From your Azure Cosmos account, open the **Replicate data globally** pane.
 
@@ -70,7 +70,7 @@ The Automatic failover option allows Azure Cosmos DB to failover to the region w
 After a Cosmos account is configured for automatic failover, the failover priority for regions can be changed.
 
 > [!IMPORTANT]
-> You cannot modify the write region (failover priority of zero) when the account is configured for automatic failover. To change the write region, you must disable automatic failover and do a manual failover.
+> You cannot modify the write region (failover priority of zero) when the account is configured for service-managed failover. To change the write region, you must disable service-managed failover and do a manual failover.
 
 1. From your Azure Cosmos account, open the **Replicate data globally** pane.
 
diff --git a/articles/cosmos-db/monitor-cosmos-db.md b/articles/cosmos-db/monitor-cosmos-db.md
@@ -174,7 +174,7 @@ For example, the following table lists few alert rules for your resources. You c
 | Alert type | Condition | Description  |
 |:---|:---|:---|
 |Rate limiting on request units (metric alert) |Dimension name: StatusCode, Operator: Equals, Dimension values: 429  | Alerts if the container or a database has exceeded the provisioned throughput limit. |
-|Region failed over |Operator: Greater than, Aggregation type: Count, Threshold value: 1 | When a single region is failed over. This alert is helpful if you didn't enable automatic failover. |
+|Region failed over |Operator: Greater than, Aggregation type: Count, Threshold value: 1 | When a single region is failed over. This alert is helpful if you didn't enable service-managed failover. |
 | Rotate keys(activity log alert)| Event level: Informational , Status: started| Alerts when the account keys are rotated. You can update your application with the new keys. |
 
 ## <a id="monitor-cosmosdb-programmatically"></a> Monitor Azure Cosmos DB programmatically
diff --git a/articles/cosmos-db/sql/manage-with-cli.md b/articles/cosmos-db/sql/manage-with-cli.md
@@ -31,7 +31,7 @@ The following sections demonstrate how to manage the Azure Cosmos account, inclu
 * [Add or remove regions](#add-or-remove-regions)
 * [Enable multi-region writes](#enable-multiple-write-regions)
 * [Set regional failover priority](#set-failover-priority)
-* [Enable automatic failover](#enable-automatic-failover)
+* [Enable service-managed failover](#enable-automatic-failover)
 * [Trigger manual failover](#trigger-manual-failover)
 * [List account keys](#list-account-keys)
 * [List read-only account keys](#list-read-only-account-keys)
@@ -106,7 +106,7 @@ az cosmosdb update --ids $accountId --enable-multiple-write-locations true
 
 ### Set failover priority
 
-Set the failover priority for an Azure Cosmos account configured for automatic failover
+Set the failover priority for an Azure Cosmos account configured for service-managed failover
 
 ```azurecli-interactive
 # Assume region order is initially 'West US'=0 'East US'=1 'South Central US'=2 for account
@@ -121,10 +121,10 @@ az cosmosdb failover-priority-change --ids $accountId \
     --failover-policies 'West US=0' 'South Central US=1' 'East US=2'
 ```
 
-### Enable automatic failover
+### Enable service-managed failover
 
 ```azurecli-interactive
-# Enable automatic failover on an existing account
+# Enable service-managed failover on an existing account
 resourceGroupName='myResourceGroup'
 accountName='mycosmosaccount'
 
@@ -548,4 +548,4 @@ For more information on the Azure CLI, see:
 
 * [Install Azure CLI](/cli/azure/install-azure-cli)
 * [Azure CLI Reference](/cli/azure/cosmosdb)
-* [Additional Azure CLI samples for Azure Cosmos DB](cli-samples.md)
+* [Additional Azure CLI samples for Azure Cosmos DB](cli-samples.md)
diff --git a/articles/cosmos-db/sql/manage-with-powershell.md b/articles/cosmos-db/sql/manage-with-powershell.md
@@ -48,7 +48,7 @@ The following sections demonstrate how to manage the Azure Cosmos account, inclu
 
 ### <a id="create-account"></a> Create an Azure Cosmos account
 
-This command creates an Azure Cosmos DB database account with [multiple regions][distribute-data-globally], [automatic failover](../how-to-manage-database-account.md#automatic-failover) and bounded-staleness [consistency policy](../consistency-levels.md).
+This command creates an Azure Cosmos DB database account with [multiple regions][distribute-data-globally], [service-managed failover](../how-to-manage-database-account.md#automatic-failover) and bounded-staleness [consistency policy](../consistency-levels.md).
 
 ```azurepowershell-interactive
 $resourceGroupName = "myResourceGroup"
@@ -177,7 +177,7 @@ $accountName = "mycosmosaccount"
 $enableAutomaticFailover = $false
 $enableMultiMaster = $true
 
-# First disable automatic failover - cannot have both automatic
+# First disable service-managed failover - cannot have both service-managed
 # failover and multi-region writes on an account
 Update-AzCosmosDBAccount `
     -ResourceGroupName $resourceGroupName `
@@ -266,7 +266,7 @@ New-AzCosmosDBAccountKey `
     -KeyKind $keyKind
 ```
 
-### <a id="enable-automatic-failover"></a> Enable automatic failover
+### <a id="enable-automatic-failover"></a> Enable service-managed failover
 
 The following command sets a Cosmos DB account to fail over automatically to its secondary region should the primary region become unavailable.
 
@@ -283,7 +283,7 @@ Update-AzCosmosDBAccount `
     -Name $accountName `
     -EnableMultipleWriteLocations:$enableMultiMaster
 
-# Now enable automatic failover
+# Now enable service-managed failover
 Update-AzCosmosDBAccount `
     -ResourceGroupName $resourceGroupName `
     -Name $accountName `
@@ -292,7 +292,7 @@ Update-AzCosmosDBAccount `
 
 ### <a id="modify-failover-priority"></a> Modify Failover Priority
 
-For accounts configured with Automatic Failover, you can change the order in which Cosmos will promote secondary replicas to primary should the primary become unavailable.
+For accounts configured with Service-Managed Failover, you can change the order in which Cosmos will promote secondary replicas to primary should the primary become unavailable.
 
 For the example below, assume the current failover priority is `West US = 0`, `East US = 1`, `South Central US = 2`. The command will change this to `West US = 0`, `South Central US = 1`, `East US = 2`.
 
