备份和还原

概览

借助 Cloud Spanner 备份和恢复功能,您可以按需创建 Cloud Spanner 数据库备份,以及恢复数据库,以防止因操作和应用错误导致逻辑数据损坏。备份具有高可用性,经过加密,可在创建后保留长达一年的时间。如果您需要更长的保留时间,我们建议您导出数据库

您可以通过以下方式使用“备份和恢复”:

对于逻辑数据损坏,Cloud Spanner 还提供了时间点恢复

主要特性

  • 数据一致性:备份为 version_time 备份中具有事务一致性和外部一致性的 Cloud Spanner 数据库副本。

  • 复制:备份与源数据库位于同一实例中,并在同一地理位置进行复制。对于区域实例,三个读写地区各自都存储有备份副本。对于多区域实例,副本存储在包含读写副本或只读副本的所有地区中。

  • 自动到期:所有备份都有一个用户指定的失效日期,用于确定何时自动删除该备份。

选择“备份与恢复”或“导入与导出”

Cloud Spanner 的导入导出功能与备份和恢复一样服务类似用例。下表介绍了它们之间的相似之处和不同之处,帮助您确定要使用哪一个。

备份和还原导入和导出
数据一致性 备份和导出的数据库具有事务一致性和外部一致性。
性能影响 两者都以低优先级运行,以最大限度地减少对数据库性能的影响。导出使用低优先级用户 CPU,而备份使用。如需了解详情,请参阅任务优先级
存储格式 使用专为快速恢复设计的专有加密格式。 支持 CSV 和 Avro 文件格式。
可移植性 备份与源数据库位于同一实例中,且无法移动。

您可以将数据库恢复到项目中与备份具有相同实例配置的任何实例。
导出的数据库位于 Google Cloud Storage,并且数据可以迁移到支持 CSV 或 Avro 的任何系统。
保留 备份最多可保留 1 年。 导出的数据库存储在 Cloud Storage 中,默认情况下,这些数据库会保留在此处,直到删除为止。您可以自定义生命周期保留政策。
结算 系统会根据每单位时间使用的存储空间向您的 Cloud Spanner 项目收取备份费用。如需了解详情,请参阅结算部分。 使用 Google Cloud StorageDataflow 时,导入和导出的结算更加复杂。如需了解详情,请参阅数据库导出和导入价格
恢复时间 恢复操作分为两种:恢复和优化。恢复操作提供快速首字节时间,因为数据库直接装载备份而不复制数据。恢复操作完成后,数据库便可以使用,但在优化过程中,读取延迟可能会略高。如需了解详情,请参阅恢复的工作原理 导入速度较慢。您需要等待所有数据写入数据库。

备份的工作原理

目录

用户可以创建任何 Cloud Spanner 数据库的备份。这些备份是完整的,从某种意义上说,它们包含备份的 version_time 中数据库的所有数据(包括架构和辅助索引)。对 version_time 之后的数据或架构所做的任何修改都不会包含在备份中。备份不包含 Identity and Access Management (IAM) 政策等数据库元数据。

创建过程

创建备份时,您必须指定源数据库、备份资源的名称和失效日期(从创建备份起最长 1 年)。您也可以选择指定 version_time,以便提前备份数据库。version_time 字段通常用于同步多个数据库的备份,或使用时间点恢复恢复数据。如果未指定 version_time,则将其设置为备份的 create_time。系统会创建备份资源和长时间运行的备份操作,以跟踪备份的进度。

为确保备份的外部一致性,Cloud Spanner 在创建时会固定数据库的内容。这样可以防止垃圾回收系统在备份操作期间移除相关数据值。然后,实例中的每个地区开始并行复制数据。如果某个地区暂时不可用,则直到该地区恢复在线并完成后,备份才会完成。备份在操作完成后立即恢复。

资源层次结构

备份是 Cloud Spanner 中的资源。每个备份资源都安排在资源层次结构中与其源数据库相同的实例下,并具有 projects/<project>/instances/<instance>/backups/<backup> 形式的资源路径。即使在备份的源数据库被删除后,备份仍会继续存在,但不会超过其父实例的生命周期。为防止意外删除备份,您无法删除存在备份的 Cloud Spanner 实例。对于要删除实例的用户,我们建议先恢复备份,然后导出恢复的数据库,然后再删除备份和实例。

备份时间和性能

创建备份所需的时间取决于各种因素,但主要取决于数据库大小与节点数。如果需要更快的备份时间,您可以增加节点数,但请注意,对节点数的更改会在后续备份中生效。

备份创建还会使用空闲 CPU,因此请确保您的 CPU 使用量不超出建议的准则。CPU 过载可能导致备份时间非常长,还可能会对数据库延迟时间产生不利影响。

