将资源移动到新区域 - Azure SQL 数据库
适用于:Azure SQL 数据库
本文介绍讲解将数据库或弹性池迁移到新区域的一般工作流。
注意
若要将数据库和弹性池移动到不同的 Azure 区域,还可以使用推荐的 Azure 资源转移器。
概述
在多种情况下,可能需要将现有数据库或池从一个区域移到另一个区域。 例如,你要将业务拓展到新的区域,并希望根据新的客户群对业务进行优化。 或者出于合规性原因,需要将运营部门转移到另一个区域。 或者,Azure 开通了距离更近、可改善客户体验的新区域。
将资源移到不同区域的常规工作流包括以下步骤:
- 检查是否符合移动的先决条件。
- 准备在范围内移动资源。
- 监视准备过程。
- 测试移动过程。
- 启动实际移动。
验证移动数据库的先决条件
- 为每个源服务器创建目标服务器。
- 使用 PowerShell 配置包含适当例外项的防火墙。
- 使用适当的登录名配置两个服务器。 如果你不是订阅管理员或 SQL 服务器管理员,请让管理员为你分配所需的权限。 有关详细信息,请参阅灾难恢复后如何管理 Azure SQL 数据库安全性。
- 如果你的数据库已通过透明数据加密 (TDE) 进行加密并使用 Azure Key Vault 中你自己的加密密钥(BYOK 或客户管理的密钥),请确保在目标区域中预配正确的加密材料。
- 为此,最简单的方法是将现有密钥保管库中的加密密钥(在源服务器上用作 TDE 保护器)添加到目标服务器,然后将该密钥设置为目标服务器上的 TDE 保护器,因为一个区域中的服务器现在可以连接到任何其他区域中的密钥保管库。
- 为了确保目标服务器能够访问旧加密密钥(还原数据库备份时需要用到),最佳做法在源服务器上运行 Get-AzSqlServerKeyVaultKey cmdlet 以返回可用密钥列表,然后将这些密钥添加到目标服务器。
- 有关在目标服务器上配置客户管理的 TDE 的详细信息和最佳做法,请参阅使用 Azure Key Vault 中客户管理的密钥进行 Azure SQL 透明数据加密。
- 若要将密钥保管库移到新区域,请参阅跨区域移动 Azure Key Vault。
- 如果启用了数据库级审核,请将其禁用,并改为启用服务器级审核。 故障转移后,数据库级审核需要跨区域的流量,而在移动后,这种情况是不适当的或者无法实现的。
- 对于服务器级审核,请确保:
- 已将包含现有审核日志的存储容器、Log Analytics 或事件中心移到目标区域。
- 已在目标服务器上配置审核。 有关详细信息,请参阅 SQL 数据库审核入门。
- 如果实例具有长期保留策略 (LTR),则现有的 LTR 备份与当前服务器保持关联。 由于目标服务器不同,因此可以使用源服务器访问源区域中的旧 LTR 备份,即使删除了该服务器,也是如此。
注意
不支持在区域之间迁移具有现有 LTR 备份的数据库,因为这需要将 LTR 备份移动到目标服务器,而这在目前无法实现。
准备资源
- 在源的服务器与目标的服务器之间创建一个故障转移组。
- 将要移动的数据库添加到该故障转移组中。 系统自动启动所有已添加的数据库的复制。 有关详细信息,请参阅将故障转移组与 SQL 数据库配合使用。
监视准备过程
可以定期调用 Get-AzSqlDatabaseFailoverGroup 来监视数据库从源到目标服务器的复制。 Get-AzSqlDatabaseFailoverGroup
的输出对象包含 ReplicationState 的属性:
- ReplicationState = 2 (CATCH_UP) 表示数据库已同步,可以安全故障转移。
- ReplicationState = 0 (SEEDING) 表示数据库尚未设定种子,尝试故障转移会失败。
测试同步
“ReplicationState”变为 2
后,使用辅助终结点 <fog-name>.secondary.database.chinacloudapi.cn
连接到每个数据库或数据库子集,并对数据库执行任何查询,以确保连接、安全性配置和数据复制正常。
启动移动
- 使用辅助终结点
<fog-name>.secondary.database.chinacloudapi.cn
连接到目标服务器。 - 在完全同步的情况下,使用 Switch-AzSqlDatabaseFailoverGroup 将辅助服务器切换为主托管实例。 此操作将会成功或者回滚。
- 使用
nslook up <fog-name>.secondary.database.chinacloudapi.cn
验证该命令是否已成功完成,确定 DNS CNAME 条目指向目标区域的 IP 地址。 如果 switch 命令失败,不会更新 CNAME。
删除源数据库
移动操作完成后,删除源区域中的资源以避免产生不必要的费用。
- 使用 Remove-AzSqlDatabaseFailoverGroup 删除故障转移组。
- 使用 Remove-AzSqlDatabase 删除源服务器上每个数据库的每个源数据库。 这会自动终止异地复制链接。
- 使用 Remove-AzSqlServer 删除源服务器。
- 删除密钥保管库、审核存储容器、事件中心、Microsoft Entra 租户和其他相关资源,以停止为其计费。
验证移动池的先决条件
- 为每个源服务器创建目标服务器。
- 使用 PowerShell 配置包含适当例外项的防火墙。
- 使用适当的登录名配置服务器。 如果你不是订阅管理员或服务器管理员,请让管理员为你分配所需的权限。 有关详细信息,请参阅灾难恢复后如何管理 Azure SQL 数据库安全性。
- 如果数据库已通过透明数据加密进行加密并使用 Azure Key Vault 中你自己的加密密钥,请确保在目标区域中预配正确的加密材料。
- 为每个源弹性池创建一个目标弹性池,并确保在同一个服务层级中创建具有相同名称和相同大小的池。
- 如果启用了数据库级审核,请将其禁用,并改为启用服务器级审核。 故障转移后,数据库级审核需要跨区域的流量,而在移动后,这种情况是不适当的或者无法实现的。
- 对于服务器级审核,请确保:
- 已将包含现有审核日志的存储容器、Log Analytics 或事件中心移到目标区域。
- 已在目标服务器上配置审核。 有关详细信息,请参阅 SQL 数据库审核。
- 如果实例具有长期保留策略 (LTR),则现有的 LTR 备份与当前服务器保持关联。 由于目标服务器不同,因此可以使用源服务器访问源区域中的旧 LTR 备份,即使删除了该服务器,也是如此。
注意
不支持在区域之间迁移具有现有 LTR 备份的数据库,因为这需要将 LTR 备份移动到目标服务器,而这在目前无法实现。
准备移动
在源服务器上的每个弹性池及其在目标服务器上的对应弹性池之间单独创建一个故障转移组。
将池中的所有数据库添加到该故障转移组中。 系统自动启动已添加的数据库的复制。 有关详细信息,请参阅将故障转移组与 SQL 数据库配合使用。
注意
尽管可以创建包含多个弹性池的故障转移组,但我们强烈建议为每个池单独创建一个故障转移组。 如果需要在多个弹性池之间移动大量的数据库,可以同时运行准备步骤,并同时启动移动步骤。 与在同一故障转移组中包含多个弹性池相比,此过程的伸缩性更好,并且所需的时间更少。
监视准备过程
可以定期调用 Get-AzSqlDatabaseFailoverGroup 来监视数据库从源到目标的复制。 Get-AzSqlDatabaseFailoverGroup
的输出对象包含 ReplicationState 的属性:
- ReplicationState = 2 (CATCH_UP) 表示数据库已同步,可以安全故障转移。
- ReplicationState = 0 (SEEDING) 表示数据库尚未设定种子,尝试故障转移会失败。
测试同步
“ReplicationState”变为 2
后,使用辅助终结点 <fog-name>.secondary.database.chinacloudapi.cn
连接到每个数据库或数据库子集,并对数据库执行任何查询,以确保连接、安全性配置和数据复制正常。
启动移动
- 使用辅助终结点
<fog-name>.secondary.database.chinacloudapi.cn
连接到目标服务器。 - 在完全同步的情况下,使用 Switch-AzSqlDatabaseFailoverGroup 将辅助服务器切换为主托管实例。 此操作要么成功,要么回滚。
- 使用
nslook up <fog-name>.secondary.database.chinacloudapi.cn
验证该命令是否已成功完成,确定 DNS CNAME 条目指向目标区域的 IP 地址。 如果 switch 命令失败,不会更新 CNAME。
删除源弹性池
移动操作完成后,删除源区域中的资源以避免产生不必要的费用。
- 使用 Remove-AzSqlDatabaseFailoverGroup 删除故障转移组。
- 使用 Remove-AzSqlElasticPool 删除源服务器上的每个源弹性池。
- 使用 Remove-AzSqlServer 删除源服务器。
- 删除密钥保管库、审核存储容器、事件中心、Microsoft Entra 租户和其他相关资源,以停止为其计费。