renaming failover groups

fixing issues

fixing things

fixing more things

fixing more things

acrolinx

fixing more things

Apply suggestions from code review

Co-authored-by: rajeshsetlem <25328917+rajeshsetlem@users.noreply.github.com>

Apply suggestions from code review

Co-authored-by: rajeshsetlem <25328917+rajeshsetlem@users.noreply.github.com>

moving programmatically manage to configure article

Update azure-sql/includes/failover-group-overview.md

Co-authored-by: rajeshsetlem <25328917+rajeshsetlem@users.noreply.github.com>

acrolinx

fixing alt text

Author: MashaMSFT

.openpublishing.redirection.azure-sql.json

@@ -155,6 +155,46 @@
       "redirect_url": "/azure/azure-sql/migration-guides/managed-instance/sql-server-to-managed-instance-guide",
       "redirect_document_id": false
     },
+    {
+      "source_path_from_root": "/azure-sql/database/auto-failover-group-configure-sql-db.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/auto-failover-group-sql-db.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-sql-db",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/failover-group-add-single-database-tutorial.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/database/failover-group-add-elastic-pool-tutorial.md",
+      "redirect_url": "/azure/azure-sql/database/failover-group-configure-sql-db",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/failover-group-add-instance-tutorial.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-configure-sql-mi",
+      "redirect_document_id": false
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-configure-sql-mi.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-configure-sql-mi",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-sql-mi.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-sql-mi",
+      "redirect_document_id": true
+    },
+    {
+      "source_path_from_root": "/azure-sql/managed-instance/auto-failover-group-standby-replica-how-to-configure.md",
+      "redirect_url": "/azure/azure-sql/managed-instance/failover-group-standby-replica-how-to-configure",
+      "redirect_document_id": true
+    },
     {
       "source_path_from_root": "/azure-sql/virtual-machines/linux/sql/sql-server-linux-faq.md",
       "redirect_url": "/azure/azure-sql/virtual-machines/linux/frequently-asked-questions-faq",

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 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).
+For failover groups, see [Failover groups with Azure SQL Database](failover-group-sql-db.md) and [Failover groups with Azure SQL Managed Instance](../managed-instance/failover-group-sql-mi.md).
 
 ## Prerequisites
 
@@ -299,6 +299,7 @@ Use Transact-SQL (T-SQL) create a geo-secondary in a subscription different from
 ## Next steps
 
 * To learn more about active geo-replication, see [active geo-replication](active-geo-replication-overview.md).
-* To learn about auto-failover groups, see [Auto-failover groups](auto-failover-group-sql-db.md)
+* To learn about failover groups, see [Failover groups](failover-group-sql-db.md)
 * For a business continuity overview and scenarios, see [Business continuity overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 * Save on licensing costs by designating your secondary DR replica for [standby](standby-replica-how-to-configure.md).
+1

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

@@ -16,13 +16,10 @@ 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 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.
+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](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). 
 
-> [!NOTE]
-> Azure SQL Managed Instance doesn't support active geo-replication, see [Auto-failover groups](../managed-instance/auto-failover-group-sql-mi.md) instead. 
-
 ## Overview
 
 Active geo-replication is designed as a business continuity solution. Active geo-replication lets you perform quick disaster recovery of individual databases if there's a regional disaster or a large scale outage. Once geo-replication is set up, you can initiate a geo-failover to a geo-secondary in a different Azure region. The geo-failover is initiated programmatically by the application or manually by the user.
@@ -75,15 +72,15 @@ To achieve full business continuity, adding database regional redundancy is only
 
 - **Failover (no data loss)**
 
-  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:
+  Failover switches the roles of primary and geo-secondary databases after completing full data synchronization so there's no data loss. Duration of the failover depends on the size of the 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; 
+  - 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).
 
 - **Forced failover (potential data loss)**
 
-  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.
+  Forced failover immediately switches the geo-secondary to the primary role without waiting for 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's automatically reconnected, reseeded using current data from the primary, and become the new geo-secondary.
 
   > [!IMPORTANT]
   > 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.
