为什么要很长时间才能对我的 Amazon RDS for MySQL 实例执行时间点恢复?

上次更新时间:2021 年 10 月 14 日

我已经在 Amazon Relational Database Service (Amazon RDS) for MySQL 中启动了时间点恢复 (PITR),所花费的时间比预期的长。为什么会发生这种情况?

简短描述

时间点恢复 (PITR) 是将数据库恢复到指定日期和时间处于的状态的过程。启动 PITR 时,将还原最新的备份(自动或手动)。然后会应用事务日志,以将 Amazon RDS 数据库向前滚动到 PITR 时间。

解决方法

避免长时间点恢复的最佳实践

为避免长时间点恢复,请遵循以下最佳实践:

  • 创建灾难恢复策略
  • 使用较小的事务并更频繁地运行 COMMIT 命令。
  • 要运行大型事务,请在大型事务之前和之后拍摄快照。但是,大于 max_allowed_packet 参数的事务会导致 PITR 失败。
  • 尽量减少快照恢复时间。快照恢复是作为时间点恢复过程的段启动的。更长的快照恢复可能会导致更长的时间点恢复会话。如需获得更多信息,请参阅为什么还原我的 Amazon RDS for MySQL 数据库实例的快照需要这么长时间?
  • 日志应用过程可能需要更长的时间,具体取决于要应用的日志数量。要减少要应用的日志数量,请考虑在自动备份之间拍摄手动快照。由于时间点恢复会自动选择在 PITR 时间附近创建的自动或手动快照,因此拥有中间手动快照可以减少要应用的日志数量。如果您正在处理大量更改,请每 3-4 小时拍摄一次手动快照。
  • 如果重播任何大型事务,那么较低的 wait_timeout 值可能会中断 Amazon RDS for MySQL 中的时间点恢复过程。例如,如果您正在执行基于行的大批量更新、插入或删除操作,并且重播时间比 wait_timeout 长,则会发生中断。为防止 PITR 进程中出现任何中断,请将 wait_timeout 值设置为“600”(10 分钟)或更长时间。有关更多信息,请参阅为 Amazon RDS for MySQL 配置参数的最佳实践中的 wait_timeout 部分。
  • 使用基于行的二进制日志记录时,请考虑将 binlog_row_image 参数值设置为“MINIMAL”,而不是“FULL”。此更新后的值将减小二进制日志的大小,从而最大限度地缩短二进制日志的恢复时间。
  • 除非您需要特定的二进制日志格式,否则请考虑使用混合日志记录格式。对于混合日志记录,默认情况下将使用基于语句的日志记录,但是日志记录模式会根据需要自动切换到基于行的日志记录。此切换可以帮助减少二进制日志的大小。有关混合日志记录的更多信息,请参阅 MySQL 网站上的二进制日志记录格式

时间点恢复故障

以下情况将导致时间点恢复失败:


这篇文章对您有帮助吗?


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