Light Freshness Edit: Azure SQL (Failover clustering)

Author: gitName

docs/database-engine/availability-groups/windows/failover-clustering-and-always-on-availability-groups-sql-server.md

@@ -1,22 +1,24 @@
 ---
-title: Business continuity and database recovery - SQL Server
+title: Business Continuity and Database Recovery - SQL Server
 description: Use this overview of business continuity solutions for high availability and disaster recovery in SQL Server to provide resources with minimal interruption.
 author: MashaMSFT
 ms.author: mathoma
 ms.reviewer: mikeray, randolphwest
-ms.date: 11/23/2022
+ms.date: 08/21/2025
+ms.update-cycle: 1825-days
 ms.service: sql
 ms.subservice: availability-groups
-ms.custom: linux-related-content
 ms.topic: conceptual
+ms.custom:
+  - linux-related-content
 ---
 # Business continuity and database recovery - SQL Server
 
-[!INCLUDE[sqlserver2016](../includes/applies-to-version/sqlserver2016.md)]
+[!INCLUDE [sqlserver2016](../includes/applies-to-version/sqlserver2016.md)]
 
-[!INCLUDE[business-continuity](../includes/business-continuity/business-continuity.md)]
+[!INCLUDE [business-continuity](../includes/business-continuity/business-continuity.md)]
 
-## Next steps
+## Related content
 
-- [Availability groups](availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md)
-- [Failover clusters](../sql-server/failover-clusters/install/sql-server-failover-cluster-installation.md)
+- [What is an Always On availability group?](availability-groups/windows/overview-of-always-on-availability-groups-sql-server.md)
+- [SQL Server failover cluster installation](../sql-server/failover-clusters/install/sql-server-failover-cluster-installation.md)

docs/database-engine/availability-groups/windows/prereqs-restrictions-recommendations-always-on-availability.md

@@ -50,7 +50,7 @@ With [!INCLUDE [ssnoversion-md](../ssnoversion-md.md)] now supported on both Win
 
 ## Distributed availability groups
 
-Distributed AGs are designed to span AG configurations, whether those two underlying clusters underneath the AGs are two different WSFCs, Linux distributions, or one on a WSFC and the other on Linux. A distributed AG will be the primary method of having a cross platform solution. A distributed AG is also the primary solution for migrations such as converting from a Windows Server-based [!INCLUDE [ssnoversion-md](../ssnoversion-md.md)] infrastructure to a Linux-based one if that is what your company wants to do. As noted above, AGs, and especially distributed AGs, would minimize the time that an application would be unavailable for use. An example of a distributed AG that spans a WSFC and Pacemaker is shown below.
+Distributed AGs are designed to span AG configurations, whether those two underlying clusters underneath the AGs are two different WSFCs, Linux distributions, or one on a WSFC and the other on Linux. A distributed AG will be the primary method of having a cross platform solution. A distributed AG is also the primary solution for migrations such as converting from a Windows Server-based [!INCLUDE [ssnoversion-md](../ssnoversion-md.md)] infrastructure to a Linux-based one if that is what your company wants to do. As noted above, AGs, and especially distributed AGs, would minimize the time that an application would be unavailable for use. An example of a distributed AG that spans a WSFC and Pacemaker is shown in the following diagram:
 
 :::image type="content" source="media/business-continuity/distributed-availability-group-span.png" alt-text="Diagram showing a distributed availability group that spans a WSFC and Pacemaker.":::
 

docs/database-engine/availability-groups/windows/upgrading-always-on-availability-group-replica-instances.md

@@ -20,7 +20,7 @@ Before [!INCLUDE[sssql22-md](../sssql22-md.md)], AGs only provide database-level
 
 Starting with [!INCLUDE[sssql22-md](../sssql22-md.md)], you can manage metadata objects including users, logins, permissions and [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] Agent jobs at the AG level in addition to the instance level. For more information, see [Contained availability groups](../../database-engine/availability-groups/windows/contained-availability-groups-overview.md).
 
