Merge pull request #36485 from MashaMSFT/202601_linkfix

Update managed instance link documentation

Author: JamesJBarnett

azure-sql/managed-instance/managed-instance-link-best-practices.md

@@ -5,7 +5,7 @@ description: Learn about best practices when using the link feature for Azure SQ
 author: djordje-jeremic
 ms.author: djjeremi
 ms.reviewer: mathoma, danil
-ms.date: 09/30/2025
+ms.date: 01/28/2026
 ms.service: azure-sql-managed-instance
 ms.subservice: data-movement
 ms.custom: ignite-2023
@@ -14,13 +14,13 @@ ms.topic: how-to
 # Managed Instance link best practices - Azure SQL Managed Instance
 [!INCLUDE[appliesto-sqlmi](../includes/appliesto-sqlmi.md)]
 
-This article outlines best practices when using the [Managed Instance link](managed-instance-link-feature-overview.md) to replicate data between [Azure SQL Managed Instance](sql-managed-instance-paas-overview.md) and your SQL Server instances hosted anywhere, providing near real-time data replication between the linked replicas.
+This article outlines best practices for using the [Managed Instance link](managed-instance-link-feature-overview.md) to replicate data between [Azure SQL Managed Instance](sql-managed-instance-paas-overview.md) and your SQL Server instances hosted anywhere. The link provides near real-time data replication between the linked replicas.
 
 ## Take log backups regularly
 
-If SQL Server is your initial primary, it's important to take the first log backup on SQL Server *after* initial seeding completes, when the database is no longer in the *Restoring...* state on Azure SQL Managed Instance. Then take **SQL Server transaction log backups regularly** to maintain a healthy transaction log file size while SQL Server is in the primary role. 
+If SQL Server is your initial primary, take the first log backup on SQL Server *after* initial seeding finishes, when the database is no longer in the *Restoring...* state on Azure SQL Managed Instance. Then take **SQL Server transaction log backups regularly** to keep the transaction log file size healthy while SQL Server is in the primary role. 
 
-The link feature replicates data using the [distributed availability groups](/sql/database-engine/availability-groups/windows/distributed-availability-groups) technology based on Always On availability groups. Data replication with distributed availability groups is based on replicating transaction log records. No transaction log records can be truncated from the database on the primary SQL Server instance until they're replicated to the database on the secondary replica. If transaction log record replication is slow or blocked due to network connection issues, the log file keeps growing on the primary instance. Growth speed depends on the intensity of workload and the network speed. If there's a prolonged network connection outage and heavy workload on primary instance, the log file can take all available storage space.
+The link feature replicates data by using the [distributed availability groups](/sql/database-engine/availability-groups/windows/distributed-availability-groups) technology based on Always On availability groups. Distributed availability group data replication is based on replicating transaction log records. The primary SQL Server instance can't truncate any transaction log records from the database until they're replicated to the database on the secondary replica. If network connection issues cause transaction log record replication to be slow or blocked, the log file keeps growing on the primary instance. The intensity of workload and the network speed determine the growth speed. If a network connection outage is prolonged and the workload on primary instance is heavy, the log file can take all available storage space.
 
 Taking regular transaction log backups truncates the transaction log and minimizes the risk of running out of space on the primary SQL Server instance due to log file growth. No extra action is necessary when SQL Managed Instance is the primary since [log backups are already taken automatically](automated-backups-overview.md). By taking log backups regularly on your SQL Server primary, you make your database more resilient to unplanned log growth events. Consider scheduling daily log backup tasks by using a SQL Server Agent job.
 
@@ -48,17 +48,17 @@ The query output looks like the following example for sample database `tpcc`:
 
 :::image type="content" source="./media/managed-instance-link-best-practices/database-log-file-size.png" alt-text="Screenshot with results of the command showing log file size and space used":::
 
-In this example, the database has used 76% of the available log, with an absolute log file size of approximately 27 GB (27,971 MB). The thresholds for action vary based on your workload. In the previous example, the transaction log size and the percentage of use of the log is typically an indication that you should take a transaction log backup to truncate the log file and free up some space, or, you should take more frequent log backups. It could also be an indication that the transaction log truncation is being blocked by open transactions. For more on troubleshooting a transaction log in SQL Server, see [Troubleshoot a Full Transaction Log (SQL Server Error 9002)](/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002). For more on troubleshooting a transaction log in Azure SQL Managed Instance, see [Troubleshoot transaction log errors with Azure SQL Managed Instance](../managed-instance/troubleshoot-transaction-log-errors-issues.md?view=azuresql-mi&preserve-view=true).
+In this example, the database has used 76% of the available log, with an absolute log file size of approximately 27 GB (27,971 MB). The thresholds for action vary based on your workload. In the previous example, the transaction log size and the percentage of use of the log typically indicates that you should take a transaction log backup to truncate the log file and free up some space, or, you should take more frequent log backups. It could also be an indication that the transaction log truncation is being blocked by open transactions. For more on troubleshooting a transaction log in SQL Server, see [Troubleshoot a Full Transaction Log (SQL Server Error 9002)](/sql/relational-databases/logs/troubleshoot-a-full-transaction-log-sql-server-error-9002). For more on troubleshooting a transaction log in Azure SQL Managed Instance, see [Troubleshoot transaction log errors with Azure SQL Managed Instance](../managed-instance/troubleshoot-transaction-log-errors-issues.md?view=azuresql-mi&preserve-view=true).
 
 
 > [!NOTE]
