使用 Azure SQL 托管实例的日志重播服务的概述
适用于：
Azure SQL 托管实例
本文概述了日志重播服务 (LRS)，可用于将数据库从 SQL Server 迁移到 Azure SQL 托管实例。 LRS 是适用于 Azure SQL 托管实例的免费云服务，并且基于 SQL Server 日志传送技术。
由于 LRS 还原标准 SQL Server 备份文件，因此可以使用它从托管在任何位置（本地或任何云）的 SQL Server 迁移到 Azure SQL 托管实例。
若要使用 LRS 开始进行迁移，请查看使用日志重放服务迁移数据库。
何时使用日志重播服务
Azure 数据库迁移服务和 LRS 使用相同的基础迁移技术和相同的 API。 LRS 进一步在本地 SQL Server 实例与 SQL 托管实例部署之间实现复杂的自定义迁移和混合体系结构。
当你不能使用 Azure 数据库迁移服务进行迁移时，可以直接将 LRS 与 PowerShell、Azure CLI cmdlet 或 API 结合使用，手动构建和编排到 SQL 托管实例的数据库迁移。
在以下情况下，可以考虑使用 LRS：
- 需要加强对数据库迁移项目的控制。
- 在迁移直接转换期间几乎不能容许停机。
- 无法在环境中安装数据库迁移服务可执行文件。
- 数据库迁移服务可执行文件无权访问你的数据库备份。
- 无法访问主机操作系统，或者没有管理员特权。
- 不能将环境中的网络端口打开到 Azure。
- 你的环境中存在带宽限制或代理阻塞性问题。
- 备份通过
TO URL选项直接存储到 Azure Blob 存储帐户中。 - 需要使用差异备份。
由于 LRS 的工作原理是还原标准的 SQL Server 备份文件，因此它应支持从任何源迁移。 已测试以下各个源：
- 本地 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)
- Alibaba Cloud RDS for SQL Server
如果遇到从未列出的源迁移的意外问题，请开立支持票证以获取帮助。
注意
- 建议使用数据库迁移服务自动将数据库从 SQL Server 迁移到 Azure SQL 托管实例。 如果数据库迁移服务不完全支持你的方案，请考虑使用 LRS 协调迁移。
- LRS 是在托管实例上还原差异备份的唯一方法。 无法在托管实例上手动还原差异备份，也无法使用 T-SQL 手动设置
NORECOVERY模式。
LRS 的工作原理
使用 LRS 生成将数据库迁移到云的自定义解决方案时，需要执行此部分后面的图和表中所示的几个编排步骤。
迁移包括在 SQL Server 上进行数据库备份，并将备份文件复制到 Azure Blob 存储帐户。 支持完整备份、日志备份和差异备份。 然后使用 LRS 云服务将备份文件从 Azure Blob 存储帐户还原到 SQL 托管实例。 Blob 存储帐户用作 SQL Server 与 SQL 托管实例之间的备份文件的中间存储。
LRS 监视 Blob 存储帐户中是否有在还原完整备份后添加的任何新的差异备份或日志备份。 然后，LRS 会自动还原这些新文件。 你可以使用该服务监视在 SQL 托管实例上还原备份文件的进度，并且可以在必要时停止该过程。
对于备份文件，LRS 不需要特定的命名约定。 它扫描放置在 Azure Blob 存储帐户中的所有文件，并仅从读取文件头构建备份链。 在迁移过程中，数据库处于“正在还原”状态。 数据库以 NORECOVERY 模式还原，因此在迁移过程完成之前，不能将它们用于读取或写入。
如果要迁移多个数据库，则需要：
- 采用平面文件结构在 Blob 存储帐户上将每个数据库的备份文件放入一个单独文件夹。 例如，使用单独的数据库文件夹：blobcontainer/database1/files、blobcontainer/database2/files 等。
- 请勿在数据库文件夹中使用嵌套文件夹，因为嵌套文件夹结构不受支持。 例如，请勿使用 blobcontainer/database1/subfolder/files 等子文件夹。
- 为每个数据库单独启动 LRS。
- 指定不同的 URI 路径，在 Blob 存储帐户上将数据库文件夹分隔开来。
虽然不需要为备份启用 CHECKSUM，但我们强烈建议启用它。 若不启用 CHECKSUM，还原数据库将花费更长的时间，因为 SQL 托管实例会在未启用 CHECKSUM 的情况下对还原的备份执行完整性检查。
有关详细信息，请参阅使用日志重播服务将数据库从 SQL Server 迁移到 SQL 托管实例。
注意
强烈推荐在启用了 CHECKSUM 的情况下在 SQL Server 上执行备份，这是因为若没有它，那么在将损坏的数据库还原到 Azure 存在风险。
自动完成与连续模式迁移
你可以在自动完成或连续模式下启动 LRS。
当提前生成了整个备份链时，以及未计划在迁移启动后添加任何更多文件时，可使用自动完成模式。 对于不需要数据补充的被动工作负载，建议使用此迁移模式。 将所有备份文件上传到 Blob 存储帐户，然后启动自动完成模式迁移。 已还原最后一个指定备份文件时，迁移会自动完成。 迁移后的数据库可用于在 SQL 托管实例上进行读取/写入访问。
如果计划在迁移进行期间继续添加新备份文件，请使用连续模式。 对于需要数据补充的活动工作负载，建议使用此模式。 将当前可用的备份链上传到 Blob 存储帐户，以连续模式启动迁移，并根据需要继续从工作负载添加新备份文件。 系统会定期扫描 Azure Blob 存储文件夹并还原找到的任何新日志或差异备份文件。
准备好进行直接转换后，停止 SQL Server 实例上的工作负载，生成最后一个备份文件，然后将其上传。 通过验证最终日志结尾备份在 SQL 托管实例上显示为“已还原”，来确保最后一个备份文件已还原。 然后，启动手动直接转换。 最后的直接转换步骤会使数据库联机并可在 SQL 托管实例上用于读取/写入访问。
通过自动完成模式自动停止 LRS 或通过直接转换手动停止 LRS 后，无法为 SQL 托管实例上已联机的数据库恢复还原过程。 例如，迁移完成后，将无法再为联机数据库还原更多差异备份。 要在迁移完成后还原更多备份文件，需要从托管实例中删除数据库并从头重新开始迁移。
迁移工作流
典型迁移工作流如下图所示，步骤在表中进行了概述。
仅当所有备份链文件都提前可用时，才需要使用自动完成模式。 对于不需要数据补充的被动工作负载，建议使用此模式。
当没有提前提供整个备份链时，以及计划在迁移进行后添加新备份文件时，请使用连续模式迁移。 对于需要数据补充的活动工作负载，建议使用此模式。
| 操作 | 详细信息 |
|---|---|
| 1. 将数据库备份从 SQL Server 实例复制到 Blob 存储帐户。 | 使用 AzCopy 或 Azure 存储资源管理器将完整备份、差异备份和日志备份从 SQL Server 实例复制到 Blob 存储容器。 使用任意文件名。 LRS 不需要特定的文件命名约定。 迁移多个数据库时，为每个数据库使用单独的文件夹。 |
| 2.在云中启动 LRS。 | 可以使用 PowerShell (start-azsqlinstancedatabaselogreplay) 或 Azure CLI (az_sql_midb_log_replay_start cmdlet) 启动服务。 在自动完成或连续迁移模式之间进行选择。 为指向 Blob 存储帐户上的备份文件夹的每个数据库单独启动 LRS。 服务启动后，它将从 Blob 存储容器中获取备份，并开始将它们还原到 SQL 托管实例。 在自动完成模式下启动 LRS 时，它会还原所有备份，直到指定的最后一个备份文件。 所有备份文件都必须提前上传，在迁移正在进行期间无法添加新备份文件。 对于不需要数据补充的被动工作负载，建议使用此模式。 在连续模式下启动 LRS 时，它会还原最初上传的所有备份，然后监视上传到文件夹的任何新文件。 该服务将根据日志序列号 (LSN) 链连续应用日志，直到手动停止运行。 对于需要数据补充的活动工作负载，建议使用此模式。 |
| 2.1. 监视操作进度。 | 可以使用 PowerShell (get-azsqlinstancedatabaselogreplay) 或 Azure CLI (az_sql_midb_log_replay_show cmdlet) 监控正在进行的还原操作的进度。 若要跟踪失败请求的其他详细信息，请使用 PowerShell 命令 Get-AzSqlInstanceOperation 或使用 Azure CLI 命令 az sql mi op show。 |
| 2.2. 在需要时可停止操作（可选）。 | 如果需要停止迁移过程，请使用 PowerShell (stop-azsqlinstancedatabaselogreplay) 或 Azure CLI (az_sql_midb_log_replay_stop)。 停止操作会删除正在还原到 SQL 托管实例的数据库。 停止操作后，将无法为数据库恢复 LRS。 你需要从头开始重启迁移过程。 |
| 3.准备就绪后，直接转换到云。 | 如果 LRS 在自动完成模式下启动，则在还原了指定的最后一个备份文件后，迁移会自动完成。 如果 LRS 在连续模式下启动，则停止应用程序和工作负载。 获取最后一个日志结尾备份，并将其上传到 Azure Blob 存储部署。 确保在托管实例上还原了最后一个日志结尾备份。 通过使用 PowerShell (complete-azsqlinstancedatabaselogreplay) 或 Azure CLI az_sql_midb_log_replay_complete 启动 LRS complete 操作来完成直接转换。 此操作会停止 LRS 并使数据库联机，以便在 SQL 托管实例上执行读取/写入工作负载。 将应用程序连接字符串从 SQL Server 实例重新指向 SQL 托管实例。 你需要通过在应用程序中手动或自动（例如，在应用程序可从属性或数据库中读取连接字符串的情况下）更改连接字符串来自行安排此步骤。 |
重要
交接后，具有业务关键服务层的 SQL 托管实例只能用比具有常规用途服务层的 SQL 托管实例更长的时间才能使用，因为必须为可用性组设定三个辅助副本的种子。 操作持续时间取决于数据的大小。 有关详细信息，请参阅管理操作持续时间。
迁移大型数据库
如果迁移数 TB 大小的大型数据库，请考虑以下事项：
- 单个 LRS 作业最多可以运行 30 天。 此期限到期后，作业会自动取消。
- 对于长时间运行的作业，系统更新会中断并延长迁移作业。 强烈建议使用维护时段来安排计划内系统更新。 围绕安排的维护时段规划迁移。
- 系统更新中断的迁移作业对于常规用途托管实例会自动暂停并恢复，对于业务关键托管实例会重启。 这些更新会影响迁移的时间范围。
- 若要提高将 SQL Server 备份文件上传到 Blob 存储帐户的速度，如果基础结构有足够的网络带宽，请考虑将并行化与多个线程配合使用。
开始迁移
通过启动 LRS 开始进行迁移。 你可以在自动完成或连续模式下启动该服务。 有关具体的详细信息，请查看使用 LRS 进行迁移。
自动完成模式。 当使用自动完成模式时，在最后一个指定的备份文件已还原时，迁移会自动完成。 此选项：
- 要求提前提供整个备份链，并将其上传到 Azure Blob 存储帐户。
- 不允许在迁移正在进行期间添加新备份文件。
- 要求 start 命令指定最后一个备份文件的文件名。
对于不需要数据补充的被动工作负载，建议使用自动完成模式。
连续模式。 使用连续模式时，服务会在迁移进行期间持续扫描 Azure Blob 存储文件夹并还原添加的任何新备份文件。
迁移仅在请求了手动直接转换后才会完成。
当没有提前提供整个备份链时，以及计划在迁移进行后添加新备份文件时，需要使用连续模式迁移。
对于需要数据补充的活动工作负载，建议使用连续模式。
计划在最多 30 天内完成单个 LRS 迁移作业。 此期限到期后，LRS 作业会自动取消。
注意
迁移多个数据库时，每个数据库必须位于其自己的文件夹中。 对于指向 Azure Blob 存储容器的完整 URI 路径和单个数据库文件夹的每个数据库，必须单独启动 LRS。 不支持数据库文件夹内的嵌套文件夹。
LRS 的限制
有关信息，请查看使用 LRS 时的限制。
后续步骤
有关详细信息，请参阅使用日志重播服务将数据库从 SQL Server 迁移到 SQL 托管实例。
详细了解如何使用链接功能将数据库迁移到 SQL 托管实例。