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

1 分钟阅读

我正在对 Amazon Aurora 集群执行集群克隆、快照恢复或时间点操作。

简短描述

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

**注意：**如果您在运行 AWS 命令行界面（AWS CLI）命令时遇到错误，请确保您使用的是最新版本的 AWS CLI。

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

当您启动克隆、快照或时间点恢复时，Amazon Relational Database Service（Amazon RDS）会代表您调用以下 API：

RestoreDBClusterFromSnapshot 或 RestoreDBClusterToPointInTime。这些 API 将创建一个新的集群并从 Amazon Simple Storage Service（Amazon S3）恢复卷。此操作可能需要几个小时才能完成。当您将数据恢复到 Aurora 集群时，所有数据都从 Amazon S3 并行传输到您的三个可用区上的六个副本。
集群存储卷克隆是 RestoreDBClusterToPointInTime 的变体。它使用写入时复制协议，通常在几分钟内完成。

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

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

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

**注意：**如果您使用 AWS CLI 或 API 执行恢复操作，则必须启用 CreateDBInstance 调用，因为它不是自动的。

最佳实践是确认在拍摄快照、时间点或克隆时源数据库上没有长时间运行的写入操作。任何长时间运行的 DCL、DDL 或 DML（打开写入事务）都可能会延长恢复的数据库变为可用状态所需的时间。

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

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

注意：Aurora 不需要二进制日志。除非有必要，否则最佳实践是停用该功能。对于跨区域复制，您可以改为评估 Aurora 全局数据库。Aurora 全局数据库也不需要二进制日志。