你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn。
使用日志重播服务将数据库从 SQL Server 迁移到 Azure SQL 托管实例
适用于: Azure SQL 托管实例
本文介绍如何使用日志重播服务 (LRS) 将数据库迁移到 Azure SQL 托管实例。 LRS 是适用于 Azure SQL 托管实例的免费云服务,基于 SQL Server 日志传送技术。
支持以下源:
- 虚拟机上的 SQL Server
- Amazon EC2 (Elastic Compute Cloud)
- 适用于 SQL Server 的 Amazon RDS(关系数据库服务)
- Google Compute Engine
- Cloud SQL for SQL Server - GCP (Google Cloud Platform)
先决条件
在开始之前,请考虑 SQL Server 实例和 Azure 的以下要求。 请仔细查看限制和最佳做法部分,确保成功迁移。
重要
- 将数据库迁移到“业务关键”服务层级之前,请考虑这些限制,它们不适用于“常规用途”服务层级。
- 在迁移过程完成之前,不能使用正在通过 LRS 还原的数据库。
- LRS 不支持在迁移期间对数据库进行只读访问。
- 迁移结束后,迁移过程就终止了,无法通过其他差异备份恢复。
将数据库迁移到“业务关键”服务层级之前,请考虑这些限制,它们不适用于“常规用途”服务层级。
SQL Server
请确保满足以下 SQL Server 要求:
- SQL Server 版本 2008 到 2022。
- SQL Server 数据库正在使用完整恢复模式(必需)。
- 数据库的完整备份(一个或多个文件)。
- 差异备份(一个或多个文件)。
- 日志备份(不为事务日志文件进行拆分)。
- 对于 SQL Server 版本 2008 到 2016,请在本地创建备份并将其手动上传到 Azure Blob 存储帐户。
- 对于 SQL Server 2016 及更高版本,可以直接备份到 Azure Blob 存储帐户。
- 虽然不需要为备份启用
CHECKSUM
,但强烈推荐启用它,以防止无意中迁移损坏的数据库并加快还原操作速度。
Azure
请确保满足以下 Azure 要求:
- PowerShell Az.SQL 模块版本 4.0.0 或更高版本(已安装或通过 Azure Cloud Shell 访问)。
- Azure CLI 版本 2.42.0 或更高版本(已安装)。
- 预配的 Azure Blob 存储容器。
- 共享访问签名 (SAS) 安全令牌,具有为 Blob 存储容器或可访问容器的托管标识生成的
Read
和List
权限。 授予超出Read
和List
的权限会导致 LRS 失败。 - 使用平面文件结构将单个数据库的备份文件放入存储帐户的单独文件夹中(必需)。 不支持数据库文件夹内的嵌套文件夹。
Azure RBAC 权限
通过系统提供的客户端运行 LRS 需要以下 Azure 基于角色的访问控制 (RBAC) 角色之一:
- SQL 托管实例参与者角色
- 具有以下权限的角色:
Microsoft.Sql/managedInstances/databases/*
最佳实践
使用 LRS 时,请考虑以下最佳做法:
- 运行数据迁移助手,验证数据库是否已准备好迁移到 SQL 托管实例。
- 将完整备份和差异备份拆分为多个文件,而不是使用一个文件。
- 启用备份压缩以帮助提高网络传输速度。
- 使用 Cloud Shell 来运行 PowerShell 或 CLI 脚本,因为它始终更新以使用最新发布的 cmdlet。
- 配置维护时段,以便在迁移时段之外的特定日期和时间计划系统更新,防止延迟或中断迁移。
- 计划在最多 30 天内完成单个 LRS 迁移作业。 在此时间范围到期时,LRS 作业会自动取消。
- 为了防止无意中迁移损坏的数据库并加快还原操作速度,请在进行备份时启用
CHECKSUM
。 虽然在没有CHECKSUM
的情况下,SQL 托管实例会对备份执行基本完整性检查,但不保证捕获所有形式的损坏。 使用CHECKSUM
进行备份是确保还原到 SQL 托管实例的备份未损坏的唯一方法。 在没有CHECKSUM
的情况下对备份进行基本完整性检查会增加数据库的还原时间。 - 迁移到“业务关键”服务层级时,请考虑直接转换后数据库可用性中的长时间延迟,因为数据库会播种到次要副本。 尤其对于要求尽量减少停机时间的大型数据库,请考虑先迁移到“常规用途”服务层级,然后再升级到“业务关键”服务层级,或使用托管实例链接迁移数据。
- 上传数千个数据库文件进行还原可能会导致迁移时间过长,甚至失败。 将数据库合并到更少的文件中来加快迁移过程,并确保迁移成功。
配置维护时段
SQL 托管实例上的系统更新优先于正在进行的数据库迁移。
不同的服务层级对迁移的影响不同:
- 在“常规用途”服务层级中,所有挂起的 LRS 迁移会暂停,仅在应用更新后才恢复。 此系统行为可能会延长迁移时间,尤其是对于大型数据库。
- 在“业务关键”服务层级中,所有挂起的 LRS 迁移会被取消,并在应用更新后自动重启。 此系统行为可能会延长迁移时间,尤其是对于大型数据库。
若要实现数据库迁移的可预测时间,请考虑配置维护时段以计划特定日期和时间的系统更新,并在指定维护时段外运行和完成迁移作业。 例如,对于从星期一开始的迁移,请在周日配置自定义维护时段,以便有最多的时间来完成迁移。
无需配置维护时段,但强烈建议对大型数据库配置。
注意
虽然维护时段控制计划内更新的可预测性,但不能保证不会发生计划外故障转移或安全修补程序更新。 计划外故障转移或安全修补程序(优先于所有其他更新)仍可能会中断迁移。
迁移多个数据库
如果使用同一个 Azure Blob 存储容器迁移多个数据库,则必须将不同数据库的备份文件放入该容器内的单独文件夹中。 单个数据库的所有备份文件必须放在数据库文件夹内的平面文件结构中,并且文件夹不能嵌套。 不支持数据库文件夹内的嵌套文件夹。
下面是 Azure Blob 存储容器内的文件夹结构示例,使用 LRS 迁移多个数据库需要这种结构。
-- Place all backup files for database 1 in a separate "database1" folder in a flat-file structure.
-- Don't use nested folders inside the database1 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database1>/<all-database1-backup-files>
-- Place all backup files for database 2 in a separate "database2" folder in a flat-file structure.
-- Don't use nested folders inside the database2 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database2>/<all-database2-backup-files>
-- Place all backup files for database 3 in a separate "database3" folder in a flat-file structure.
-- Don't use nested folders inside the database3 folder.
https://<mystorageaccountname>.blob.core.windows.net/<containername>/<database3>/<all-database3-backup-files>
创建存储帐户
使用 Azure Blob 存储帐户作为 SQL Server 实例与 SQL 托管实例部署之间的备份文件的中间存储。 若要在存储帐户中创建新的存储帐户和 blob 容器:
- 创建存储帐户。
- 在存储帐户中创建 blob 容器。
在防火墙后配置 Azure 存储
支持使用受防火墙保护的 Azure Blob 存储,但需要其他配置。 要在启用 Azure 防火墙的情况下启用对 Azure 存储的读/写访问,必须使用 MI 子网委派和存储服务终结点将 SQL 托管实例的子网添加到存储帐户虚拟网络的防火墙规则中。 存储帐户和托管实例必须位于同一区域或两个配对区域。
如果 Azure 存储位于防火墙后,你可能会在 SQL 托管实例错误日志中看到以下消息:
Audit: Storage access denied user fault. Creating an email notification:
这会生成一封电子邮件,通知你对 SQL 托管实例的审核未能将审核日志写入存储帐户。 如果看到此错误或收到此电子邮件,请按照本部分中的步骤配置防火墙。
要配置防火墙,请执行以下步骤:
转到 Azure 门户中的托管实例,然后选择子网以打开“子网”页面。
在“子网”页上,选择子网的名称以打开子网配置页。
在“子网委派”下,从“将子网委托给服务”下拉菜单中选择“Microsoft.Sql/managedInstances”。 等待大约一小时的权限传播,然后在“服务终结点”下,从“服务”下拉列表中选择“Microsoft.Storage”。
接下来,转到 Azure 门户中的存储帐户,在“安全性 + 网络”下选择“网络”,然后选择“防火墙和虚拟网络”选项卡。
在存储帐户的“防火墙和虚拟网络”选项卡上,选择“+ 添加现有虚拟网络”,打开“添加网络”页面。
从下拉菜单中选择相应的订阅、虚拟网络和托管实例子网,然后选择“添加”,将 SQL 托管实例的虚拟网络添加到存储帐户。
对 Blob 存储帐户进行身份验证
使用 SAS 令牌或托管标识访问 Azure Blob 存储帐户。
警告
不能在同一存储帐户上同时使用 SAS 令牌和托管标识。 可以使用 SAS 令牌或托管标识,但不能同时使用两者。
为 LRS 生成 Blob 存储 SAS 身份验证令牌
使用 SAS 令牌访问 Azure Blob 存储 帐户。
可以使用 Azure Blob 存储帐户作为 SQL Server 实例与 SQL 托管实例部署之间的备份文件的中间存储。 为 LRS 生成仅具有只读和列出权限的 SAS 身份验证令牌。 该令牌使 LRS 能够访问 Blob 存储帐户并使用备份文件将它们还原到托管实例。
按照以下步骤生成令牌:
在 Azure 门户中,打开“存储资源管理器”。
展开“Blob 容器”。
右键单击 Blob 容器,然后选择“获取共享访问签名”。
选择令牌到期时间范围。 确保令牌在迁移期间有效。
选择令牌的时区:UTC 或本地时间。
重要
令牌的时区和托管实例可能不匹配。 请确保 SAS 令牌具有适当的时间有效性,并考虑时区因素。 要考虑时区差异,请设置早于迁移时间开始时间的有效期 FROM 值,以及晚于预计迁移结束时间的 TO 值。
仅选择“读取”和“列出”权限。
重要
不要选择任何其他权限。 否则,LRS 将无法启动。 此安全要求是设计使然。
选择“创建”。
系统将使用你指定的时间有效性生成 SAS 身份验证。 你需要令牌的 URI 版本,如以下屏幕截图所示:
注意
目前不支持通过定义存储访问策略设置的权限创建的 SAS 令牌。 按照本过程中的说明手动指定 SAS 令牌的读取和列出权限。
从 SAS 令牌复制参数
使用 SAS 令牌或托管标识访问 Azure Blob 存储帐户。
在使用 SAS 令牌启动 LRS 之前,你需要了解其结构。 系统生成的 SAS 令牌的 URI 由两部分组成,这两部分用问号 (?
) 隔开,如以下示例所示:
第一部分从 https://
开始,一直到问号 (?
) 前结束,该部分用于作为输入馈送到 LRS 的 StorageContainerURI
参数。 它向 LRS 提供存储数据库备份文件的文件夹的相关信息。
第二部分是 StorageContainerSasToken
参数,该部分从问号 (?
) 后开始一直到字符串末尾。 此部分是实际签名的身份验证令牌,在指定时间内有效。 此部分不一定需要像示例所示的那样从 sp=
开始。 你的方案可能有所不同。
按如下方式复制参数:
复制令牌的第一部分,从
https://
一直到问号 (?
)(不含)。 启动 LRS 时,将其用作 PowerShell 或 Azure CLI 中的StorageContainerUri
参数。复制该令牌的第二部分,从问号 (
?
) 后面开始,一直复制到该字符串的结尾。 启动 LRS 时,将其用作 PowerShell 或 Azure CLI 中的StorageContainerSasToken
参数。
注意
复制令牌的任一部分时,请勿包含问号 (?
)。
验证托管实例存储访问权限
验证托管实例是否可以访问 Blob 存储帐户。
首先,将任何数据库备份(如 full_0_0.bak
)上传到 Azure Blob 存储容器。
接下来,连接到托管实例,并运行示例测试查询,以确定托管实例是否能够访问容器中的备份。
如果使用 SAS 令牌对存储帐户进行身份验证,请将 <sastoken>
替换为 SAS 令牌,并在实例上运行以下查询:
CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/databases]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE'
, SECRET = '<sastoken>'
RESTORE HEADERONLY
FROM URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/full_0_0.bak'
将备份上传到 Blob 存储帐户
Blob 容器准备就绪并确认托管实例可以访问该容器后,可以开始将备份上传到 Blob 存储帐户。 可以:
- 将备份复制到 Blob 存储帐户。
- 如果环境允许(从 SQL Server 版本 2012 SP1 CU2 和 SQL Server 2014 开始),则使用 BACKUP TO URL 命令将备份从 SQL Server 直接备份到 Blob 存储帐户。
将现有备份复制到 Blob 存储帐户
如果你使用的是早期版本的 SQL Server,或者你的环境不支持直接备份到 URL,请像往常一样在 SQL Server 实例上备份,然后将其复制到 Blob 存储。
在 SQL Server 实例上进行备份
将想要迁移到完整恢复模式的数据库设置为允许日志备份。
-- To permit log backups, before the full database backup, modify the database to use the full recovery
USE master
ALTER DATABASE SampleDB
SET RECOVERY FULL
GO
若要手动将数据库完整、差异和日志备份到本地存储,请使用以下示例 T-SQL 脚本。 不需要 CHECKSUM
,但建议使用它,以防止迁移损坏的数据库并加快还原时间。
以下示例将数据库完整备份到本地磁盘:
-- Take full database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
以下示例将数据库差异备份到本地磁盘:
-- Take differential database backup to local disk
BACKUP DATABASE [SampleDB]
TO DISK='C:\BACKUP\SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
以下示例将事务日志备份到本地磁盘:
-- Take transactional log backup to local disk
BACKUP LOG [SampleDB]
TO DISK='C:\BACKUP\SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
GO
将备份复制到 Blob 存储帐户
备份准备就绪后,若想要开始使用 LRS 将数据库迁移到托管实例,可以使用以下方法将现有备份复制到 Blob 存储帐户:
- 下载并安装 AzCopy。
- 下载并安装 Azure 存储资源管理器。
- 使用 Azure 门户中的存储资源管理器。
注意
若要使用同一个 Azure Blob 存储容器迁移多个数据库,请将某个单独数据库的所有备份文件都放入该容器中单独的文件夹中。 为每个数据库文件夹使用平面文件结构。 不支持数据库文件夹内的嵌套文件夹。
直接备份到 Blob 存储帐户
如果你使用的是受支持的 SQL Server 版本(从 SQL Server 2012 SP1 CU2 和 SQL Server 2014 开始),在公司和网络策略允许的情况下,可以使用本机 SQL Server BACKUP TO URL 选项从 SQL Server 直接备份到 Blob 存储帐户。 如果可以使用 BACKUP TO URL
,则无需在本地存储上进行备份然后将其上传到 Blob 存储帐户。
直接本机备份到 Blob 存储帐户时,必须对存储帐户进行身份验证。
使用以下命令创建将 SAS 令牌导入 SQL Server 实例的凭据:
CREATE CREDENTIAL [https://<mystorageaccountname>.blob.core.windows.net/<containername>]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE',
SECRET = '<SAS_TOKEN>';
有关使用 SAS 令牌的详细说明,请查看教程将 Azure Blob 存储与 SQL Server 配合使用。
创建凭据以使用 Blob 存储对 SQL Server 实例进行身份验证后,可以使用 BACKUP TO URL 命令直接备份到存储帐户。 建议启用 CHECKSUM
,但不是必需的。
以下示例将数据库完整备份到 URL:
-- Take a full database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_full.bak'
WITH INIT, COMPRESSION, CHECKSUM
GO
以下示例将数据库差异备份到 URL:
-- Take a differential database backup to a URL
BACKUP DATABASE [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_diff.bak'
WITH DIFFERENTIAL, COMPRESSION, CHECKSUM
GO
以下示例将事务日志备份到 URL:
-- Take a transactional log backup to a URL
BACKUP LOG [SampleDB]
TO URL = 'https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>/SampleDB_log.trn'
WITH COMPRESSION, CHECKSUM
登录到 Azure 并选择订阅
通过以下 PowerShell cmdlet 登录到 Azure:
Login-AzAccount
使用以下 PowerShell cmdlet 选择托管实例所在的订阅:
Select-AzSubscription -SubscriptionId <subscription ID>
开始迁移
通过启动 LRS 开始进行迁移。 你可以在自动完成或连续模式下启动该服务。
当使用自动完成模式时,在最后一个指定的备份文件已还原时,迁移会自动完成。 此选项要求提前提供整个备份链,并将其上传到 Azure Blob 存储帐户。 它不允许在迁移正在进行期间添加新备份文件。 此选项要求 start
命令指定最后一个备份文件的文件名。 对于不需要数据补充的被动工作负载,建议使用此模式。
使用连续模式时,服务会在迁移正在进行期间持续扫描 Azure Blob 存储文件夹并还原添加的任何新备份文件。 迁移仅在请求了手动直接转换后才会完成。 当没有提前提供整个备份链时,以及计划在迁移进行后添加新备份文件时,需要使用连续模式迁移。 对于需要数据补充的活动工作负载,建议使用此模式。
计划在最多 30 天内完成单个 LRS 迁移作业。 此时间到期后,LRS 作业会自动取消。
注意
迁移多个数据库时,每个数据库必须位于其自己的文件夹中。 对于指向 Azure Blob 存储容器的完整 URI 路径和单个数据库文件夹的每个数据库,必须单独启动 LRS。 不支持数据库文件夹内的嵌套文件夹。
在自动完成模式下启动 LRS
确保已将整个备份链上传到 Azure Blob 存储帐户。 此选项不允许在迁移进行期间添加新备份文件。
若要在自动完成模式下启动 LRS,请使用 PowerShell 或 Azure CLI 命令。 使用 -LastBackupName
参数指定最后一个备份文件的名称。 最后一个指定备份文件的还原结束后,服务会自动启动直接转换。
使用 SAS 令牌或托管标识从存储帐户还原数据库。
重要
- 在自动完成模式下启动迁移之前,确保整个备份链已上传到 Azure Blob 存储帐户。 此模式不允许在迁移过程中添加新备份文件。
- 确保正确指定了最后一个备份文件,并且之后未上传更多文件。 如果系统在最后一个指定备份文件后检测到更多备份文件,则迁移会失败。
以下 PowerShell 示例使用 SAS 令牌在自动完成模式下启动 LRS:
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" `
-StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D" `
-AutoCompleteRestore `
-LastBackupName "last_backup.bak"
以下 Azure CLI 示例使用 SAS 令牌在自动完成模式下启动 LRS:
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb -a --last-bn "backup.bak"
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
在连续模式下启动 LRS
确保已将初始备份链上传到 Azure Blob 存储帐户。
重要
在连续模式下启动 LRS 后,你能够将新日志和差异备份添加到存储帐户,直到进行手动直接转换。 启动手动直接转换后,无法添加其他差异文件,也无法还原。
以下 PowerShell 示例使用 SAS 令牌在连续模式下启动 LRS:
Start-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-Collation "SQL_Latin1_General_CP1_CI_AS" -StorageContainerUri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>" `
-StorageContainerSasToken "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
以下 Azure CLI 示例在连续模式下启动 LRS:
az sql midb log-replay start -g mygroup --mi myinstance -n mymanageddb
--storage-uri "https://<mystorageaccountname>.blob.core.windows.net/<containername>/<databasefolder>"
--storage-sas "sv=2019-02-02&ss=b&srt=sco&sp=rl&se=2023-12-02T00:09:14Z&st=2019-11-25T16:09:14Z&spr=https&sig=92kAe4QYmXaht%2Fgjocqwerqwer41s%3D"
编写迁移作业脚本
在连续模式下启动 LRS 的 PowerShell 和 Azure CLI 客户端是同步的。 在此模式下,PowerShell 和 Azure CLI 会在启动作业前等待 API 响应报告作业启动是成功还是失败。
在等待过程中,命令不会将控制权返回给命令提示符。 如果你正在编写迁移体验的脚本,并且需要 LRS start 命令立即交还控制权,以便继续执行脚本的其余部分,则可以使用 -AsJob
开关将 PowerShell 作为后台作业运行。 例如:
$lrsjob = Start-AzSqlInstanceDatabaseLogReplay <required parameters> -AsJob
启动后台作业后,即使后台作业需要较长时间才能完成,系统也会立即返回一个作业对象。 当该作业运行时,你可以继续在此会话中工作而不会发生中断。 有关将 PowerShell 作为后台作业运行的详细信息,请参阅 PowerShell Start-Job 文档。
同样,若要在 Linux 上以后台进程的形式启动 Azure CLI 命令,请在 LRS start 命令末尾使用与号 (&
):
az sql midb log-replay start <required parameters> &
监视迁移进度
Az.SQL 4.0.0 及更高版本提供了详细的进度报告。 查看托管数据库还原详细信息 - 获取以获取示例输出。
若要通过 PowerShell 监视正在进行的迁移进度,请使用以下命令:
Get-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
若要通过 Azure CLI 监视正在进行的迁移进度,请使用以下命令:
az sql midb log-replay show -g mygroup --mi myinstance -n mymanageddb
若要跟踪失败请求的其他详细信息,请使用 PowerShell 命令 Get-AzSqlInstanceOperation 或使用 Azure CLI 命令 az sql mi op show。
停止迁移(可选)
如果需要停止迁移,请使用 PowerShell 或 Azure CLI。 停止迁移会删除托管实例上正在还原的数据库,因此无法恢复迁移。
若要通过 PowerShell 停止迁移过程,请使用以下命令:
Stop-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName"
若要通过 Azure CLI 停止迁移过程,请使用以下命令:
az sql midb log-replay stop -g mygroup --mi myinstance -n mymanageddb
完成迁移(连续模式)
如果在连续模式下启动 LRS,请确保停止了应用程序和 SQL Server 工作负载,以防止生成任何新备份文件。 确保已将 SQL Server 实例中的最后一个备份上传到 Azure Blob 存储帐户。 监视托管实例上的还原进度,确保还原了最后一个日志结尾备份。
在托管实例上还原了最后一个日志结尾备份后,启动手动直接转换以完成迁移。 直接转换结束后,数据库可用于在托管实例上进行读取和写入访问。
若要通过 PowerShell 在 LRS 连续模式下完成迁移过程,请使用以下命令:
Complete-AzSqlInstanceDatabaseLogReplay -ResourceGroupName "ResourceGroup01" `
-InstanceName "ManagedInstance01" `
-Name "ManagedDatabaseName" `
-LastBackupName "last_backup.bak"
若要通过 Azure CLI 在 LRS 连续模式下完成迁移过程,请使用以下命令:
az sql midb log-replay complete -g mygroup --mi myinstance -n mymanageddb --last-backup-name "backup.bak"
限制
使用 LRS 迁移时,请考虑以下限制:
- 在迁移过程完成之前,不能使用正在通过 LRS 还原的数据库。
- 在迁移过程中,正在迁移的数据库不能用于 SQL 托管实例上的只读访问。
- 迁移结束后,迁移过程就终止了,无法通过其他差异备份恢复。
- LRS 仅支持数据库
.bak
、.log
和.diff
文件。 不支持 Dacpac 和 bacpac 文件。 - 必须配置维护时段,在特定日期和时间安排系统更新。 计划在安排的维护时段外运行并完成迁移。
- 在没有
CHECKSUM
的情况下进行的数据库备份:- 可能会迁移损坏的数据库。
- 与启用
CHECKSUM
的数据库备份相比,花费更多时间来还原。
- 必须为整个 Azure Blob 存储容器生成 LRS 使用的共享访问签名 (SAS) 令牌,而且该令牌必须仅具有
Read
和List
权限。 例如,如果授予Read
、List
和Write
权限,则由于额外的Write
权限,LRS 无法启动。 - 不支持通过定义存储访问策略设置权限而创建的 SAS 令牌。 按照本文中的说明手动指定 SAS 令牌的读取和列出权限。
- 必须将不同数据库的备份文件采用平面文件结构放在 Blob 存储帐户上的不同文件夹中。 不支持数据库文件夹内的嵌套文件夹。
- 如果使用的是自动完成模式,则需要在 Blob 存储帐户上提前提供整个备份链。 无法在自动完成模式下添加新备份文件。 如果需要在迁移正在进行期间添加新备份文件,请使用连续模式。
- 必须针对指向包含单个数据库文件夹的完整 URI 路径的每个数据库单独启动 LRS。
- 备份 URI 路径、容器名称或文件夹名称不应包含
backup
或backups
,因为这些是保留关键字。 - 在针对同一存储容器并行启动多个日志重播还原时,请确保为每个还原操作提供相同的有效的 SAS 令牌。
- 对于每个托管实例,LRS 最多可以支持 100 个同时还原过程。
- 单个 LRS 作业最多可以运行 30 天,之后会自动取消。
- 虽然可以在防火墙后使用 Azure 存储帐户,但需要进行额外的配置,并且存储帐户和托管实例必须位于同一区域或两个配对区域中。 有关详细信息,请参阅配置防火墙。
- 可以并行还原的最大数据库数量为每订阅 200 个。 在某些情况下,可通过开具支持票证来增加此限制。
- 上传数千个数据库文件进行还原可能会导致迁移时间过长,甚至失败。 将数据库合并到更少的文件中来加快迁移过程,并确保迁移成功。
注意
如果需要在迁移过程中以只读方式访问数据库,并且执行迁移的时间要长得多,并且停机时间最短,请考虑使用托管实例链接功能作为建议的迁移解决方案。
迁移到“业务关键”服务层级时的限制
迁移到“业务关键”服务层级中的 SQL 托管实例时,请考虑以下限制:
- 迁移大型数据库时,可能会有相当长的停机时间,因为数据库在直接转换后不可用,而数据库会播种到“业务关键”服务层级的次要副本。 有关解决方法,请参阅更长时间的直接转换部分。
- 如果迁移被计划外故障转移、系统更新或安全修补程序中断,迁移会从头开始自动重启,因此很难规划可预测的迁移,而不会造成最后一刻的意外。
重要
这些限制仅适用于迁移到 “业务关键”服务层级的情况,不适用于“常规用途”服务层级的情况。
在“业务关键”服务层级中直接转换耗时更长
如果要迁移到“业务关键”服务层级中的 SQL 托管实例,请考虑到在将数据库播种到次要副本时将数据库联机的延迟。 这尤其适用于大型数据库。
与在“常规用途”服务层级中相比,迁移到“业务关键”服务层级中的 SQL 托管实例耗时更长。 直接转换到 Azure 完成后,数据库将不可用,直到它们从主副本播种到三个次要副本,这可能需要很长时间,具体取决于数据库大小。 数据库越大,播种到次要副本耗时更长,可能需要长达数小时的时间。
如果数据库在直接转换完成后立即可用,请考虑以下解决方法:
- 首先迁移到“常规用途”服务层级,然后在后续维护时段升级到“业务关键”服务层级。 升级服务层级是一项联机操作,它使数据库保持联机状态,直到短暂的故障转移(这是在升级操作的最后一步)。
- 使用托管实例链接联机迁移到“业务关键”实例,而无需等待数据库在直接转换后可用。
排查 LRS 问题
启动 LRS 后,请使用以下任一监视 cmdlet 查看正在进行的操作的状态:
- 对于 PowerShell:
get-azsqlinstancedatabaselogreplay
- 对于 Azure CLI:
az_sql_midb_log_replay_show
若要查看有关失败操作的详细信息,请执行以下操作:
- 对于 PowerShell:Get-AzSqlInstanceOperation
- 对于 Azure CLI:az sql mi op show
如果一段时间后 LRS 无法启动,并且出现错误,请检查最常见的问题:
- 托管实例上的现有数据库是否与你尝试从 SQL Server 实例迁移的数据库具有相同的名称? 可通过重命名其中一个数据库来解决此冲突。
- 授予 SAS 令牌的权限是否只有读取和列出? 授予超出
Read
和List
的权限会导致 LRS 失败。 - 是否在问号 (
?
) 后开始复制用于 LRS 的 SAS 令牌,内容类似于sv=2020-02-10...
? - SAS 令牌的有效时间是否适用于启动和完成迁移的时间范围? 由于用于 SQL 托管实例部署和 SAS 令牌的时区不同,因此可能会出现不匹配的情况。 尝试重新生成 SAS 令牌,并将令牌有效期延长到迁移时间范围的当前日期之前和之后。
- 在针对同一存储容器并行启动多个日志重播还原时,请确保为每个还原操作提供相同的有效的 SAS 令牌。
- 数据库名称、资源组名称和托管实例名称的拼写是否正确?
- 如果在自动完成模式下启动 LRS,是否为最后一个备份文件指定了有效文件名?
- 备份 URI 路径是否包含关键字
backup
或backups
? 重命名使用backup
或backups
的容器或文件夹,因为它们是保留关键字。