你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

故障排除链接 - Azure SQL 托管实例

适用于:Azure SQL 托管实例

本文介绍如何监视和排查 SQL Server 与 Azure SQL 托管实例之间的链接问题。

可以使用 Transact-SQL(T-SQL)、Azure PowerShell 或 Azure CLI 检查链接的状态。 如果遇到问题,可以使用错误代码来解决问题。

可以通过检查两个实例之间的网络和验证已针对链接正确准备好环境来解决创建链接的许多问题。

如果链接出现问题,可以使用 Transact-SQL (T-SQL)、Azure PowerShell 或 Azure CLI 获取有关链接的当前状态的信息。

使用 T-SQL 获取链接状态的快速状态详细信息,然后使用 Azure PowerShell 或 Azure CLI 获取有关链接当前状态的完整信息。

使用 T-SQL 确定播种阶段或数据同步开始后链接的状态。

使用以下 T-SQL 查询,确定在托管通过该链接进行种子设定的数据库的 SQL Server 或 SQL 托管实例上,该链接在种子设定阶段的状态:

SELECT
    ag.local_database_name AS 'Local database name',
    ar.current_state AS 'Current state',
    ar.is_source AS 'Is source',
    ag.internal_state_desc AS 'Internal state desc',
    ag.database_size_bytes / 1024 / 1024 AS 'Database size MB',
    ag.transferred_size_bytes / 1024 / 1024 AS 'Transferred MB',
    ag.transfer_rate_bytes_per_second / 1024 / 1024 AS 'Transfer rate MB/s',
    ag.total_disk_io_wait_time_ms / 1000 AS 'Total Disk IO wait (sec)',
    ag.total_network_wait_time_ms / 1000 AS 'Total Network wait (sec)',
    ag.is_compression_enabled AS 'Compression',
    ag.start_time_utc AS 'Start time UTC',
    ag.estimate_time_complete_utc as 'Estimated time complete UTC',
    ar.completion_time AS 'Completion time',
    ar.number_of_attempts AS 'Attempt No'
FROM sys.dm_hadr_physical_seeding_stats AS ag
    INNER JOIN sys.dm_hadr_automatic_seeding AS ar
    ON local_physical_seeding_id = operation_id

-- Estimated seeding completion time
SELECT DISTINCT CONVERT(VARCHAR(8), DATEADD(SECOND, DATEDIFF(SECOND, start_time_utc, estimate_time_complete_utc) ,0), 108) as 'Estimated complete time'
FROM sys.dm_hadr_physical_seeding_stats

如果查询未返回任何结果,则播种过程尚未启动或已完成。

实例上使用以下 T-SQL 查询,在数据同步开始后检查链接的运行状况:

DECLARE @link_name varchar(max) = '<DAGname>'
SELECT
   rs.synchronization_health_desc [Link sync health]
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 0 AND rs.role = 2 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

该查询返回以下可能的值:

  • 无结果:查询是在辅助实例上执行的。
  • HEALTHY:链接正常,数据正在副本之间同步。
  • NOT_HEALTHY:链接不正常,数据在副本之间不同步。

replicaState 值描述当前链接。 如果状态还包括“错误”,则在状态中列出的操作期间已发生错误。 例如,LinkCreationError 指示创建链接时出错。

一些可能的 replicaState 值为

  • CreatingLink:初始种子设定
  • LinkSynchronizing:数据复制正在进行
  • LinkFailoverInProgress:故障转移正在进行

有关链接状态属性的完整列表,请查看 分布式可用性组 - GET REST API 命令。

使用链接时可能会遇到两个不同的错误类别 - 尝试初始化链接时出错,尝试创建链接时出错。

初始化链接时,可能会出现以下错误(链接状态:LinkInitError):

  • 错误 41962:操作中止,因为链接未在 5 分钟内启动。 检查 网络连接,然后重试。
  • 错误 41973:无法建立链接,因为 SQL Server 中的 终结点证书未正确导入 Azure SQL 托管实例。
  • 错误 41974:无法建立链接,因为 SQL 托管实例中的 终结点证书 未正确导入 SQL Server。
  • 错误 41976:可用性组未响应。 检查名称和配置参数,然后重试。
  • 错误 41986:由于连接失败或辅助副本未响应,无法建立链接。 请检查名称、配置参数和网络连接,然后重试。
  • 错误 47521:无法建立链接,因为辅助服务器未收到请求。 请确保可用性组和数据库在主服务器上正常运行,然后重试。

创建链接时,可能会出现以下错误(链接状态:LinkCreationError):

  • 错误 41977:目标数据库未响应。 检查链接参数,然后重试。