-An AG also has another component called the *listener*, which allows applications and end users to connect without needing to know which [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] instance is hosting the primary replica. Each AG would have its own listener. While the implementations of the listener are slightly different on Windows Server versus Linux, the functionality it provides and how it's used is the same. The diagram below shows a Windows Server-based AG that is using a Windows Server Failover Cluster (WSFC). An underlying cluster at the OS layer is required for availability whether it is on Linux or Windows Server. The example shows a simple configuration with two servers, or *nodes*, with a WSFC as the underlying cluster.
+An AG also has another component called the *listener*, which allows applications and end users to connect without needing to know which [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] instance is hosting the primary replica. Each AG would have its own listener. While the implementations of the listener are slightly different on Windows Server versus Linux, the functionality it provides and how it's used is the same. The following diagram shows a Windows Server-based AG that is using a Windows Server Failover Cluster (WSFC). An underlying cluster at the OS layer is required for availability whether it is on Linux or Windows Server. The example shows a simple configuration with two servers, or *nodes*, with a WSFC as the underlying cluster.
 
 :::image type="content" source="media/business-continuity/simple-availability-group.png" alt-text="Diagram of a simple availability group.":::
 
@@ -31,7 +31,7 @@ Standard and Enterprise edition have different maximums when it comes to replica
 
 When it comes to availability, AGs can provide either automatic or manual failover. Automatic failover can occur if synchronous data movement is configured and the database on the primary and secondary replica are in a synchronized state. As long as the listener is used and the application uses a later version of .NET Framework (3.5 with an update, or 4.0 and above), the failover should be handled with minimal to no effect on end users if a listener is utilized. Failing over to a secondary replica to make it the new primary replica can be configured to be automatic or manual, and is generally measured in seconds.
 
-The list below highlights some differences with AGs on Windows Server versus Linux:
+The following list highlights some differences with AGs on Windows Server versus Linux:
 
 - Owing to differences in the way the underlying cluster works on Linux and Windows Server, all failovers (manual or automatic) of AGs are done via the cluster on Linux. On Windows Server-based AG deployments, manual failovers must be done via [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)]. Automatic failovers are handled by the underlying cluster on both Windows Server and Linux.
 - For [!INCLUDE [ssnoversion-md](../ssnoversion-md.md)] on Linux, the recommended configuration for AGs is a minimum of three replicas. This is due to the way that the underlying clustering works.
@@ -40,7 +40,7 @@ The list below highlights some differences with AGs on Windows Server versus Lin
 Starting with [!INCLUDE[sssql17-md](../sssql17-md.md)], there are some new features and enhancements to AGs:
 
 - Cluster types
-- REQUIRED_SECONDARIES_TO_COMMIT
+- `REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT`
 - Enhanced Microsoft Distributor Transaction Coordinator (DTC) support for Windows Server-based configurations
 - Additional scale out scenarios for read-only databases (described later in this article)
 
@@ -67,9 +67,9 @@ A cluster type of None can be used with both Windows Server and Linux AGs. Setti
 > [!IMPORTANT]  
 > Starting with [!INCLUDE[sssql17-md](../sssql17-md.md)], you can't change a cluster type for an AG after it is created. This means that an AG cannot be switched from None to External or WSFC, or vice versa.
 
-For those who are only looking to just add additional read-only copies of a database, or like what an AG provides for migration/upgrades but don't want to be tied to the additional complexity of an underlying cluster or even the replication, an AG with a cluster type of None is a perfect solution. For more information, see the sections [Migrations and Upgrades](#Migrations) and [read-scale](#ReadScaleOut).
+For those who are only looking to just add additional read-only copies of a database, or like what an AG provides for migration/upgrades but don't want to be tied to the additional complexity of an underlying cluster or even the replication, an AG with a cluster type of None is a perfect solution. For more information, see the sections [Migrations and upgrades](#Migrations) and [read-scale](#ReadScaleOut).
 
-The screenshot below shows the support for the different kinds of cluster types in SQL Server Management Studio (SSMS). You must be running version 17.1 or later. The screenshot below is from version 17.2.
+The following screenshot shows the support for the different kinds of cluster types in SQL Server Management Studio (SSMS). You must be running version 17.1 or later. The following screenshot follow is from version 17.2: 
 
 :::image type="content" source="media/business-continuity/availability-group-options.png" alt-text="Screenshot of SSMS AG options." lightbox="media/business-continuity/availability-group-options.png":::
 