@@ -101,7 +98,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 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.
+  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, which 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 fails 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, perform a manual failover.
 
 - **Standby replica** 
 
@@ -112,7 +109,7 @@ To achieve full business continuity, adding database regional redundancy is only
 To ensure that your application can immediately access the new primary after geo-failover, validate that authentication and network access for your secondary server are properly configured. For details, see [SQL Database security after disaster recovery](active-geo-replication-security-configure.md). Also validate that backup retention policy on the secondary database matches that of the primary. This setting isn't a part of the database and isn't replicated from the primary. By default, the geo-secondary is configured with a default PITR retention period of seven days. For details, see [SQL Database automated backups](automated-backups-overview.md).
 
 > [!IMPORTANT]
-> If your database is a member of a failover group, you cannot initiate its failover using the geo-replication failover command. Use the failover command for the group. If you need to failover an individual database, you must remove it from the failover group first. See  [Auto-failover groups](auto-failover-group-sql-db.md) for details.
+> If your database is a member of a failover group, you cannot initiate its failover using the geo-replication failover command. Use the failover command for the group. If you need to failover an individual database, you must remove it from the failover group first. See  [Failover groups](failover-group-sql-db.md) for details.
 
 ## <a name="configuring-secondary-database"></a> Configure geo-secondary
 
@@ -228,7 +225,7 @@ As discussed previously, active geo-replication can also be managed programmatic
 - For sample scripts, see:
   - [Configure and failover a single database using active geo-replication](scripts/setup-geodr-and-failover-database-powershell.md).
   - [Configure and failover a pooled database using active geo-replication](scripts/setup-geodr-and-failover-elastic-pool-powershell.md).
-- SQL Database also supports auto-failover groups. For more information, see using [auto-failover groups](auto-failover-group-sql-db.md).
+- SQL Database also supports failover groups. For more information, see using [failover groups](failover-group-sql-db.md).
 - For a business continuity overview and scenarios, see [Business continuity overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 - Save on licensing costs by designating your secondary DR replica for [standby](standby-replica-how-to-configure.md).
 - To learn about Azure SQL Database Hyperscale Geo-replica see [Hyperscale Geo-replica](service-tier-hyperscale-replicas.md#geo-replica)

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

@@ -13,7 +13,7 @@ ms.custom: sqldbrb=1
 # Configure and manage Azure SQL Database security for geo-restore or failover
 [!INCLUDE[appliesto-sqldb](../includes/appliesto-sqldb.md)]
 
-This article describes the authentication requirements to configure and control [active geo-replication](active-geo-replication-overview.md) and [auto-failover groups](auto-failover-group-sql-db.md). It also provides the steps required to set up user access to the secondary database. Finally, it also describes how to enable access to the recovered database after using [geo-restore](recovery-using-backups.md#geo-restore). For more information on recovery options, see [Business Continuity Overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
+This article describes the authentication requirements to configure and control [active geo-replication](active-geo-replication-overview.md) and [failover groups](failover-group-sql-db.md). It also provides the steps required to set up user access to the secondary database. Finally, it also describes how to enable access to the recovered database after using [geo-restore](recovery-using-backups.md#geo-restore). For more information on recovery options, see [Business Continuity Overview](business-continuity-high-availability-disaster-recover-hadr-overview.md).
 
 ## Disaster recovery with contained users
 
@@ -100,5 +100,5 @@ SID = 0x1234 /*replace 0x1234 with the desired login SID*/
 * For more information on managing database access and logins, see [SQL Database security: Manage database access and login security](logins-create-manage.md).
 * For more information on contained database users, see [Contained Database Users - Making Your Database Portable](/sql/relational-databases/security/contained-database-users-making-your-database-portable).
 * To learn about active geo-replication, see [Active geo-replication](active-geo-replication-overview.md).
-* To learn about auto-failover groups, see [Auto-failover groups](auto-failover-group-sql-db.md).
+* To learn about failover groups, see [Failover groups](failover-group-sql-db.md).
 * For information about using geo-restore, see [geo-restore](recovery-using-backups.md#geo-restore)