托管实例链接最佳做法 - Azure SQL 托管实例

适用于：Azure SQL 托管实例

本文概述了使用托管实例链接在 Azure SQL 托管实例与任何位置托管的 SQL Server 实例之间复制数据的最佳做法。该链接提供链接副本之间的准实时数据复制。

定期创建日志备份

在创建链接之前，尤其是对于大型数据库，或在多数据库链接模式下处理多个数据库时，应在受支持的 SQL Server 版本中使用跟踪标志 12381，以防止在设定种子期间日志被过早截断。日志备份可以在该标志启用期间继续，但保留的日志记录不会被重新使用。监控日志使用量、增长率和可用磁盘空间，并在所有正在创建的链接都完成设定初始值后立即禁用该标志。 SQL 托管实例错误日志中的播种错误 1408 或 1412 可能表明日志被过早截断。在重新创建链接前，请先查看链接的故障排除指南。

当 SQL Server 为主副本时，如果在受支持的版本上启用了跟踪标志 12381，则可以在播种期间继续执行事务日志备份。如果您暂停日志备份以防止过早截断，请在初始同步完成后恢复日志备份。如果你还没开始日志备份，建议在初始做种结束后先做第一个备份。所有创建链接的种种完成后，如果你启用了该标志，请禁用它，并在SQL Server仍为主链期间定期备份SQL Server事务日志。

链接功能使用基于 Always On 可用性组的分布式可用性组技术复制数据。分布式可用性组数据复制基于复制事务日志记录。主 SQL Server 实例在复制到次要副本上的数据库之前，无法截断数据库中的任何事务日志记录。如果网络连接问题导致事务日志复制速度缓慢或被阻止，则日志文件在主实例上不断增大。工作负荷和网络速度的强度决定了增长速度。如果网络连接中断已延长，并且主实例上的工作负荷很重，则日志文件可以占用所有可用的存储空间。

常规事务日志备份允许非活跃日志记录在无其他因素阻止截断时可重用。它们不会释放通过trace flag 12381、复制或活跃事务保留的记录，也不会缩小物理日志文件。当 SQL 托管实例是主实例时，无需额外操作，因为日志备份已经自动完成。根据你的工作负载安排定期SQL Server日志备份，监控日志使用情况和剩余磁盘空间。

可以使用 Transact-SQL (T-SQL) 脚本来备份日志文件，例如本部分提供的示例。请将示例脚本中的占位符替换为你的数据库名称、备份文件的名称和路径以及说明。

若要备份事务日志，请使用 SQL Server 上的以下示例 Transact-SQL (T-SQL) 脚本：

-- Execute on SQL Server
-- Take log backup
BACKUP LOG [<DatabaseName>]
TO DISK = N'<DiskPathandFileName>'
WITH NOFORMAT, NOINIT,
NAME = N'<Description>', SKIP, NOREWIND, NOUNLOAD, COMPRESSION, STATS = 1

使用以下 Transact-SQL (T-SQL) 命令检查 SQL Server 上的数据库使用的日志空间：

-- Execute on SQL Server
DBCC SQLPERF(LOGSPACE);

查询输出类似于以下示例数据库 tpcc：

显示日志文件大小和已用空间的命令结果屏幕截图

在此示例中，数据库使用了 76% 的可用日志空间，而绝对日志文件大小约为 27 GB (27,971 MB)。操作阈值可能因工作负载而异。在上一示例中，事务日志大小和日志使用百分比通常表示应执行事务日志备份来截断日志文件并释放一些空间，或者应采取更频繁的日志备份。可能也表明由于一些未完成的事务，事务日志截断被阻止。有关排除 SQL Server 中事务日志故障的更多信息，请参阅排除完整事务日志故障 (SQL Server Error 9002)。有关排查 Azure SQL 托管实例中的事务日志问题的详细信息，请参阅排查 Azure SQL 托管实例的事务日志错误。

注意

参与链接时，SQL 托管实例会自动执行完整备份和事务日志备份，无论它是否为主要副本。不会进行差异备份，否则可能会导致还原时间更长。

匹配副本之间的性能容量

使用链接功能时，请匹配 SQL Server 和 SQL 托管实例之间的性能容量。如果辅助副本无法与主副本的复制保持同步，或者在故障转移后，这种匹配有助于避免性能问题。性能容量包括 CPU 核心（或 Azure 中的 vCore）、内存和 I/O 吞吐量。

可以通过检查次要副本上的重做队列大小来监视复制的性能。重做队列大小显示在次要副本上等待被重做的日志记录的数量。次要副本的重做队列大小持续保持在较高水平，表明其无法跟上主副本的速度。您可以通过以下方式检查重做队列的大小：

在主要副本上的动态管理视图 redo_queue_size 中的值。
InstanceRedoLagReplicationSeconds 中的值在主要副本上。

如果重做队列大小持续较高，请考虑增加次要副本上的资源。

监视复制滞后时间