@@ -100,19 +100,19 @@ In [!INCLUDE[sssql17-md](../sssql17-md.md)] and later versions, DTC support can
 
 ### Failover cluster instances
 
-Clustered installations have been a feature of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] since version 6.5. FCIs are a proven method of providing availability for the entire installation of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)], known as an instance. This means that everything inside the instance, including databases, [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] Agent jobs, linked servers, and so on, will move to another server should the underlying server encounter a problem. All FCIs require some sort of shared storage, even if it's provided via networking. The FCI's resources can only be running and owned by one node at any given time. In the diagram below, the first node of the cluster owns the FCI, which also means it owns the shared storage resources associated with it denoted by the solid line to the storage.
+Clustered installations have been a feature of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] since version 6.5. FCIs are a proven method of providing availability for the entire installation of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)], known as an instance. This means that everything inside the instance, including databases, [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] Agent jobs, linked servers, and so on, will move to another server should the underlying server encounter a problem. All FCIs require some sort of shared storage, even if it's provided via networking. The FCI's resources can only be running and owned by one node at any given time. In the following diagram, the first node of the cluster owns the FCI, which also means it owns the shared storage resources associated with it denoted by the solid line to the storage.
 
-:::image type="content" source="media/business-continuity/failover-cluster-instance.png" alt-text="Diagram of a Failover Cluster Instance.":::
+:::image type="content" source="media/business-continuity/failover-cluster-instance.png" alt-text="Diagram of a failover cluster instance.":::
 
-After a failover, ownership changes as is seen in the diagram below.
+After a failover, ownership changes as is seen in the following diagram: 
 
-:::image type="content" source="media/business-continuity/failover-cluster-instance-post-failover.png" alt-text="Diagram of a Failover Cluster Instance, post failover.":::
+:::image type="content" source="media/business-continuity/failover-cluster-instance-post-failover.png" alt-text="Diagram of a failover cluster instance, post failover.":::
 
 There's zero data loss with an FCI, but the underlying shared storage is a single point of failure since there's one copy of the data. FCIs are often combined with another availability method, such as an AG or log shipping, to have redundant copies of databases. The additional method deployed should use physically separate storage from the FCI. When the FCI fails over to another node, it stops on one node and starts on another, not unlike powering off a server and turning it on. An FCI goes through the normal recovery process, meaning any transactions that need to be rolled forward will be, and any transactions that are incomplete will be rolled back. Therefore, the database is consistent from a data point to the time of the failure or manual failover, hence no data loss. Databases are only available after recovery is complete, so recovery time will depend on many factors, and will generally be longer than failing over an AG. The tradeoff is that when you fail over an AG, there may be extra tasks required to make a database usable, such as enabling a [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] Agent job.
 
 Like an AG, FCIs abstract which node of the underlying cluster is hosting it. An FCI always retains the same name. Applications and end users never connect to the nodes; the unique name assigned to the FCI is used. An FCI can participate in an AG as one of the instances hosting either a primary or secondary replica.
 
-The list below highlights some differences with FCIs on Windows Server versus Linux:
+The following list highlights some differences with FCIs on Windows Server versus Linux:
 
 - On Windows Server, an FCI is part of the installation process. An FCI on Linux is configured after installing [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)].
 - Linux only supports a single installation of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] per host, so all FCIs will be a default instance. Windows Server supports up to 25 FCIs per WSFC.
@@ -124,7 +124,7 @@ If recovery point and recovery time objectives are more flexible, or databases a
 
 :::image type="content" source="media/business-continuity/log-shipping.png" alt-text="Diagram of Log Shipping.":::
 
-Arguably the biggest advantage of using log shipping in some capacity is that it accounts for human error. The application of transaction logs can be delayed. Therefore, if someone issues something like an UPDATE without a WHERE clause, the standby may not have the change so you could switch to that while you repair the primary system. While log shipping is easy to configure, switching from the primary to a warm standby, known as a role change, is always manual. A role change is initiated via Transact-SQL, and like an AG, all objects not captured in the transaction log must be manually synchronized. Log shipping also needs to be configured per database, whereas a single AG can contain multiple databases.  
+Arguably the biggest advantage of using log shipping in some capacity is that it accounts for human error. The application of transaction logs can be delayed. Therefore, if someone issues something like an `UPDATE` without a `WHERE` clause, the standby may not have the change so you could switch to that while you repair the primary system. While log shipping is easy to configure, switching from the primary to a warm standby, known as a role change, is always manual. A role change is initiated via Transact-SQL, and like an AG, all objects not captured in the transaction log must be manually synchronized. Log shipping also needs to be configured per database, whereas a single AG can contain multiple databases.  
 
 Unlike an AG or FCI, log shipping has no abstraction for a role change, which applications must be able to handle. Techniques such as a DNS alias (CNAME) could be employed, but there are pros and cons, such as the time it takes for DNS to refresh after the switch.
 