-> When participating in a link, automated full and transaction log backups are taken from SQL Managed Instance whether or not it's the primary replica. Differential backups aren't taken, which can lead to longer restore times. 
+> When participating in a link, SQL Managed Instance takes automated full and transaction log backups whether or not it's the primary replica. Differential backups aren't taken, which can lead to longer restore times. 
 
 ## Match performance capacity between replicas
 
-When you're using the link feature, it's important to match performance capacity between SQL Server and SQL Managed Instance to avoid performance issues if the secondary replica can't keep up with replication from the primary replica, or after failover. Performance capacity includes CPU cores (or vCores in Azure), memory, and I/O throughput. 
+When you use the link feature, match the performance capacity between SQL Server and SQL Managed Instance. This matching helps you avoid performance problems if the secondary replica can't keep up with replication from the primary replica, or after failover. Performance capacity includes CPU cores (or vCores in Azure), memory, and I/O throughput.  
 
-You can check the performance of replication with the redo queue size on the secondary replica. The redo queue size indicates the number of log records that are waiting to be redone on the secondary replica. A consistently high redo queue size indicates that the secondary replica can't keep up with the primary replica. You can check the redo queue size in the following ways:
+You can monitor the performance of replication by checking the redo queue size on the secondary replica. The redo queue size shows the number of log records that are waiting to be redone on the secondary replica. A consistently high redo queue size shows that the secondary replica can't keep up with the primary replica. You can check the redo queue size in the following ways:
 
 - The `redo_queue_size` value in the [sys.dm_hadr_database_replica_states](/sql/relational-databases/system-dynamic-management-views/sys-dm-hadr-database-replica-states-transact-sql) dynamic management view on the primary replica. 
 - The `InstanceRedoLagReplicationSeconds` value in [Get-AzSqlInstanceLink](/powershell/module/az.sql/get-azsqlinstancelink) on the primary replica. 
@@ -67,11 +67,11 @@ If the redo queue size is consistently high, consider increasing resources on th
 
 ## Rotate certificate
 
-You might need to manually rotate the certificate used to secure the database mirroring endpoint on SQL Server. Since the certificate used to secure the database mirroring endpoint on SQL Managed Instance is managed by the service and rotated automatically, you don't need to manually rotate it yourself. 
+You might need to manually rotate the certificate used to secure the database mirroring endpoint on SQL Server. Since the service manages and automatically rotates the certificate used to secure the database mirroring endpoint on SQL Managed Instance, you don't need to manually rotate it. 
 
 ### SQL Server
 
-It's possible for the certificate that you use to secure the database mirroring endpoint on SQL Server to expire, which can lead to the degradation of the link. To prevent this issue, *rotate the certificate* before it expires.
+The certificate that you use to secure the database mirroring endpoint on SQL Server can expire. If the certificate expires, it can lead link degradation. To prevent this problem, *rotate the certificate* before it expires.
 
 Use the following Transact-SQL (T-SQL) command to check the expiration date of the current certificate: 
 
