为什么我的 Amazon Aurora 数据库集群克隆、快照恢复或时间点恢复需要这么长时间?

上次更新时间:2020 年 10 月 21 日

我正在对 Amazon Aurora 集群执行集群克隆、快照恢复或时间点操作。为什么此恢复过程需要这么长时间,我该如何解决此问题?

简短描述

Amazon Aurora 的连续备份和恢复技术经过优化,可避免恢复时间出现变动。它们还有助于集群的存储卷在集群可用时立即达到全面性能。通常,恢复时间较长是由于在进行备份时源数据库中长时间运行的事务处理造成的。

解决方法

注意:如果您在运行 AWS 命令行界面 (AWS CLI) 命令时收到错误,请确保您正在运行最新版本的 AWS CLI

Amazon Aurora 会自动连续备份集群卷的更改。备份将在备份保留期内保留。此连续备份还意味着您能够将数据恢复到新的集群,并将其恢复到指定的保留期内的任何时间点。这样就不需要冗长的二进制日志前滚过程。由于您新建了集群,因此不会影响原始数据库的性能或导致中断。

当您启动克隆、快照或时间点恢复时,Amazon RDS 会代表您调用以下 API:

此步骤完成后,集群将变更为“可用”状态。您可以通过刷新控制台或使用 AWS CLI 检查您的集群状态。

实例创建过程仅在集群处于“可用”状态时启动。这分为两个阶段:设置实例配置和数据库崩溃恢复。

您可以通过查找 MySQL 错误日志文件来检查 API 是否已完成实例的设置。即使实例处于“正在创建”状态,也可以执行此操作。如果错误日志文件可供下载,这意味着实例已设置,引擎现在正在执行崩溃恢复操作。错误日志文件也是检查数据库崩溃恢复进度以及 Amazon CloudWatch 指标的最佳资源。

注意:如果您使用 AWS CLI 或 API 执行还原操作,请确保启用 CreateDBInstance 调用,因为它不是自动的。

检查源数据库上是否存在长时间运行的写入操作

防止长时间崩溃恢复的最佳方法是确保在执行快照、时间点或克隆时,源数据库上没有长时间运行的写入操作。任何长时间运行的 DCL、DDL 或 DML(打开写入事务)都可能会延长恢复的数据库变为可用状态所需的时间。

例如,如果为 Aurora 集群启用二进制日志,则会增加执行恢复所需的时间。这是因为 InnoDB 会自动检查日志,并将数据库前滚到当前点。然后,它会回滚恢复时存在的任何未提交的事务。有关 InnoDB 崩溃恢复的详细信息,请参阅 Innodb 恢复

当实例完成创建和恢复过程后,集群和实例便可以接受传入连接。

注意:Aurora 不需要二进制日志。除非有必要,否则最佳做法是禁用它。对于跨区域复制,您可以改为评估 Aurora 全局数据库,这也不需要二进制日志。


这篇文章对您有帮助吗?


您是否需要账单或技术支持?