Spanner 时间点恢复 (PITR) 可针对 意外删除或写入。例如,如果操作员无意中写入 数据或应用发布会损坏数据库,您可以使用 PITR 进行恢复 过去某个时间点的数据(最多 7 天) 无缝衔接。如果您需要长期保留数据,可以使用以下任一方法: 备份和恢复或导出和导入。
默认情况下,您的数据库会将数据和架构的所有版本保留为一个
小时。您可以通过 version_retention_period
选项将此时间限制延长至 7 天。有关说明,请参阅设置保留期限。
Spanner 以微秒粒度存储旧版本数据,
数据库会维护一个 earliest_version_time
,
表示过去可以恢复旧版本的最早时间
数据。
恢复数据的方法
您可以通过以下两种方式恢复数据:
如需恢复数据库的一部分,请执行过时读取,并指定过去的查询条件和时间戳,然后将结果写回实时数据库中。这通常用于外科手术 实时数据库操作例如,如果您不小心删除了 特定行,或者错误地更新部分数据,您可以恢复 使用该方法。如需查看相关说明,请参阅恢复数据库的一部分。
如需恢复整个数据库、备份或 导出数据库中指定的时间戳, 然后将其恢复或导入到新数据库。这通常用于从数据损坏问题中恢复(您必须将数据库恢复到损坏发生之前的某个时间点时)。请注意,备份或导出数据库可能需要几个小时,您将无法恢复或导入到现有数据库。如需查看相关说明,请参阅恢复整个数据库。
性能考虑因素
保留期限较长的数据库(尤其是经常覆盖数据的数据库)会使用更多系统资源。这可能会影响数据库的性能,尤其是当您的实例未供应足够的计算容量时。如果您的数据库具有非常高的覆盖率(例如,如果您的数据库每天被覆盖多次),您可以考虑逐渐增加保留期并监控系统。请注意以下事项:
增加了存储空间用量。我们建议您设置存储空间提醒,确保不会超出存储空间上限。如果增加保留期限,请注意,随着数据库不断累积旧版数据,存储空间用量将逐渐增加。这是因为在上一个保留期限下将要过期的旧数据不再过期。例如,如果您将保留期限从 3 天增加到 7 天,则需要等待 4 天才能使数据库存储空间用量稳定。我们还会提供用于估算存储空间增量的说明。
增加了 CPU 使用率和延迟时间。Spanner 使用其他计算资源 来压缩和维护旧版本数据。 监控您的实例和数据库以确保延迟时间和 CPU 使用率一直处于可接受的水平。
增加了执行架构更新的时间。保留期限增加意味着必须保留架构版本更长时间,这可能会导致等待服务器资源时的架构更新为
throttled
。确保您遵循架构更新的最佳做法并保持在架构更新的限制范围内。
价格
使用 PITR 功能无需额外付费。但是,如果你 将数据库的版本保留期限从默认的一小时延长 您的数据库存储和计算容量费用可能会增加。您的点播 backup 费用不受影响,因为只有一个版本 数据库的快照。如需了解详情,请参阅性能注意事项部分。提高数据库版本之前 保留期限,您可以估算数据库存储空间的预计增加量。
如需了解有关 Spanner 计费方式的一般信息,请参阅 Spanner 价格。
后续步骤
- 详细了解如何使用 PITR 恢复数据。