@@ -82,22 +82,22 @@ GO
 SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK' 
 ```
 
-If your certificate is about to expire, or has already expired, you can [create a new certificate](managed-instance-link-configure-how-to-scripts.md#create-a-certificate-on-sql-server-and-import-its-public-key-to-sql-managed-instance), and then alter the existing endpoint to [replace the current certificate](managed-instance-link-configure-how-to-scripts.md#alter-an-existing-endpoint). 
+If your certificate is about to expire, or has already expired, [create a new certificate](managed-instance-link-configure-how-to-scripts.md#create-a-certificate-on-sql-server-and-import-its-public-key-to-sql-managed-instance), and then alter the existing endpoint to [replace the current certificate](managed-instance-link-configure-how-to-scripts.md#alter-an-existing-endpoint). 
 
-Once the endpoint is configured to use the new certificate, you can [drop](/sql/t-sql/statements/drop-certificate-transact-sql) the expired certificate.
+After you configure the endpoint to use the new certificate, you can [drop](/sql/t-sql/statements/drop-certificate-transact-sql) the expired certificate.
 
 ### SQL Managed Instance
 
-The database mirroring endpoint certificate on SQL Managed Instance is automatically rotated periodically. Monitoring the expiration date for the database mirroring endpoint certificate on SQL Managed Instance is not necessary, as long as you can [validate the certificate chain on SQL Server](managed-instance-link-best-practices.md#validate-the-certificate-chain-on-sql-server) successfully.
+The database mirroring endpoint certificate on SQL Managed Instance is automatically rotated periodically. You don't need to monitor the expiration date for the database mirroring endpoint certificate on SQL Managed Instance, as long as you can [validate the certificate chain on SQL Server](managed-instance-link-best-practices.md#validate-the-certificate-chain-on-sql-server) successfully.
 
 ## Validate the certificate chain on SQL Server
 
 > [!NOTE]
-> The certificate chain should be periodically validated for existing links, or to troubleshoot issues with a degraded link. Skip this section if you're configuring a new link or have recently completed the steps in sections [Get the certificate public key from SQL Managed Instance and import it to SQL Server](managed-instance-link-configure-how-to-scripts.md#get-the-certificate-public-key-from-sql-managed-instance-and-import-it-to-sql-server) and [Import Azure-trusted root certificate authority keys to SQL Server](managed-instance-link-configure-how-to-scripts.md#import-azure-trusted-root-certificate-authority-keys-to-sql-server).
+> Periodically validate the certificate chain for existing links or to troubleshoot problems with a degraded link. If you're configuring a new link or recently completed the steps in sections [Get the certificate public key from SQL Managed Instance and import it to SQL Server](managed-instance-link-configure-how-to-scripts.md#get-the-certificate-public-key-from-sql-managed-instance-and-import-it-to-sql-server) and [Import Azure-trusted root certificate authority keys to SQL Server](managed-instance-link-configure-how-to-scripts.md#import-azure-trusted-root-certificate-authority-keys-to-sql-server), skip this section.
 
-Issues with the certificate chain can degrade the link. To prevent this issue, *validate the certificate chain on SQL Server* regularly.
+Problems with the certificate chain can degrade the link. To prevent this problem, *regularly validate the certificate chain on SQL Server*.
 
-The following scenarios can cause issues with the certificate chain on SQL Server:
+The following scenarios can cause problems with the certificate chain on SQL Server:
 - Scheduled certificate rotation on SQL Managed Instance.
 - Unintentional or accidental changes to the certificates on SQL Server, such as dropping or altering the certificate used to secure the database mirroring endpoint.
 
@@ -121,17 +121,25 @@ EXEC sp_validate_certificate_ca_chain <certificate_id>
 GO 
 ```
 
-A response of `Commands completed successfully. Completion time: ...` indicates the MI endpoint certificate has been successfully validated. 
+A response of `Commands completed successfully. Completion time: ...` indicates the MI endpoint certificate is successfully validated. 
 
 > [!IMPORTANT]
-> The stored procedure `sp_validate_certificate_ca_chain` relies on host OS services to perform certificate validation, which might involve an online certificate revocation check. If the host OS is not configured to access the internet, the execution fails even if the certificate chain is valid. 
+> The stored procedure `sp_validate_certificate_ca_chain` relies on host OS services to perform certificate validation, which might involve an online certificate revocation check. If the host OS isn't configured to access the internet, the execution fails even if the certificate chain is valid. 
 
 If you encounter an error, the most reliable mitigation is to restore the certificate chain by first [dropping](/sql/t-sql/statements/drop-certificate-transact-sql) all certificates created in sections [Get the certificate public key from SQL Managed Instance and import it to SQL Server](managed-instance-link-configure-how-to-scripts.md#get-the-certificate-public-key-from-sql-managed-instance-and-import-it-to-sql-server) and [Import Azure-trusted root certificate authority keys to SQL Server](managed-instance-link-configure-how-to-scripts.md#import-azure-trusted-root-certificate-authority-keys-to-sql-server), and then reimporting them again.
 
 ## Add startup trace flags
 
 In SQL Server, there are two trace flags (`-T1800` and `-T9567`) that, when added as startup parameters, can optimize the performance of data replication through the link. See [Enable startup trace flags](managed-instance-link-preparation.md#enable-startup-trace-flags) to learn more. 
 
+## Use synchronous commit with caution 
+
+The default commit mode for the link is asynchronous. While it's possible to change the commit mode to synchronous, it's not recommended and not necessary to secure against potential data loss. 
+
+During a planned linked failover, replication temporarily switches to synchronous commit mode until the failover completes. After failover, the commit mode switches back to asynchronous, even if it's explicitly set to synchronous commit mode before the failover.
+
+Using synchronous commit mode for the link can impact the performance of your primary replica, especially if there's high network latency between the replicas. In synchronous commit mode, transactions on the primary replica must wait for confirmation that the transaction log records are hardened on the secondary replica before the transaction can be committed on the primary. This waiting time increases with higher network latency, which can lead to increased transaction response times and reduced throughput on the primary replica.
+
 ## Related content
 
 To use the link: