HADR doc updates

Edits

Apply suggestions from code review

committing mladen's suggestions

Co-authored-by: Mladen Andzic (Msft) <mlandzic@microsoft.com>

Edits & fix build warnings

Fix build warnings

Edits based on review

Author: rajeshsetlem

azure-sql/database/active-geo-replication-configure-portal.md

@@ -16,7 +16,7 @@ ms.custom: sqldbrb=1, devx-track-azurecli, ignite-2023, devx-track-azurepowershe
 
 This article shows you how to configure [active geo-replication for Azure SQL Database](active-geo-replication-overview.md#active-geo-replication-terminology-and-capabilities) using the [Azure portal](https://portal.azure.com) or Azure CLI and to initiate failover.
 
-For best practices using auto-failover groups, see [Auto-failover groups with Azure SQL Database](auto-failover-group-sql-db.md) and [Auto-failover groups with Azure SQL Managed Instance](../managed-instance/auto-failover-group-sql-mi.md).
+For best practices using failover groups, see [Failover groups with Azure SQL Database](auto-failover-group-sql-db.md) and [Failover groups with Azure SQL Managed Instance](../managed-instance/auto-failover-group-sql-mi.md).
 
 ## Prerequisites
 
@@ -185,9 +185,6 @@ The command immediately switches the secondary database into the primary role. T
 
 There's a short period during which both databases are unavailable, on the order of 0 to 25 seconds, while the roles are switched. If the primary database has multiple secondary databases, the command automatically reconfigures the other secondaries to connect to the new primary. The entire operation should take less than a minute to complete under normal circumstances.
 
-> [!NOTE]
-> This command is designed for quick recovery of the database in case of an outage. It triggers failover without data synchronization, or forced failover.  If the primary is online and committing transactions when the command is issued some data loss may occur.
-
 ## Remove secondary database
 
 This operation permanently stops the replication to the secondary database, and changes the role of the secondary to a regular read-write database. If the connectivity to the secondary database is broken, the command succeeds but the secondary doesn't become read-write until after connectivity is restored.

azure-sql/database/active-geo-replication-overview.md

@@ -16,7 +16,7 @@ ms.custom: sqldbrb=1, ignite-2023
 
 Active geo-replication is a feature that lets you create a continuously synchronized readable secondary database for a primary database. The readable secondary database might be in the same Azure region as the primary, or, more commonly, in a different region. This kind of readable secondary database is also known as a geo-secondary or geo-replica. 
 
-Active geo-replication is configured per database, and only supports manual failover. To automatically fail over a group of databases, or if your application requires a stable connection endpoint, consider [Auto-failover groups](auto-failover-group-sql-db.md) instead. [Compare geo-replication with failover groups](business-continuity-high-availability-disaster-recover-hadr-overview.md#compare-geo-replication-with-failover-groups) to learn more. 
+Active geo-replication is configured per database, and only supports manual failover. To fail over a group of databases, or if your application requires a stable connection endpoint, consider [Failover groups](auto-failover-group-sql-db.md) instead.
 
 You can also use [Migrate SQL Database with active geo-replication](/azure/germany/germany-migration-databases#migrate-sql-database-using-active-geo-replication). 
 
@@ -73,20 +73,20 @@ To achieve full business continuity, adding database regional redundancy is only
    > You can use geo-replication to create secondary replicas in the same region as the primary. You can use these secondaries to satisfy read scale-out scenarios in the same region. However, a secondary replica in the same region does not provide additional resilience to catastrophic failures or large scale outages, and therefore is not a suitable failover target for disaster recovery purposes. It also does not guarantee availability zone isolation. Use Business Critical or Premium service tiers [zone redundant configuration](high-availability-sla.md#zone-redundant-availability) or General Purpose service tier [zone redundant configuration](high-availability-sla.md#zone-redundant-availability) to achieve availability zone isolation.
    >
 
-- **Planned geo-failover**
+- **Failover (no data loss)**
 
-  Planned geo-failover switches the roles of primary and geo-secondary databases after completing full data synchronization. A planned failover doesn't result in data loss. The duration of planned geo-failover depends on the size of transaction log on the primary that needs to be synchronized to the geo-secondary. Planned geo-failover is designed for the following scenarios:
+  Failover switches the roles of primary and geo-secondary databases after completing full data synchronization. A failover doesn't result in data loss. The duration of failover depends on the size of transaction log on the primary that needs to be synchronized to the geo-secondary. Failover is designed for the following scenarios:
 
   - Perform DR drills in production when the data loss isn't acceptable; 
   - Relocate the database to a different region; 
   - Return the database to the primary region after the outage has been mitigated (known as failback).
 
-- **Unplanned geo-failover**
+- **Forced failover (potential data loss)**
 
-  Unplanned, or forced, geo-failover immediately switches the geo-secondary to the primary role without any synchronization with the primary. Any transactions committed on the primary but not yet replicated to the secondary are lost. This operation is designed as a recovery method during outages when the primary isn't accessible, but database availability must be quickly restored. When the original primary is back online, it is automatically reconnected, reseeded using the current primary data, and become a new geo-secondary.
+  Forced failover immediately switches the geo-secondary to the primary role without any synchronization with the primary. Any transactions committed on the primary but not yet replicated to the secondary are lost. This operation is designed as a recovery method during outages when the primary isn't accessible, but database availability must be quickly restored. When the original primary is back online, it is automatically reconnected, reseeded using the current primary data, and become a new geo-secondary.
 
   > [!IMPORTANT]
-  > After either planned or unplanned geo-failover, the connection endpoint for the new primary changes because the new primary is now located on a different logical server.
+  > After either failover or forced failover, the connection endpoint for the new primary changes because the new primary is now located on a different logical server.
 
 - **Multiple readable geo-secondaries**
 
@@ -101,7 +101,7 @@ To achieve full business continuity, adding database regional redundancy is only
 
 - **User-controlled geo-failover and failback**
 
-  A geo-secondary that has finished initial seeding can be explicitly switched to the primary role (failed over) at any time by the application or the user. During an outage where the primary is inaccessible, only an unplanned geo-failover can be used. That immediately promotes a geo-secondary to be the new primary. When the outage is mitigated, the system automatically makes the recovered primary a geo-secondary, and brings it up-to-date with the new primary. Due to the asynchronous nature of geo-replication, recent transactions might be lost during unplanned geo-failovers if the primary fails before these transactions are replicated to a geo-secondary. When a primary with multiple geo-secondaries fail over, the system automatically reconfigures replication relationships and links the remaining geo-secondaries to the newly promoted primary, without requiring any user intervention. After the outage that caused the geo-failover is mitigated, it might be desirable to return the primary to its original region. To do that, invoke a planned geo-failover.
+  A geo-secondary that has finished initial seeding can be explicitly switched to the primary role (failed over) at any time by the application or the user. During an outage where the primary is inaccessible, only forced failover can be used. That immediately promotes a geo-secondary to be the new primary. When the outage is mitigated, the system automatically makes the recovered primary a geo-secondary, and brings it up-to-date with the new primary. Due to the asynchronous nature of geo-replication, recent transactions might be lost during forced failovers if the primary fails before these transactions are replicated to a geo-secondary. When a primary with multiple geo-secondaries fail over, the system automatically reconfigures replication relationships and links the remaining geo-secondaries to the newly promoted primary, without requiring any user intervention. After the outage that caused the geo-failover is mitigated, it might be desirable to return the primary to its original region. To do that, invoke a failover.
 
 - **Standby replica** 
 

azure-sql/database/auto-failover-group-configure-sql-db.md

@@ -12,17 +12,17 @@ ms.topic: how-to
 ms.custom: azure-sql-split, devx-track-azurepowershell
 zone_pivot_groups: azure-sql-deployment-option-single-elastic
 ---
-# Configure an auto-failover group for Azure SQL Database
+# Configure a failover group for Azure SQL Database
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
 > [!div class="op_single_selector"]
 > * [Azure SQL Database](auto-failover-group-configure-sql-db.md?view=azuresql-db&preserve-view=true)
 > * [Azure SQL Managed Instance](../managed-instance/auto-failover-group-configure-sql-mi.md?view=azuresql-mi&preserve-view=true)
 
-This topic teaches you how to configure an [auto-failover group](auto-failover-group-sql-db.md) for single and pooled databases in Azure SQL Database by using the Azure portal and Azure PowerShell.  For an end-to-end experience, review the [Auto-failover group tutorial](failover-group-add-single-database-tutorial.md). 
+This topic teaches you how to configure an [failover group](auto-failover-group-sql-db.md) for single and pooled databases in Azure SQL Database by using the Azure portal and Azure PowerShell.  For an end-to-end experience, review the [failover group tutorial](failover-group-add-single-database-tutorial.md). 
 
 > [!NOTE]
-> This article covers auto-failover groups for Azure SQL Database. For Azure SQL Managed Instance, see [Configure auto-failover groups in Azure SQL Managed Instance](../managed-instance/auto-failover-group-configure-sql-mi.md). 
+> This article covers failover groups for Azure SQL Database. For Azure SQL Managed Instance, see [Configure failover groups in Azure SQL Managed Instance](../managed-instance/auto-failover-group-configure-sql-mi.md). 
 
 
 ::: zone pivot="azure-sql-single-db"
@@ -90,8 +90,7 @@ Create your failover group and add your database to it using PowerShell.
       -ServerName $serverName `
       -PartnerServerName $drServerName  `
       FailoverGroupName $failoverGroupName `
-      FailoverPolicy Automatic `
-      -GracePeriodWithDataLossHours 2
+      FailoverPolicy Manual       
    $failovergroup
 
    # Add the database to the failover group
@@ -108,11 +107,11 @@ Create your failover group and add your database to it using PowerShell.
    ```
 
 > [!NOTE]
-> It's possible to deploy your auto-failover group across subscriptions by using the `-PartnerSubscriptionId` parameter in Azure Powershell starting with [Az.SQL 3.11.0](https://www.powershellgallery.com/packages/Az.Sql/3.11.0). To learn more, review the following [Example](/powershell/module/az.sql/new-azsqldatabasefailovergroup#example-3). 
+> It's possible to deploy your failover group across subscriptions by using the `-PartnerSubscriptionId` parameter in Azure Powershell starting with [Az.SQL 3.11.0](https://www.powershellgallery.com/packages/Az.Sql/3.11.0). To learn more, review the following [Example](/powershell/module/az.sql/new-azsqldatabasefailovergroup#example-3). 
 
 ---
 
-## Test failover
+## Test failover (no data loss)
 
 Test failover of your failover group using the Azure portal or PowerShell.
 
@@ -258,8 +257,7 @@ Create your failover group and add your elastic pool to it using PowerShell.
        -ServerName $serverName `
        -PartnerServerName $drServerName  `
        FailoverGroupName $failoverGroupName `
-       FailoverPolicy Automatic `
-       -GracePeriodWithDataLossHours 2
+       FailoverPolicy Manual      
    Write-host "Failover group created successfully."
 
    # Add elastic pool to the failover group
@@ -280,7 +278,7 @@ Create your failover group and add your elastic pool to it using PowerShell.
 
 ---
 
-## Test failover
+## Test failover (no data loss)
 
 Test failover of your elastic pool using the Azure portal or PowerShell.
 
@@ -423,7 +421,7 @@ The following table lists specific permission scopes for Azure SQL Database:
 ## Remarks
 
 - Removing a failover group for a single or pooled database does not stop replication, and it does not delete the replicated database. You will need to manually stop geo-replication and delete the database from the secondary server if you want to add a single or pooled database back to a failover group after it's been removed. Failing to do either may result in an error similar to `The operation cannot be performed due to multiple errors` when attempting to add the database to the failover group.
-- Auto-failover group name is subject to [naming restrictions](/azure/azure-resource-manager/management/resource-name-rules).
+- Failover group name is subject to [naming restrictions](/azure/azure-resource-manager/management/resource-name-rules).
 
 ## Next steps
 
@@ -433,4 +431,4 @@ For detailed steps configuring a failover group, see the following tutorials:
 - [Add an elastic pool to a failover group](failover-group-add-elastic-pool-tutorial.md)
 - [Add a managed instance to a failover group](../managed-instance/failover-group-add-instance-tutorial.md)
 
-For an overview of Azure SQL Database high availability options, see [geo-replication](active-geo-replication-overview.md) and [auto-failover groups](auto-failover-group-sql-db.md).
+For an overview of Azure SQL Database high availability options, see [geo-replication](active-geo-replication-overview.md) and [failover groups](auto-failover-group-sql-db.md).