实例中的 CPU 由实例中所有正在进行的备份共享。在同一实例中同时创建不同数据库的备份会导致备份时间较长。

恢复的工作原理

恢复时,您必须指定来源备份和新的目标数据库。您无法恢复到现有数据库。新数据库必须与备份位于同一项目中,并且位于与备份具有相同实例配置的实例中。例如,如果备份位于配置为 us-west3 的实例中,则可以将其恢复到项目中也配置为 us-west3 的任何实例。实例的节点数不必相同。恢复的数据库将具有备份 create_time 中原始数据库的所有数据和架构。它没有任何 IAM 权限(从包含已恢复数据库的实例继承的 IAM 权限除外),并且用户应在恢复完成后应用适当的 IAM 权限。恢复过程旨在实现高可用性,因为只要实例中的大部分区域和地区都可用,数据库就可以恢复。

请务必注意,恢复的数据库会在由两项操作跟踪的三个 States 之间进行转换。

  • CREATING 状态:当您启动恢复时,系统会使用 RestoreDatabaseMetadata 创建新的数据库和长时间运行的数据库操作,以跟踪恢复进度。新数据库将开始运行并保持 CREATING 状态,这意味着它尚未准备就绪,直到恢复操作完成为止。为了提供快速恢复时间(通常在 10 分钟内),恢复操作的工作原理是将文件装载到备份中,而不是将其复制到数据库。

  • READY_OPTIMIZING 状态:恢复操作完成后,数据库将转换为 READY_OPTIMIZING 状态。在此状态下,数据库可供使用,但数据库从备份中读取数据时,您可能会遇到读取延迟略高的情况。如果备份正用于数据库恢复或优化,则任何删除备份的尝试都将失败。

    恢复操作完成后,您将获得另一个长期运行的数据库操作,其中包含 OptimizeRestoredDatabaseMetadata,以跟踪优化的进度。优化操作会将备份中的数据复制到数据库。如果您希望加速优化过程,可以向实例添加更多节点。

  • READY 状态:优化操作完成后,数据库将转换为 READY 状态。此时,恢复的数据库完成性能优化,不再引用备份。

一个实例最多只能有一个恢复 CREATING 状态的数据库。在恢复的数据库转换为 READY_OPTIMIZINGREADY 状态之前,您将无法将另一个备份恢复到实例。

结算

系统会根据您的备份每单位时间使用的存储量向您收取费用。备份操作完成后,便开始计费,并且将持续计费直到删除备份为止。从备份进行恢复是免费的。

备份会单独存储和计费。备份存储空间不会影响数据库存储空间的结算数据库存储空间限制

已完成的备份将至少收取 24 小时的费用。如果您创建了备份,然后在备份完成后一分钟将其删除,则您仍需支付 24 小时的费用。

如需详细了解备份费用,请参阅 Cloud Spanner 价格页面。

访问控制 (IAM)

通过 IAM,您可以控制对 Cloud Spanner 资源的访问权限,包括备份和恢复的数据库。如果您不熟悉 IAM、角色和权限,请参阅 IAM 概览以了解相关介绍。

备份资源将整理到 Cloud Spanner 资源层次结构中的实例下。我们建议您在项目级层或实例级层应用 IAM 政策。如果您需要更精细的控制,也可以在备份和数据库级层应用 IAM 政策,但这样太过复杂,我们不建议这样做。请记住,备份不包含 IAM 政策等数据库元数据,因此当您恢复数据库时,数据库会在开始时从其父实例继承政策。

本部分介绍有权访问备份和恢复的预定义角色。

以下角色专门用于备份和恢复:

  • spanner.backupAdmin:有权创建、查看、更新和删除备份。此角色还可以查看和管理备份的 IAM 政策。此角色无法从备份恢复数据库。
  • spanner.restoreAdmin:有权从备份恢复数据库。如果您需要将备份恢复到其他实例,请在项目级层应用此角色,或将项目级层应用于这两个实例。此角色无法创建备份。
  • spanner.backupWriter:有权创建备份,但无法更新或删除备份。此角色旨在供自动创建备份的脚本使用。

以下角色也具有备份和恢复权限:

  • spanner.admin:拥有对备份和恢复的完全访问权限。此角色拥有对所有 Cloud Spanner 资源的完整访问权限。
  • owner:拥有对备份和恢复的完全访问权限
  • editor:拥有对备份和恢复的完全访问权限
  • viewer:有权查看备份、备份操作和恢复操作。此角色无法创建、更新、删除或恢复备份。

如需了解详情,请参阅 Cloud Spanner IAM