如何排查和解决 Aurora MySQL 兼容版快照恢复问题？

2 分钟阅读

我想从快照或备份恢复 Amazon Aurora MySQL 兼容版数据库集群，但我遇到了问题。

简短描述

从快照或备份恢复整个 Aurora MySQL 兼容版数据库集群有多种不同的方案。您可以使用 Aurora 和 Amazon Relational Database Service (Amazon RDS) 控制台从快照恢复整个数据库集群，或进行时间点恢复 (PITR)。您也可以使用 AWS Backup 来管理自动备份并进行 PITR 恢复。或者，您可以为数据库创建 Aurora 克隆。

解决方法

**注意：**如果您在运行 AWS 命令行界面 (AWS CLI) 命令时收到错误，请参阅 Troubleshooting errors for the AWS CLI（AWS CLI 错误故障排除）。此外，请确保您使用的是最新版本的 AWS CLI。

使用 Aurora 和 RDS 控制台从快照恢复

当您创建快照时，Aurora 会备份整个数据库集群。对于 Aurora，您无法仅针对集群中的单个数据库实例创建快照。

对于简单的恢复操作，请使用 Aurora 和 RDS 控制台。当您使用 Aurora 和 RDS 控制台从数据库集群快照恢复时，Aurora 会创建一个新集群并预置一个写入器实例。您无法将快照恢复到现有集群。

您也可以使用 restore-db-cluster-from-snapshot 命令从快照恢复集群，但此方法只能创建集群。然后，使用 create-db-instance 命令为该集群创建写入器实例和读取器实例。

恢复完成后，新集群的端点会与原始集群不同。要在替换生产集群时最大限度地减少停机时间，请完成以下步骤：

恢复到集群时，请使用新名称，例如 original-cluster-name-new。
将现有集群重命名为 original-cluster-name-old。
注意：重命名集群时会出现 1-3 分钟的停机。
将新集群重命名为原名称。

此外，恢复到新集群后，必须在新集群中手动添加和配置所需的多可用区读取器实例。

要在新集群中添加读取器实例，请完成以下步骤：

打开 Aurora 和 RDS 控制台。
在导航窗格中，选择 Databases（数据库），然后选择新集群。
等待新主实例的状态变为 Available（可用），然后选择 Actions（操作）。
要将读取器添加到同一 AWS 区域的新集群，请选择 Add reader（添加读取器）。
要配置跨区域只读副本，请选择 Create cross-region read replica（创建跨区域只读副本）。

防止恢复缓慢

如果卷大小较大，实例类的 I/O 大小较小，或网络带宽不足，则集群需要更长的时间才能恢复。此外，目标数据库的最大存储吞吐量也会影响恢复速度。

为了最大限度地缩短恢复 Aurora MySQL 兼容版集群所需的时间，请执行以下操作：

检查原始集群上的 RollbackSegmentHistoryListLength (HLL) 值。HLL 值较高表明存在大量 undo 记录，这可能会减慢恢复速度。要解决此问题，请监控 CloudWatch 中的 HLL 指标并将该值保持在较低水平。
要提高恢复性能，请选择具有更高存储吞吐量和网络带宽的较大实例类。
在工作负载较低的时段创建快照。如果您在数据库活动较少时创建快照，则可以减少 Aurora 在恢复过程中需要处理的 undo 记录。
以较小批量提交事务。如果您将长时间运行的事务拆分为较小的单元，则可以减小 undo 日志的大小。
在创建快照之前，请避免长时间运行的事务。长时间运行的事务会产生更多 undo 记录，Amazon RDS 在恢复过程中必须处理这些记录。

使用 AWS Backup 进行 PITR

当您使用 AWS Backup 创建快照时，快照名称会包含 awsbackup:job-AWS-Backup-job-number。这些快照被视为手动数据库集群快照，但不计入 Aurora 的数据库集群快照配额。

您也可以使用 AWS Backup 来管理用于 PITR 的自动备份。AWS Backup 管理的自动备份的名称会包含 continuous:cluster-AWS-Backup-job-number。要启用 PITR，必须在备份规则中开启持续备份。

使用 AWS Backup 控制台来恢复与 AWS Backup 计划关联的集群。使用 AWS Backup 控制台恢复集群后，必须添加主写入器数据库实例。为此，请运行 create-db-instance AWS CLI 命令。将 --db-cluster-identifier 替换为已恢复数据库集群的名称。

备份失败

当您在 AWS Backup 中使用的策略没有足够的 AWS Identity and Access Management (IAM) 权限时，可能会出现备份失败。要解决此问题，请验证 IAM 角色或用户是否具有使用 AWS Backup 执行备份操作所需的权限。您必须附加 IAM 策略，向 IAM 角色或用户授予 backup:StartBackupJob 权限。

当 IAM 角色或用户无法访问用于备份操作的 AWS Key Management Service (AWS KMS) 密钥时，也可能会出现备份失败。如果您的 Aurora 集群使用了静态加密，请确保 IAM 角色或用户可以访问并使用加密集群存储的 AWS KMS 密钥。您必须对密钥资源策略授予 kms:GenerateDataKey 权限。

恢复失败

当您尝试从备份快照恢复 Aurora MySQL 兼容版集群时，可能会由于以下原因收到“Incompatible-restore”错误：

源数据库包含临时表或 MyISAM 表，当您恢复到新集群时，Aurora 不支持这些表。要解决此问题，请在创建快照之前移除这些表。
源数据库中不一致或循环的外键约束可能会阻止成功恢复。要解决此问题，请在创建快照之前修复这些约束。
目标集群的引擎版本不兼容。要解决此问题，请验证目标 Aurora MySQL 引擎版本是否与您创建快照所使用的版本兼容。如果您想升级新集群的引擎版本，请先恢复到兼容版本。然后，升级已恢复的集群。
网络配置不正确。请仔细检查您在恢复过程中指定的虚拟私有云 (VPC)、子网组和安全组设置是否与预期目标环境相匹配。
IAM 角色或用户没有 AWS KMS 密钥访问权限。如果快照使用了加密，请验证 IAM 角色或用户是否有权访问并使用指定的 AWS KMS 密钥进行解密。

创建 Aurora 克隆

作为替代方法，您可以为数据库创建 Aurora 克隆。通过数据库克隆，您可以快速创建数据库副本，且占用的额外空间最少。数据仅在发生更改时才会被复制。