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

故障转移链接 - Azure SQL 托管实例

适用于： Azure SQL 托管实例

本文介绍如何使用 SQL Server Management Studio (SSMS) 或 PowerShell 来故障转移 SQL Server 和 Azure SQL 托管实例之间链接的数据库。

注意

• 目前只能在预览版中将 Azure SQL 托管实例配置为初始主要副本，并且仅从 SQL Server 2022 CU10 开始支持此功能。

先决条件

若要通过链接将数据库故障转移到次要副本，需要满足以下先决条件：

• 一个有效的 Azure 订阅。 如果没有帐户，请创建一个免费帐户。
• 支持的 SQL Server 版本，安装了所需的服务更新。
• 主副本和辅助副本之间配置的链接。

停止工作负载

若要将数据库故障转移到次要副本，请先在维护时段停止主要副本上的任何应用程序工作负载。 这使数据库复制能够赶上次要副本，让你能在不丢失数据的情况下故障转移到次要副本。 在进行故障转移之前，请确保应用程序不会向主要副本提交事务。

故障转移数据库

可以使用 SQL Server Management Studio 或 PowerShell 来故障转移链接的数据库。

SQL Server Management Studio

使用 SSMS 中的“SQL Server 和托管实例之间的故障转移”向导，将数据库从主要副本故障转移到次要副本。

可以从主要副本或次要副本执行计划的故障转移。 若要执行强制故障转移，请连接到次要副本。

注意

• 在进行故障转移之前，请停止源数据库上的工作负载，使复制数据库能够完全赶上进度并完成故障转移，且不会丢失数据。 如果你正在执行强制故障转移，则可能会丢失数据。
• 若在 SQL Server 2019 及更早版本中故障转移数据库，会断开并删除两个副本之间的链接。 无法故障回复到初始主要副本。
• 目前可在预览版中故障转移数据库，同时保留与 SQL Server 2022 的链接。

若要故障转移数据库，请执行以下步骤：

1. 打开 SSMS 并连接到任一副本。

2. 在“对象资源管理器”中，右键单击复制的数据库，将鼠标悬停在“Azure SQL 托管实例链接”上，并选择“故障转移...”打开“SQL Server 和托管实例之间的故障转移”向导。 如果有来自同一数据库的多个链接，请在“对象资源管理器”中的“Always On 可用性组”下展开“可用性组”，然后右键单击要用于故障转移的链接所属的分布式可用性组。 选择“故障转移...”打开“SQL Server 和托管实例之间的故障转移”向导，以获取该特定链接。

   

3. 在“简介” 页上，选择“下一步”。

4. “选择故障转移类型”页显示有关每个副本、所选数据库的角色以及支持的故障转移类型的详细信息。 可以从任何副本启动故障转移。 如果选择强制故障转移，则必须选中相应的方框，以表明你了解可能会出现数据丢失的情况。 选择下一步。

   注意

   如果要迁移到 Azure SQL 托管实例，请选择“计划内故障转移”。

5. 在“登录到 Azure 和远程实例”页上：

   1. 选择“登录”以提供凭证并登录到 Azure 帐户。
   2. 根据在上一页上选择的故障转移类型，登录选项的功能会有所不同。 对于计划内故障转移，必须登录到远程实例（SQL Server 或 SQL 托管实例）。 对于强制故障转移，登录是可选的，因为支持以下两种应用场景：
      • 真正的灾难恢复：由于主实例在真正的灾难期间通常不可用，因此无法登录，用户必须立即故障转移到辅助实例，使其成为新的主实例。 中断得到解决后，链接处于不一致状态，因为两个副本现在都处于主要角色（脑裂应用场景）。
      • 灾难恢复演练：不建议使用强制故障转移执行灾难恢复演练，因为可能存在潜在的数据丢失。 但是，在演练期间，由于主实例可用，因此支持登录，并且你可以选择撤消这两个副本的角色，以避免脑裂应用场景的出现。

6. 在“故障转移后操作”页上，SQL Server 2022 和早期版本之间的选项不同，你是否能够连接到主实例也会导致选项不同。

   • 对于 SQL Server 2022，可以选择停止副本之间的复制操作，这会在故障转移完成后删除链接和分布式可用性组。 如果要维护链接并继续执行副本之间的复制操作，请取消选中相应的方框。 如果选择删除链接，还可以选中相应的方框来删除可用性组（如果只是为了将数据库复制到 Azure 而创建，并且你不再需要该可用性组）。 选中适合你的场景的相应方框，然后选择“下一步”。
   • 对于 SQL Server 2019 及更早版本，默认情况下，“删除链接”的选项已选中，并且无法取消选中该选项，这是因为故障转移到 SQL 托管实例时会停止复制操作、断开连接并删除分布式可用性组。 选中此框以表明你了解链接将被删除，然后选择“下一步”。
   • （可选）如果能够在上一页上登录到 SQL Server 实例，还可以通过选中“清理”部分中的框，在强制故障转移后删除 SQL Server 实例上的可用性组。

7. 在“摘要”页上查看操作。 或者，选择“脚本”以生成脚本，以便将来可以轻松地使用同一链接对该数据库进行故障转移。 准备好对数据库进行故障转移时，选择“完成”。

8. 完成所有步骤后，“结果”页会在已成功完成的操作旁边显示复选标记。 现在可以关闭窗口。

如果选择为 SQL Server 2022 维护链接，则次要副本将变为新的主要副本，该链接仍然处于活动状态，你可以故障回复到次要副本。

如果使用的是 SQL Server 2019 及更早版本，或者选择为 SQL Server 2022 删除链接，则链接将被删除，故障转移完成后不会再存在。 每个副本上的源数据库和目标数据库都可以执行读/写工作负荷。 它们是完全独立的。

重要

成功故障转移到 SQL 托管实例后，手动将应用程序连接字符串重新指向 SQL 托管实例 FQDN，以完成迁移或故障转移过程，并继续在 Azure 中运行。

PowerShell

若要故障转移，首先必须使用 Transact-SQL (T-SQL) 切换 SQL Server 实例的复制模式。

然后，可以使用 PowerShell 对角色进行故障转移和切换。

切换复制模式（故障转移到 SQL MI）

默认情况下，SQL Server 和 SQL 托管实例之间的复制是异步的。 如果要从 SQL Server 故障转移到 Azure SQL 托管实例，请在故障转移数据库之前，使用 Transact-SQL (T-SQL) 将链接切换到 SQL Server 上的同步模式。

注意

• 如果从 SQL 托管实例故障转移到 SQL Server 2022，则跳过该步骤。
• 大范围网络距离的同步复制可能会减慢主要副本上的事务处理速度。

运行 SQL Server 上的以下 T-SQL 脚本，将分布式可用性组的复制模式从异步更改为同步。进行以下替换：

• <DAGName> 替换为分布式可用性组的名称（用于创建链接）。
• <AGName> 替换为在 SQL Server 上创建的可用性组的名称（用于创建链接）。
• <ManagedInstanceName> 替换为托管实例的名称。

-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

若要确认是否已成功更改链接的复制模式，请使用以下动态管理视图。 结果指示 SYNCHRONOUS_COMMIT 状态。

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

现在，你已将 SQL Server 切换为同步提交模式，这两个实例之间的复制现在是同步的。 如果需要反转此状态，请执行相同的步骤并将 AVAILABILITY_MODE 设置为 ASYNCHRONOUS_COMMIT。

检查 SQL Server 和 SQL 托管实例上的 LSN 值

若要完成故障转移或迁移，请确认到辅助副本的复制已完成。 为此，请确保 SQL Server 和 SQL 托管实例的日志记录中的日志序列号 (LSN) 是相同的。

最初，预计主要副本上的 LSN 将高于次要副本上的 LSN。 网络延迟可能会导致复制速度落后于主要副本。 由于主要副本上的工作负载已停止，因此 LSN 将匹配并在一段时间后停止更改。

在 SQL Server 上使用以下 T-SQL 查询来读取最近记录的事务日志的 LSN。 将：

• <DatabaseName> 替换为数据库名称并查找最后一个强化的 LSN 编号。

-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

在 SQL 托管实例上使用以下 T-SQL 查询来读取数据库的最后一个强化的 LSN。 将 <DatabaseName> 替换为你的数据库名称。

此查询将适用于常规用途 SQL 托管实例。 对于业务关键 SQL 托管实例，需要取消注释脚本末尾的 and drs.is_primary_replica = 1。 在业务关键服务层级，此筛选器可确保仅读取主要副本的详细信息。

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

或者，还可以使用 Get-AzSqlInstanceLink PowerShell 或 az sql mi link show Azure CLI 命令获取 SQL 托管实例上链接的 LastHardenedLsn 属性，该属性将提供与之前的 T-SQL 查询相同的信息。

重要

再次验证你的工作负载是否已在主要副本上停止。 检查 SQL Server 和 SQL 托管实例上的 LSN 是否匹配，并且在一段时间内保持匹配和不变。 如果两种实例上的 LSN 稳定，则表示已将尾部日志复制到次要副本，并且工作负载已实际停止。

故障转移数据库

如果想要使用 PowerShell 在 SQL Server 2022 和 SQL 托管实例之间故障转移数据库，同时仍保留链接，或者要对任何版本的 SQL Server 执行故障转移（但会丢失数据），请在 SSMS 中使用 SQL Server 和托管实例之间的故障转移向导来生成适合你的环境的脚本。 可以从主要副本或次要副本执行计划的故障转移。 若要执行强制故障转移，请连接到次要副本。

若要在故障转移或迁移数据库时断开链接并停止复制，而无论 SQL Server 版本如何，请使用 Remove-AzSqlInstanceLink PowerShell 或 az sql mi link delete Azure CLI 命令。

注意

• 在进行故障转移之前，请停止源数据库上的工作负载，使复制数据库能够完全赶上进度并完成故障转移，且不会丢失数据。 如果执行强制故障转移，或者在 LSN 匹配之前断开链接，可能会丢失数据。
• 若在 SQL Server 2019 及更早版本中故障转移数据库，会断开并删除两个副本之间的链接。 无法故障回复到初始主要副本。
• 目前可在预览版中故障转移数据库，同时保留与 SQL Server 2022 的链接。

以下示例脚本会断开链接并结束副本之间的复制，使数据库可在两个实例上执行读/写操作。 将：

• <ManagedInstanceName> 替换为托管实例的名称。
• <DAGName> 替换为要进行故障转移的链接的名称（上述 Get-AzSqlInstanceLink 命令的属性 Name 的输出）。

# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

故障转移成功后，链接将被删除，不再存在。 SQL Server 数据库和 SQL 托管实例数据库都可以执行读/写工作负载，因为它们现在已完全独立。

重要

成功故障转移到 SQL 托管实例后，手动将应用程序连接字符串重新指向 SQL 托管实例 FQDN，以完成迁移或故障转移过程，并继续在 Azure 中运行。

删除链接后，可以在 SQL Server 上保留可用性组，但必须删除分布式可用性组才能从 SQL Server 中删除链接元数据。 仅当使用 PowerShell 进行故障转移时，才需要执行此附加步骤，因为 SSMS 会为你执行此操作。

若要删除分布式可用性组，请替换以下值，然后运行示例 T-SQL 代码：

• <DAGName> 替换为 SQL Server 上分布式可用性组的名称（用于创建链接）。

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

故障转移后查看数据库

对于 SQL Server 2022，如果选择维持链接，则可以检查分布式可用性组是否存在于 SQL Server Management Studio 中对象资源管理器的可用性组下。

如果在故障转移期间删除了链接，则可以使用对象资源管理器来确认分布式可用性组不再存在。 如果选择保留可用性组，则数据库仍将同步。

清理可用性组

由于使用 SQL Server 2022 进行故障转移不会中断此链接，因此可以在故障转移后维持链接，这会使可用性组和分布式可用性组保持活动状态。 无需执行其他操作。

但是，删除链接只会删除分布式可用性组，并使可用性组保持活动状态。 可以决定保留可用性组，或将其删除。

如果决定删除可用性组，请替换以下值，然后运行示例 T-SQL 代码：

• <AGName> 替换为 SQL Server 上可用性组的名称（用于创建链接）。

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

相关内容

有关链接功能的详细信息，请参阅以下资源：

• 托管实例链接概述
• 为托管实例链接准备环境
• 使用脚本配置 SQL Server 与 SQL 托管实例之间的链接
• 使用托管实例链接进行灾难恢复
• 有关维护链接的最佳做法