继静态加密之后,Amazon DynamoDB 团队趁热打铁,再次为大家献上有用的功能。在 AWS re:Invent 2017 上,我们为 DynamoDB 表推出了全局表和按需备份与还原功能。今天,我们进一步推出了连续备份和时间点还原 (PITR) 功能。
您只需在 AWS 管理控制台一次点击,或进行一次 API 调用,或使用 AWS 命令行界面 (CLI),即可启用连续备份功能。DynamoDB 可以按低至一秒的粒度备份数据,并且可以还原从启用 PITR 功能以来任何一秒的数据,最长可还原 35 天内的数据。我们推出此功能是为了防止意外的写入或删除操作。 如果开发人员利用生产数据而不是暂存数据运行了脚本,或者有人不小心执行了 DeleteItem 调用,PITR 将为您解除后顾之忧。此外,我们还特别考虑了您一般无法预测到的场景。您可以继续根据存档的需要执行按需备份,而 PITR 为意外的数据丢失提供了额外的保障。下面来看它的工作原理。
连续备份
如要启用此功能,请在控制台导航至我们的表,然后选择 Backups (备份) 选项卡。直接单击 Enable (启用) 即可打开此功能。此外还可以通过 UpdateContinuousBackups API 调用打开连续备份功能。
启用连续备份功能后,我们应该可以看到 Earliest restore date (最早可还原日期) 和 Latest restore date (最晚可还原日期)。
假设我有许多旧的用户资料准备删除。
其实我只是准备根据用户的 last_update
日期向活跃用户发送服务更新信息。我决定写一段简要的 Python 脚本,以删除已经有一段时间没有使用我的服务的所有用户。
Python
很好!这将会删除从 2013 年以来从未登录我的服务的所有非用户。然后 — CTRL+C CTRL+C CTRL+C CTRL+C (中断当前正在执行的命令)。
呀!您看出是哪里出问题了吗?我其实是删除了对我最重要的用户!啊,不要!我在本该使用小于符号的地方使用了大于符号!赶紧的,我要在 Jeff Barr 可以看到前还原表。(利用 Boto 3 的 DynamoDB 条件,我也许可以防止那个手误: Attr("last_update").lt("2014-01-01T00:00:00")
)
还原
幸好,还原一张表十分简单。我在控制台导航至我的表,打开 Backups (备份) 选项卡,然后单击 Restore to point-in-time (时间点还原)。
我将指定要还原的时间 (在我开始疯狂删除前的几秒) 以及我计划还原的表名称。
对于像我这样相对小、平均分布的表,还原速度非常快。
还原表所需的时间取决于多方面的因素,还原时间不一定由表的大小决定。如果您的数据集在主键上平均分布,您将能够利用并行计算的优势来加快还原。
了解更多并亲自尝试一下
有关此新功能的更多信息请参阅此处的文档。
不同区域的连续备份定价是不同的,取决于表和所有索引的当前大小。
请注意几件事:
PITR 支持加密表。
如果您禁用 PITR 后重新启用它,这将重置您可以还原表的开始时间。
与按需备份一样,启用此功能不会影响性能或可用性。
流设置、生存时间设置、PITR 设置、标记、Amazon CloudWatch 警报以及自动扩展策略不会复制到还原后的表。
其实 Jeff 一直都知道我还原了表,因为每次 PITR API 调用都记录在 AWS CloudTrail 中。
本文转载自 AWS 技术博客。
原文链接:
评论