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

将 Azure Cosmos DB 帐户从周期备份模式迁移到连续备份模式

适用对象: NoSQL MongoDB Gremlin

可以使用 Azure 门户CLIPowerShell资源管理器模板,将采用周期模式备份策略的 Azure Cosmos DB 帐户迁移到连续模式。 从周期模式迁移到连续模式是单向迁移,此操作不可逆。 从周期模式迁移到连续模式后,可以利用连续模式的优势。

下面是迁移到连续模式的主要原因:

  • 能够使用 Azure 门户、CLI 或 PowerShell 执行自助服务还原。
  • 能够对过去 30 天或 7 天的时间窗口以秒时间粒度还原。
  • 能够确保备份在一段时间内在分片或分区键范围内保持一致。
  • 能够在删除或修改了容器、数据库或整个帐户时将其还原。
  • 能够选择容器、数据库或帐户上的事件,并能够决定何时启动还原。

注意

迁移功能仅限单向,它是不可逆操作。 这意味着,一旦从周期性模式迁移到连续模式,就无法切换回周期模式。

只有在满足以下条件时,才能将帐户迁移到连续备份模式。 在迁移你的帐户之前,还要检查时间点还原限制

  • 如果帐户类型为 API for NoSQL、API for Table、Gremlin 或 API for MongoDB。
  • 如果帐户有单个写入区域。
  • 如果帐户未启用分析存储。

如果帐户使用的是客户管理的密钥,则必须在 Key Vault 访问策略中声明一个托管标识(系统分配的或用户分配的),并且必须将它设置为该帐户的默认标识。

权限

若要执行迁移,用户需要对即将迁移的帐户具有 Microsoft.DocumentDB/databaseAccounts/write 权限。

迁移后的定价

将帐户迁移到连续备份模式后,与定期备份模式相比,成本可能会发生变化。 30 天与 7 天的层级选择也会对备份成本产生影响。 若要了解详情,请参阅连续备份模式定价

使用门户进行迁移

使用以下步骤将帐户从周期备份迁移到连续备份模式:

  1. 登录 Azure 门户

  2. 导航到你的 Azure Cosmos DB 帐户,打开“备份和还原”窗格。 选择“备份策略”选项卡,然后选择“更改”。 选择目标连续模式后,选择“保存”。

    Migrate to continuous mode using Azure portal

  3. 在迁移进行期间,弹出窗口显示“正在更新备份策略设置”。 如果选择该通知,可能会在帐户级别看到“正在更新”,在帐户概述上看到备份策略显示“正在迁移”。 完成后,备份策略会切换到所选的连续模式层。 迁移时间取决于用户帐户中的数据大小。

    Check the status of migration from Azure portal