@@ -134,7 +134,7 @@ When your primary availability location experiences a catastrophic event like an
 
 ### Availability groups
 
-One of the benefits of AGs is that both high availability and disaster recovery can be configured using a single feature. Without the requirement for ensuring that shared storage is also highly available, it's much easier to have replicas that are local in one data center for high availability, and remote ones in other data centers for disaster recovery each with separate storage. Having extra copies of the database is the tradeoff for ensuring redundancy. An example of an AG that spans multiple data centers is shown below. One primary replica is responsible for keeping all secondary replicas synchronized.
+One of the benefits of AGs is that both high availability and disaster recovery can be configured using a single feature. Without the requirement for ensuring that shared storage is also highly available, it's much easier to have replicas that are local in one data center for high availability, and remote ones in other data centers for disaster recovery each with separate storage. Having extra copies of the database is the tradeoff for ensuring redundancy. An example of an AG that spans multiple data centers is shown in the following diagram. One primary replica is responsible for keeping all secondary replicas synchronized.
 
 :::image type="content" source="media/business-continuity/availability-group-span.png" alt-text="Diagram of an availability group spanning data centers.":::
 

docs/database-engine/sql-server-business-continuity-dr.md

@@ -33,7 +33,7 @@ AGs can provide minimal downtime during patching of the underlying OS by manuall
 ### Failover cluster instances
 
 FCIs on their own can't assist with a traditional migration or upgrade; an AG or log shipping would have to be configured for the databases in the FCI and all other objects accounted for. However, FCIs under Windows Server are still a popular option for when the underlying Windows Servers need to be patched. A manual failover can be initiated, which means a brief outage instead of having the instance unavailable for the entire time that Windows Server is being patched.
-An FCI can be upgraded in place to later versions of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)]. For information, see [Upgrade a SQL Server Failover Cluster Instance](../../sql-server/failover-clusters/windows/upgrade-a-sql-server-failover-cluster-instance.md).
+An FCI can be upgraded in place to later versions of [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)]. For information, see [Upgrade a SQL Server failover cluster instance](../../sql-server/failover-clusters/windows/upgrade-a-sql-server-failover-cluster-instance.md).
 
 ### Log shipping
 
@@ -78,6 +78,6 @@ Starting with [!INCLUDE[sssql17-md](../sssql17-md.md)], It's possible to create
 
 The only major caveat is that due to no underlying cluster with a cluster type of None, configuring read-only routing is a little different. From a [!INCLUDE[ssnoversion-md](../ssnoversion-md.md)] perspective, a listener is still required to route the requests even though there's no cluster. Instead of configuring a traditional listener, the IP address or name of the primary replica is used. The primary replica is then used to route the read-only requests.
 
-A log shipping warm standby can technically be configured for readable usage by restoring the database WITH STANDBY. However, because the transaction logs require exclusive use of the database for restoration, it means that users can't be accessing the database while that happens. This makes log shipping a less than ideal solution - especially if near real-time data is required.
+A log shipping warm standby can technically be configured for readable usage by restoring the database `WITH STANDBY`. However, because the transaction logs require exclusive use of the database for restoration, it means that users can't be accessing the database while that happens. This makes log shipping a less than ideal solution - especially if near real-time data is required.
 
 One thing that should be noted for all read-scale scenarios with AGs is that unlike using transactional replication where all of the data is live, each secondary replica isn't in a state where unique indexes can be applied, the replica is an exact copy of the primary. If any indexes are required for reporting or data needs to be manipulated, they must be created on the database(s) on the primary replica. If you need that flexibility, replication is a better solution for readable data.