监视复制滞后时间有助于确定辅助副本与主副本同步的速度。一个很大的差异表明，次要副本无法跟上主副本，这通常是由两个实例之间的链接中网络吞吐量缓慢、两个副本之间的资源分配不匹配或主副本上的工作负荷过高引起的。

执行计划的故障转移时，监视复制滞后尤其重要，这要求在执行故障转移之前，辅助副本与主副本完全同步。如果复制滞后时间较长，故障转移可能需要更长时间才能完成，在某些情况下，甚至有可能失败。

对SQL Server和SQL 托管实例使用以下 T-SQL 查询监视副本之间的复制延迟：

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   ag.name [Link name], 
   ars1.role_desc [Link role],
   ars2.connected_state_desc [Link connected state],
   ars2.synchronization_health_desc [Link sync health],
   drs.secondary_lag_seconds [Link replication latency (seconds)]
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states ars1
   ON ag.group_id = ars1.group_id
   JOIN sys.dm_hadr_availability_replica_states ars2
   ON ag.group_id = ars2.group_id
   JOIN sys.dm_hadr_database_replica_states drs
   ON ars2.replica_id = drs.replica_id
WHERE 
   ag.is_distributed = 1 AND ag.name = @link_name AND ars1.is_local = 1 AND ars2.is_local = 0
GO

轮换证书

可能需要手动轮换用于保护 SQL Server 上的数据库镜像终结点的证书。由于服务管理和自动轮换用于保护 SQL 托管实例上的数据库镜像终结点的证书，因此无需手动轮换它。

SQL Server

用于保护 SQL Server 上的数据库镜像终结点的证书可能会过期。如果证书过期，可能会导致链路降级。若要防止此问题，请在证书过期前轮换证书。

使用以下 Transact-SQL (T-SQL) 命令检查当前证书的期满日：

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

如果证书即将过期或已过期，请创建新的证书，然后更改现有终结点以替换当前证书。

将终结点配置为使用新证书后，可以删除过期的证书。

SQL 托管实例

SQL 托管实例上的数据库镜像终结点证书会定期自动轮换。无需监视 SQL 托管实例上的数据库镜像终结点证书的到期日期，只要可以成功验证 SQL Server 上的证书链。

验证 SQL Server 上的证书链

注意

定期验证现有链接的证书链，或排查降级链接的问题。如果要配置新链接或最近完成部分中的步骤：从 SQL 托管实例获取证书公钥并将其导入 SQL Server ，并将 Azure 受信任的根证书颁发机构密钥导入 SQL Server，请跳过本部分。

证书链问题可能会导致连接质量下降。若要防止此问题， 请定期验证 SQL Server 上的证书链。

以下方案可能会导致 SQL Server 上的证书链出现问题：

SQL 托管实例上的计划证书轮换。
无意或意外更改 SQL Server 上的证书，例如删除或更改用于保护数据库镜像终结点的证书。

首先，通过替换certificate_id的值来确定导入的 MI 终结点证书，然后在 SQL Server 上运行以下查询：

-- Run on SQL Server 
USE master 
SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

接下来，通过替换上一个查询结果中的 <certificate_id> 值，然后在 SQL Server 上运行以下查询，来验证证书：

-- Run on SQL Server 
USE master
EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Commands completed successfully. Completion time: ... 表示 MI 终结点证书已成功验证的响应。

重要

存储过程 sp_validate_certificate_ca_chain 依赖于主机 OS 服务来执行证书验证，这可能涉及联机证书吊销检查。如果未将主机 OS 配置为访问 Internet，则即使证书链有效，执行也会失败。

如果遇到错误，最可靠的缓解措施是首先删除在“ 从 SQL 托管实例获取证书公钥 ”部分中创建的所有证书，然后将其导入 SQL Server，并将 Azure 受信任的根证书颁发机构密钥导入 SQL Server，然后重新导入证书链。

添加启动跟踪标志

在 SQL Server 中，将两个跟踪标志（-T1800 和 -T9567）添加为启动参数后，可以优化通过链接进行数据复制的性能。有关详细信息，请参阅启用启动跟踪标志。

谨慎使用同步提交

链接的默认提交模式是异步的。虽然可以将提交模式更改为同步模式，但不建议这样做，也不需要保护它免受潜在的数据丢失的影响。

在计划的链接故障转移期间，复制会暂时切换到同步提交模式，直到故障转移完成。故障转移后，提交模式将切换回异步，即使在故障转移之前已显式设置为同步提交模式。

对此链接使用同步提交模式可能会影响主副本的性能，尤其是在副本之间存在较高网络延迟的情况下。在同步提交模式下，主副本上的事务必须等待确认事务日志记录已在次要副本上写入并持久化，然后才能在主副本上提交。此等待时间随着网络延迟的增加而增加，这可能导致事务响应时间增加，并降低主副本的吞吐量。

要使用该链接，请参阅以下内容：

要了解有关该链接的详细信息，请参阅以下内容：

对于其他复制和迁移方案，请考虑：

Última atualização em 2026-10-16