使用 PowerShell 迁移

  1. 安装最新版本的 Azure PowerShell 或任何高于 6.2.0 的版本。

  2. 若要使用 Continous7Days 模式进行预配或迁移,必须使用 cosmosdb 扩展的预览版。 使用 Install-Module -Name Az.CosmosDB -AllowPrerelease

  3. 接下来,执行以下步骤:

    1. 连接到 Azure 帐户:

      Connect-AzAccount
      
    2. 使用 continuous30days 层或 continuous7days 天将帐户从周期备份模式迁移到连续备份模式。 如果未提供层值,则假定为 continuous30days

      Update-AzCosmosDBAccount ` 
         -ResourceGroupName "myrg" ` 
         -Name "myAccount" `
         -BackupPolicyType "Continuous"
      
         Update-AzCosmosDBAccount ` 
         -ResourceGroupName "myrg" ` 
         -Name "myAccount" `
         -BackupPolicyType "Continuous" `
         -ContinuousTier "Continuous7Days"
      

使用 CLI 进行迁移

  1. 安装最新版本的 Azure CLI:
  • 如果尚未安装 Azure CLI,请参阅安装 Azure CLI。 或者,也可以在 Azure 门户中使用 Azure Cloud Shell。
  1. 登录到 Azure 帐户,并运行以下命令以将帐户迁移到连续模式:

    az login
    
  2. 将帐户迁移到 continuous30dayscontinuous7days 层。 如果未提供层值,则假定为 continuous30days

    az cosmosdb update -n <myaccount> -g <myresourcegroup> --backup-policy-type continuous
    
    az cosmosdb update -g "my-rg" -n "my-continuous-backup-account" --backup-policy-type "Continuous" --continuous-tier "Continuous7Days"
    
  3. 迁移成功完成后,输出显示 backupPolicy 对象,其中包含值为 Continuoustype 属性。

     {
       "apiProperties": null,
       "backupPolicy": {
            "continuousModeProperties": {
                    "tier": "Continuous7Days"
            },
            "migrationState": null,
            "type": "Continuous"
       },
          …
     }
    

检查迁移状态

运行以下命令并检查 backupPolicy 对象的状态和targetType 属性。 迁移开始后,状态会显示为“正在进行”:

az cosmosdb show -n "myAccount" -g "myrg"

Check the migration status using PowerShell command

迁移完成后,备份类型将更改为“连续”,并显示所选层级。 如果未提供层级,则层级将设置为 Continuous30Days。 运行相同的命令以检查状态:

az cosmosdb show -n "myAccount" -g "myrg"

Backup type changes to continuous after the migration is complete

使用资源管理器模板从周期性模式迁移到连续模式

若要使用 ARM 模板迁移到连续备份模式,请查找模板的 backupPolicy 部分,并更新 type 属性。 例如,如果现有模板具有类似于以下 JSON 对象的备份策略:

"backupPolicy": {
   "type": "Periodic",
   "periodicModeProperties": {
   "backupIntervalInMinutes": 240,
   "backupRetentionIntervalInHours": 8
   }
}

将其替换为以下 JSON 对象:

"backupPolicy": { 
   "type": "Continuous", 
   "continuousModeProperties": { 
      "tier": "Continuous7Days" 
    } 
} 

接下来,使用 Azure PowerShell 或 CLI 部署模板。 下面的示例演示如何使用 CLI 命令部署模板:

az deployment group create -g <ResourceGroup> --template-file <ProvisionTemplateFilePath>

更改连续模式层

可以在 Azure PowerShell、Azure CLI 或 Azure 门户中在 Continuous30DaysContinous7Days 之间切换。

在给定 Azure Cosmos DB 帐户的门户中,选择“时间点还原”窗格,然后选择备份策略模式旁边的“更改”链接,显示“连续(30 天)”或“连续(7 天)”对应的选项。 选择所需的目标,然后选择“保存”。

Screenshot of dialog to select tier of continuous mode.

以下 Azure CLI 命令演示如何将现有帐户切换到 Continous7Days

az cosmosdb update \ 
    --resource-group "my-rg" \ 
    --name "my-continuous-backup-account" \ 
    --backup-policy-type "Continuous" \ 
    --continuous-tier "Continuous7Days" 

以下 Azure PowerShell 命令演示如何将现有帐户切换到 Continous7Days

Update-AzCosmosDBAccount ` 
    -ResourceGroupName "myrg" ` 
    -Name "myAccount" `
    -BackupPolicyType Continuous `
    -ContinuousTier Continuous7Days

还可以通过类似于使用 Azure CLI 和 Azure PowerShell 的方法使用 ARM 模板。

注意

从 30 天层更改为 7 天层后,还原超过 7 天的历史记录的功能将立即不可用。 从 7 天层更改为 30 天层后,将无法立即还原超过 7 天的历史记录。 可以通过 Azure Powershell 或 Azure CLI 从可用的帐户元数据中提取最早的还原时间。 在 7 天层和 30 天层之间切换的价格影响也将立即可见。

迁移期间和迁移后会出现什么情况?

从周期模式迁移到连续模式时,无法运行任何执行帐户级别更新或删除的控制平面操作。 例如,迁移正在进行时,无法运行添加或删除区域、帐户故障转移、更新备份策略等操作。 迁移时间取决于帐户中的数据大小和区域数量。 只有迁移成功完成后,才会成功完成迁移的帐户上的还原操作。

可以在迁移完成后还原帐户。 如果迁移在太平洋标准时间下午 1:00 完成,则可以从太平洋标准时间下午 1:00 开始执行时间点还原。

常见问题

迁移是否只发生在帐户级别?

是的。

哪些帐户可以作为备份迁移的目标?

目前,具有单一写入区域且已共享、预配或自动预配吞吐量的 API for NoSQL、API for Table、Gremlin API 和 API for MongoDB 帐户支持迁移。

启用了分析存储和多写入区域的帐户不支持迁移。

迁移是否需要时间? 一般需要多长时间?

迁移需要不同的时间,这在很大程度上取决于帐户中的数据大小和区域数量。 可以使用 Azure CLI 或 PowerShell 命令获取迁移状态。 对于数十 TB 数据的大型帐户,迁移可能需要好几天才能完成。

迁移是否会导致任何可用性影响/停机时间?

不会,迁移操作会在后台进行。 因此,客户端请求不受影响。 但是,我们需要在迁移过程中执行一些后端操作,并且如果帐户负载过大,可能需要更多时间。

如果迁移失败会怎样? 是否仍可以获取周期备份或获取连续备份?

启动迁移过程后,帐户将启用连续模式。 如果迁移失败,则必须重新启动迁移,直到成功。

如何还原到迁移之前/期间/之后的时间戳?

假设在 t1 开始迁移并在 t5 完成迁移,则不能在 t1t5 之间使用还原时间戳。

另假设你的帐户现在处于连续模式。 若要还原到 t5 之后的某个时间,请使用 Azure 门户、CLI 或 PowerShell 执行还原,就像往常使用连续帐户执行的操作一样。 只有在迁移完成后,才能完成这种自助服务还原。

若要还原到 t1 之前的时间,可以像往常使用周期备份帐户一样,创建支持工单。 迁移后,最多有 30 天的时间来执行周期还原。 在这 30 天内,可以在迁移前基于帐户的备份保留/间隔进行还原。 例如,如果备份配置为每隔 1 小时保留 24 个副本,则可以还原到 (t1 – 24 hours)t1 之间的任何时间。

迁移期间会阻止哪些帐户级别的控制平面操作?

在迁移期间,会阻止添加/删除区域、故障转移、更改备份策略、导致数据移动的任何吞吐量更改等操作。

如果迁移由于某种基础问题而失败,那么在重试和成功完成之前,它仍会阻止控制平面操作吗?

失败的迁移不会阻止任何控制平面操作。 如果迁移失败,建议进行重试直至成功,然后再执行任何其他控制平面操作。

能否取消迁移?

迁移是不可逆的操作,因此无法取消。

是否有工具可帮助基于数据使用量和区域数来预估迁移事件?

没有用于预估时间的工具。 我们的测试和缩放运行表明,具有 1 TB 数据的单个区域帐户大约需要 90 分钟。

对于多区域帐户,总数据大小的计算公式是 Number_of_regions * Data_in_single_region

由于连续备份模式现已正式发布,是否仍建议还原帐户副本? 是否建议先尝试在副本上迁移,然后再决定迁移生产帐户?

建议测试连续备份模式功能,看看它是否按预期工作,然后再迁移生产帐户。 迁移是单向操作,而且不可逆。

后续步骤

要了解有关连续备份模式的更多信息,请参阅以下文章: