将 Azure Cosmos DB 帐户从周期备份模式迁移到连续备份模式
适用于: SQL API
表 API
Gremlin API
Azure Cosmos DB API for MongoDB
可以使用 Azure 门户、CLI、PowerShell 或资源管理器模板,将采用周期模式备份策略的 Azure Cosmos DB 帐户迁移到连续模式。 从定期模式迁移到连续模式是单向迁移,此操作不可逆。 从周期模式迁移到连续模式后,可以利用连续模式的优势。
下面是迁移到连续模式的主要原因:
- 能够使用 Azure 门户、CLI 或 PowerShell 执行自助服务还原。
- 能够对过去 30 天的时间窗口以秒时间粒度还原。
- 能够确保备份在一段时间内在分片或分区键范围内保持一致。
- 能够在删除或修改了容器、数据库或整个帐户时将其还原。
- 能够选择容器、数据库或帐户上的事件,并能够决定何时启动还原。
注意
迁移功能仅限单向,它是不可逆操作。 这意味着,一旦从定期模式迁移到连续模式,就无法切换回定期模式。
仅当满足以下条件时,才能将帐户迁移到连续备份模式: 在迁移你的帐户之前,还要检查时间点还原限制:
- 如果帐户的类型为 SQL API 或是 API for MongoDB。
- 如果帐户的类型为表 API 或 Gremlin API。 这两个 API 为预览版。
- 如果帐户有单个写入区域。
- 如果帐户未启用分析存储。
如果帐户使用的是客户管理的密钥,必须在 Key Vault 访问策略中声明一个用户分配的托管标识,并且必须将它设置为该帐户的默认标识。
权限
若要执行迁移,用户需要对即将迁移的帐户具有 Microsoft.DocumentDB/databaseAccounts/write
权限。
迁移后的定价
将帐户迁移到连续备份模式后,与周期备份模式相比,连续备份模式的成本不同。 连续模式备份成本比周期模式要便宜得多。 要了解更多信息,请参阅连续备份模式定价示例。
使用门户进行迁移
使用以下步骤将帐户从周期备份迁移到连续备份模式:
登录 Azure 门户。
导航到你的 Azure Cosmos DB 帐户,打开“功能”窗格。 选择“连续备份”,然后选择“启用”。
迁移正在进行时,状态显示“挂起”。迁移完成后,状态变为“启用”。迁移时间取决于你帐户中数据的大小。
使用 PowerShell 迁移
安装最新版本的 Azure PowerShell 或高于 6.2.0 的版本。 接下来,执行以下步骤:
连接到 Azure 帐户:
Connect-AzAccount -Environment AzureChinaCloud
将帐户从周期迁移到连续备份模式:
Update-AzCosmosDBAccount ` -ResourceGroupName "myrg" ` -Name "myAccount" ` -BackupPolicyType Continuous
使用 CLI 进行迁移
安装最新版本的 Azure CLI:
- 如果没有 CLI,请安装最新版本的 Azure CLI 或高于 2.26.0 的版本。
- 如果已安装 Azure CLI,请使用
az upgrade
命令升级到最新版本。
登录到 Azure 帐户,并运行以下命令以将帐户迁移到连续模式:
注意
请先运行
az cloud set -n AzureChinaCloud
更改云环境,然后才能在 Azure 中国世纪互联中使用 Azure CLI。 若要切换回 Azure 公有云,请再次运行az cloud set -n AzureCloud
。az login az cosmosdb update -n <myaccount> -g <myresourcegroup> --backup-policy-type continuous
迁移成功完成后,输出显示 backupPolicy 对象的 type 属性设置为 Continuous。
{ "apiProperties": null, "backupPolicy": { "type": "Continuous" }, "capabilities": [], "connectorOffer": null, "consistencyPolicy": { "defaultConsistencyLevel": "Session", "maxIntervalInSeconds": 5, "maxStalenessPrefix": 100 }, … }
检查迁移状态
运行以下命令并检查 backupPolicy 对象的状态、targetType 属性。 迁移开始后,状态会显示为“正在进行”:
az cosmosdb show -n "myAccount" -g "myrg"
迁移完成后,备份类型将更改为“连续”。 运行相同的命令以检查状态:
az cosmosdb show -n "myAccount" -g "myrg"
使用资源管理器模板进行迁移
若要使用 ARM 模板迁移到连续备份模式,请查找模板的 backupPolicy 部分,并更新 type
属性。 例如,如果现有模板具有类似于以下 JSON 对象的备份策略:
"backupPolicy": {
"type": "Periodic",
"periodicModeProperties": {
"backupIntervalInMinutes": 240,
"backupRetentionIntervalInHours": 8
}
},
将其替换为以下 JSON 对象:
"backupPolicy": {
"type": "Continuous"
},
接下来,使用 Azure PowerShell 或 CLI 部署模板。 下面的示例演示如何使用 CLI 命令部署模板:
az group deployment create -g <ResourceGroup> --template-file <ProvisionTemplateFilePath>
迁移期间和迁移后会出现什么情况?
从周期模式迁移到连续模式时,无法运行任何执行帐户级别更新或删除的控制平面操作。 例如,迁移正在进行时,无法运行添加或删除区域、帐户故障转移、更新备份策略等操作。 迁移时间取决于帐户中的数据大小和区域数量。 只有迁移成功完成后,才会成功完成迁移的帐户上的还原操作。
可以在迁移完成后还原帐户。 如果迁移在太平洋标准时间下午 1:00 完成,则可以从太平洋标准时间下午 1:00 开始执行时间点还原。
常见问题
迁移是否只发生在帐户级别?
是的。
哪些帐户可以作为备份迁移的目标?
目前,使用单一写入区域的 SQL API 和 API for MongoDB 帐户,这些帐户已经在整个支持迁移中共享、预配或自动缩放预配。 表 API 和 Gremlin API 为预览版。
启用了分析存储和多写入区域的帐户不支持迁移。
迁移是否需要时间? 一般需要多长时间?
迁移需要时间,具体取决于帐户中的数据大小和区域数量。 可以使用 Azure CLI 或 PowerShell 命令获取迁移状态。 对于数十 TB 数据的大型帐户,迁移可能需要好几天才能完成。
迁移是否会导致任何可用性影响/停机时间?
不会,迁移操作会在后台进行,因此客户端请求不受影响。 但是,我们需要在迁移过程中执行一些后端操作,并且如果帐户负载过大,可能需要更多时间。
如果迁移失败会怎样? 是否仍可以获取周期备份或获取连续备份?
启动迁移过程后,帐户将开始变为连续模式。 如果迁移失败,则必须重新启动迁移,直到成功。
如何还原到迁移之前/期间/之后的时间戳?
假设在 t1 开始迁移并在 t5 完成迁移,则不能使用 t1 和 t5 之间还原时间戳。
若要还原到 t5 后的某个时间,因为帐户现在处于连续模式,可以使用 Azure 门户、CLI 或 PowerShell 执行还原,就像通常使用连续帐户执行的操作一样。 只有在迁移完成后,才能完成这种自助服务还原。
若要还原到 t1 之前的某个时间,可以像往常一样使用周期备份帐户来打开支持票证。 迁移后,最多有 30 天的时间来执行周期还原。 在这 30 天内,可以在迁移前基于帐户的备份保留/间隔进行还原。 例如,如果备份配置在 1 小时间隔内保留 24 个副本,则可以还原到 [t1 - 24 小时] 和 [t1] 之间的任何时间。
迁移期间会阻止哪些帐户级别的控制平面操作?
在迁移期间,会阻止添加/删除区域、故障转移、更改备份策略、导致数据移动的吞吐量更改等操作。
如果迁移由于某种基础问题而失败,那么在重试和成功完成之前,它仍会阻止控制平面操作吗?
失败的迁移不会阻止任何控制平面操作。 如果迁移失败,建议进行重试直至成功,然后再执行任何其他控制平面操作。
能否取消迁移?
迁移是不可逆的操作,因此无法取消。
是否有工具可帮助基于数据使用量和区域数来预估迁移事件?
没有用于预估时间的工具。 不过,我们的缩放运行指出,具有 1 TB 数据的单个区域大约耗时一个半小时。
对于多区域帐户,总数据大小的计算公式是 Number_of_regions * Data_in_single_region
。
由于连续备份模式现已正式发布,是否仍建议先还原帐户副本,并尝试在副本上迁移,然后再决定迁移生产帐户?
建议测试连续备份模式功能,看看它是否按预期工作,然后再迁移生产帐户。 这是因为迁移是单向操作,而且不可逆。
后续步骤
要了解有关连续备份模式的更多信息,请参阅以下文章:
使用 Azure 门户、PowerShell、CLI 或 Azure 资源管理器还原帐户。
尝试为迁移到 Azure Cosmos DB 进行容量计划?
- 若只知道现有数据库群集中的 vcore 和服务器数量,请阅读使用 vCore 或 vCPU 估算请求单位
- 若知道当前数据库工作负载的典型请求速率,请阅读使用 Azure Cosmos DB 容量计划工具估算请求单位