Merge pull request #36488 from MashaMSFT/202601_fogfix

Update failover group documentation

Author: prmerger-automator[bot]

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

@@ -90,10 +90,7 @@ There is some overlap of content in the following articles, be sure to make chan
 
 - **Failover group read-only listener**
 
-  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. If you can't tolerate downtime for the read-only sessions and can use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the `AllowReadOnlyFailoverToPrimary` property. In that case, the read-only traffic is automatically redirected to the primary if the secondary isn't available.
-
-  > [!NOTE]
-  > The `AllowReadOnlyFailoverToPrimary` property only has effect if Microsoft managed failover policy is enabled and a forced failover has been triggered. In that case, if the property is set to True, the new primary will serve both read-write and read-only sessions.
+  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a server, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. 
 
 - **Multiple failover groups**
 

azure-sql/managed-instance/failover-group-configure-sql-mi.md

@@ -524,10 +524,12 @@ When using failover groups, consider the following limitations:
     - after failover, and can delay or prevent a subsequent failover.
 - Database rename isn't supported for databases in failover group. You'll need to temporarily delete the failover group to be able to rename a database.
 - System databases aren't replicated to the secondary instance in a failover group. Therefore, scenarios that depend on objects from the system databases such as Server Logins and Agent jobs, require objects to be manually created on the secondary instances and also manually kept in sync after any changes made on primary instance. The only exception is Service master Key (SMK) for SQL Managed Instance that is replicated automatically to secondary instance during creation of failover group. Any subsequent changes of SMK on the primary instance however won't be replicated to secondary instance. To learn more, see how to [Enable scenarios dependent on objects from the system databases](#enable-scenarios-dependent-on-objects-from-the-system-databases).
+- When new databases are added to a failover group, planned failover is unavailable until the new database has been seeded to the secondary replica and is synchronized. Forced failover is still available during this process.
 - For instances inside of a failover group, changing the service tier to, or from, the Next-gen General Purpose tier isn't supported. You must first delete the failover group before modifying either replica, and then re-create the failover group after the change takes effect.
 - SQL managed instances in a failover group must have the same [update policy](update-policy.md), though it's possible to [change the update policy](#change-update-policy) for instances within a failover group.
 
 
+
 ## <a id="programmatically-managing-failover-groups"></a> Programmatically manage failover groups
 
 Failover groups can also be managed programmatically using Azure PowerShell, Azure CLI, and REST API. The following tables describe the set of commands available. Failover groups include a set of Azure Resource Manager APIs for management, including the [Azure SQL Database REST API](/rest/api/sql/) and [Azure PowerShell cmdlets](/powershell/azure/). These APIs require the use of resource groups and support Azure role-based access control (Azure RBAC). For more information on how to implement access roles, see [Azure role-based access control (Azure RBAC)](/azure/role-based-access-control/overview).

azure-sql/managed-instance/failover-group-sql-mi.md

@@ -74,10 +74,7 @@ There's some overlap of content in the following articles, be sure to make chang
 
 - **Failover group read-only listener**
 
-  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a SQL managed instance, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.<zone_id>.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. If you can't tolerate downtime for the read-only sessions and can use the primary for both read-only and read-write traffic at the expense of the potential performance degradation of the primary, you can enable failover for the read-only listener by configuring the `AllowReadOnlyFailoverToPrimary` property. In that case, the read-only traffic is automatically redirected to the primary if the secondary isn't available.
-
-  > [!NOTE]  
-  > The `AllowReadOnlyFailoverToPrimary` property only has effect if Microsoft managed failover policy is enabled and a forced failover has been triggered. In that case, if the property is set to True, the new primary serves both read-write and read-only sessions.
+  A DNS CNAME record that points to the current secondary. It's created automatically when the failover group is created and allows the read-only SQL workload to transparently connect to the secondary when the secondary changes after failover. When the failover group is created on a SQL managed instance, the DNS CNAME record for the listener URL is formed as `<fog-name>.secondary.<zone_id>.database.windows.net`. By default, failover of the read-only listener is disabled as it ensures the performance of the primary isn't affected when the secondary is offline. However, it also means the read-only sessions won't be able to connect until the secondary is recovered. 
 
 ## Failover group architecture
 
@@ -267,13 +264,16 @@ Performing a drill using forced failover is **not recommended**, as this operati
 - The workload is stopped on the primary SQL managed instance.
 - All long running transactions have completed.
 - All client connections to the primary SQL managed instance have been disconnected.
-- [Failover group status](failover-group-sql-mi.md#failover-group-status) is 'Synchronizing'.
+- [Failover group status](failover-group-sql-mi.md#failover-group-status) is `Synchronizing` on **both** the primary and secondary instances.
 
 Please ensure the two SQL managed instances have switched roles. Also that the failover group status has switched from *'Failover in progress'* to *'Synchronizing'* before optionally establishing connections to the new primary SQL managed instance and starting read-write workload.
 
-To perform a data lossless failback to the original SQL managed instance roles, using manual planned failover instead of forced failover is **strongly recommended**. If forced failback is used:
+To perform a data lossless failback to the original SQL managed instance roles, using manual planned failover instead of forced failover is **strongly recommended**. 
+
+If forced failback is used:
 
 - Follow the same steps as for the data lossless failover.
+- Forced failback is expected to fail if a previous forced failover did not succeed on both SQL managed instances. Ensure failover group status is `Synchronizing` on **both** instances before executing the forced failback.
 - Longer failback execution time is expected if the forced failback is executed **shortly after** the initial forced failover is completed, as it has to wait for completion of outstanding automatic backup operations on the former primary SQL managed instance.
 - Any outstanding automatic backup operations on an instance transitioning from the primary to the secondary role can impact database availability on this instance.
 - Please use the failover group status to determine whether both instances have successfully changed their roles and are ready to accept client connections.