Compartir a través de

将 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。
  • 如果帐户有单个写入区域。
  • 如果帐户从未为容器禁用 Synapse Link。

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

权限

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

迁移后的定价

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

使用门户进行迁移

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

  1. 登录 Azure 门户

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

    使用 Azure 门户迁移到连续模式

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

    从 Azure 门户中检查迁移状态

使用 PowerShell 迁移

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

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

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

    1. 连接到 Azure 帐户:

      Connect-AzAccount -Environment AzureChinaCloud
      
    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 CLI 或任何高于 2.26.0 的版本。

    • 如果已安装 Azure CLI,请使用 az upgrade 命令升级到最新版本。

    • 若要使用 Continous7Days 模式进行预配或迁移,必须使用 cosmosdb 扩展的预览版。 使用 az extension update --name cosmosdb-preview 管理扩展。

  2. 登录到 Azure 帐户,并运行以下命令以将帐户迁移到连续模式:

    az login
    
  3. 将帐户迁移到 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"
    
  4. 迁移成功完成后,输出显示 backupPolicy 对象,其中包含值为 Continuoustype 属性。

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

检查迁移状态

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

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

使用 PowerShell 命令检查迁移状态

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

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

迁移完成后,备份类型将更改为“连续”

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

若要使用 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 天)”对应的选项。 选择所需的目标,然后选择“保存”。

该屏幕截图显示用于选择连续模式层的对话框。

以下 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 帐户支持迁移。

启用了多写入区域的帐户不支持迁移。

目前,启用了 Synapse Link 的帐户已为一个或多个集合禁用 Synapse Link,无法迁移到连续备份。

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

迁移需要不同的时间,这在很大程度上取决于帐户中的数据大小和区域数量。 可以使用 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

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

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

后续步骤

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