强制故障转移后的状态不一致

在强制故障转移后,可能会遇到两个副本处于主要角色的脑裂场景,导致链接处于不一致状态。 如果在灾难期间故障转移到辅助副本,并且主副本重新联机,则可能发生这种情况。

首先,确认你处于脑裂场景。 可以使用 SQL Server Management Studio(SSMS)或 Transact-SQL(T-SQL)执行此操作。

连接到 SSMS 中的 SQL Server 和 SQL 托管实例,然后在“对象资源管理器”中,在“Always On 高可用性”中的“可用性组”节点下,展开“可用性副本”。 如果两个不同的副本列为“(主要)”,则表示处于脑裂场景

或者,可以在 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], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   JOIN sys.dm_hadr_availability_replica_states rs 
   ON ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 AND ag.is_distributed = 1 AND ag.name = @link_name 
GO

如果两个实例的“链接角色”列中列出“主要”,则表示处于脑裂场景

要解决脑裂状态,请首先对曾是原始主要副本的任意副本进行备份。 如果原始主服务器为 SQL Server,则请进行结尾日志备份。 如果原始主要副本是 SQL 托管实例,则可进行仅复制完整备份。 备份完成后,将分布式可用性组设置为曾用作原始主要副本(但现在将作为新辅助副本)的副本的辅助角色。

例如,如果发生真正灾难,假设已强制将 SQL Server 工作负载故障转移到 Azure SQL 托管实例,并且打算继续在 SQL 托管实例上运行工作负载,在 SQL Server 上执行结尾日志备份,然后将分布式可用性组设置为 SQL Server 上的辅助角色,例如以下示例:

--Execute on SQL Server 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] 
SET (ROLE = SECONDARY) 
GO 

接下来,使用链接执行从 SQL 托管实例到 SQL Server 的计划手动故障转移,例如以下示例:

--Execute on SQL Managed Instance 
USE master
ALTER AVAILABILITY GROUP [<DAGName>] FAILOVER 
GO 

测试网络连接

需要 SQL Server 和 SQL 托管实例之间的双向网络连接才能使链接正常工作。 在 SQL Server 端打开端口并在 SQL 托管实例端配置 NSG 规则后,请使用 SQL Server Management Studio(SSMS)或 Transact-SQL 测试连接。

通过在 SQL Server 和 SQL 托管实例上创建临时 SQL 代理作业来测试网络,以检查两个实例之间的连接。 在 SSMS 中使用 网络检查器 时,作业会自动为你创建,并在测试完成后删除。 如果使用 T-SQL 测试网络,则需要手动删除 SQL 代理作业。

注意

目前不支持通过 Linux 上的 SQL Server 上的 SQL Server 代理执行 PowerShell 脚本,因此目前无法从 Linux 上的 SQL Server 上的 SQL Server 代理作业执行 Test-NetConnection

若要使用 SQL 代理测试网络连接,需要满足以下要求:

  • 执行测试的用户必须对 SQL Server 和 SQL 托管实例具有创建作业权限(作为 sysadmin 或属于 msdb 的 SQLAgentOperator 角色)
  • SQL Server 代理服务必须在 SQL Server 上运行。 由于代理默认在 SQL 托管实例上处于打开状态,因此无需执行其他操作。

若要在 SSMS 中测试 SQL Server 与 SQL 托管实例之间的网络连接,请执行以下步骤:

  1. 连接到将在 SSMS 中作为主要副本的实例。

  2. 在“对象资源管理器”中,展开数据库,右键单击要链接到辅助副本的数据库。 选择“任务”>“Azure SQL 托管实例链接”>“测试连接”以打开“网络检查器”向导

    SSMS 中“对象资源管理器”的屏幕截图,数据库链接的右键菜单中选择了“测试连接”。

  3. 在“网络检查器”向导的“简介”页上选择“下一步”

  4. 如果满足“先决条件”页上的所有要求,请选择“下一步”。 否则,请解决所有未满足的先决条件,然后选择“重新运行验证”

  5. 登录 页上,选择 登录 以连接到将作为次要副本的另一个实例。 选择“下一步”

  6. 查看 “指定网络选项” 页的详细信息,并在必要时提供 IP 地址。 选择“下一步”

  7. 摘要 页上,查看向导执行的操作,然后选择 完成 以测试两个副本之间的连接。

  8. 查看“结果”页以验证两个副本之间的连接,然后选择 “关闭” 以完成。

谨慎

仅当已验证源环境和目标环境之间的网络连接时,才继续执行后续步骤。 否则,在继续操作之前排查网络连接问题。

有关链接功能的详细信息,请查看以下资源: