时间点恢复 (PITR) 概览

Spanner 时间点恢复 (PITR) 可防止意外删除或写入。例如，如果运维人员意外写入数据或应用发布损坏数据库，您可以无缝地使用 PITR 从过去某个时间点恢复数据（最多 7 天）。如果您需要长期保留数据，可以使用备份和恢复或导出和导入。

默认情况下，数据库会将其数据和架构的所有版本都保留 1 小时。您可以通过 version_retention_period 选项将此时间限制延长至 7 天。如需查看说明，请参阅设置保留期限。Spanner 以微秒为单位存储较早版本的数据，并且数据库维护 earliest_version_time，这表示过去可以恢复较早版本的数据的最早时间。

恢复数据的方法

您可以通过以下两种方式恢复数据：

• 如需恢复数据库的一部分，请执行过时数据读取，并指定过去的查询条件和时间戳，然后将结果写回实时数据库中。这通常用于在实时数据库的外部维护操作。例如，如果您不小心删除了某一行或错误地更新了一部分数据，则可以使用此方法进行恢复。如需查看相关说明，请参阅恢复数据库的一部分。

• 如需恢复整个数据库，请通过指定过去时间戳来备份或导出数据库，然后将其恢复或导入至新数据库。这通常用于从数据损坏问题中恢复（您必须将数据库恢复到损坏发生之前的某个时间点时）。请注意，备份或导出数据库可能需要几个小时，您将无法恢复或导入到现有数据库。如需查看相关说明，请参阅恢复整个数据库。

性能考虑因素

保留期限较长的数据库（尤其是经常覆盖数据的数据库）会使用更多系统资源。这可能会影响数据库的性能，尤其是当您的实例未供应足够的计算容量时。如果您的数据库具有非常高的重写频率（例如每天被重写多次），您可以考虑逐步延长保留期，并持续监控系统运行状况。请注意以下事项：

• 增加了存储空间用量。我们建议您设置存储空间提醒，确保不会超出存储空间上限。如果延长保留期限，请注意，随着数据库不断累积较早版本的数据，存储空间用量将逐渐增加。这是因为在上一个保留期限下将要过期的旧数据不再过期。例如，如果您将保留期限从 3 天增加到 7 天，则需要等待 4 天才能使数据库存储空间用量稳定。我们还会提供用于估算存储空间增量的说明。

• 增加了 CPU 使用率和延迟时间。Spanner 使用额外的计算资源来压缩和维护较早版本的数据。监控您的实例和数据库以确保延迟时间和 CPU 使用率一直处于可接受的水平。

• 增加了执行架构更新的时间。保留期限延长意味着必须将架构版本保留更长时间，这可能会导致等待服务器资源时的架构更新为 throttled。确保您遵循架构更新的最佳做法并保持在架构更新的限制范围内。

价格

使用 PITR 无需额外付费。不过，如果您将数据库的版本保留期限从默认的 1 小时延长，那么您的数据库存储空间和计算容量费用可能会增加。您的按需备份费用不受影响，因为系统只会存储一个版本的数据库。如需了解详情，请参阅性能注意事项部分。在延长数据库的版本保留期限之前，您可以估算数据库存储空间的预计增长量。

如需了解 Spanner 的收费方式的一般信息，请参阅 Spanner 价格。

后续步骤

• 详细了解如何使用 PITR 恢复数据。