如何缩短 Amazon RDS for MySQL 实例的快照还原时间？

简短描述

快照还原时间长通常是由长时间的数据库恢复造成的。数据库恢复时间基于快照发生时的实例工作负载。如果您在源数据库实例上激活了二进制日志记录，则恢复时间和快照还原时间可能会更长。

当您还原快照时，Amazon RDS 会执行恢复过程，并在新的数据库实例上启动 MySQL 数据库引擎。根据恢复会话时间，新的数据库实例最多可能需要几分钟才能启动。有关更多信息，请参阅 MySQL 网站上的 InnoDB 崩溃恢复。

**注意：**在从 Amazon Simple Storage Service (Amazon S3) 完全恢复卷之前，您会遇到一些延迟或延迟加载。有关详细信息，请参阅从数据库快照恢复。

有关 PITR（point-in-time recovery，时间点恢复），请参阅为什么对 Amazon RDS for MySQL 实例执行时间点恢复需要很长时间？

解决方法

要缩短快照还原时间，请采用以下最佳实践：

• 安排备份窗口，或在非高峰时段手动拍摄数据库实例快照。拍摄快照时，您在源数据库实例上执行的活动会影响数据库和快照的恢复时间。
• 如果源实例在快照期间使用磁存储类型，则还原的实例处于修改状态。例如，当您将数据库快照还原为通用 SSD gp2 或预调配 IOPS 存储类型时，会发生容量变化。在此期间，您可以连接到 Amazon RDS 实例，但可能会遇到性能下降的情况。
• 暂时将您的实例恢复到更高的数据库实例类别。升级数据库实例类时，您可以暂时获得更多资源并缩短崩溃恢复时间。快照还原完成后，可以缩减实例类别。

要缩短开启二进制日志记录的快照的还原时间，请采用以下最佳实践：

• 要缩短二进制日志恢复时间，请避免使用大型事务和大型二进制日志文件。具有大量数据的二进制日志会延长 binlog 的恢复时间。此外，快照还原时间也会有所增加。
• 应使用适当的事务规模。大型事务一次性写入二进制日志文件，不会分成多个不同的文件。结果，二进制日志文件很大，崩溃恢复时间就会增加。
• 应使用适当的二进制日志记录格式。二进制日志记录格式会影响崩溃恢复的规模和效率。有关更多信息，请参阅 MySQL 网站上基于行的日志记录和复制的用法。有关二进制日志记录格式的更多信息，请参阅 MySQL 网站上基于语句和基于行的复制的优缺点。

**注意：**要更快地完成延迟加载，请使用吞吐量更高的 Amazon RDS 实例类型和 Amazon Elastic Block Store (Amazon EBS) 卷。延迟加载完成后，您可以降级实例类类型，并降低 IOPS 和吞吐量值。