

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon RDS 的备份和恢复
<a name="rds"></a>

Amazon RDS 包含用于自动备份数据库的功能。Amazon RDS 创建数据库实例的存储卷快照，并备份整个数据库实例，而不仅仅是单个数据库。使用 Amazon RDS，您可以为自动备份建立备份窗口、创建数据库实例快照以及跨区域和账户共享和复制快照。

Amazon RDS 为备份和恢复数据库实例提供了两种不同的选项：
+ **自动备份**提供数据库实例的 point-in-time恢复 (PITR)。创建新的数据库实例时，默认开启自动备份。

  Amazon RDS 在创建数据库实例时定义的备份窗口内对您的数据执行每日备份。您可以为自动备份配置最长 35 天的保留期。Amazon RDS 每隔 5 分钟也将数据库实例的事务日志上传到 Amazon S3 一次。Amazon RDS 使用您的每日备份以及数据库事务日志来恢复您的数据库实例。您可以将实例恢复到保留期内的任意一秒钟，最长可达 `LatestRestorableTime`（通常为最后五分钟）。

  要查找数据库实例的最新可恢复时间，请使用 `DescribeDBInstances` API 调用。或者在 Amazon RDS 控制台上查看数据库的**描述**选项卡。

  启动 PITR 时，会将事务日志与最合适的每日备份相结合，将数据库实例恢复到请求的时间。
+ **数据库快照**是用户启动的备份，可用于随心所欲地将数据库实例还原到已知状态。然后，您可以随时恢复到该状态。您可以使用 Amazon RDS 控制台或 `CreateDBSnapshot` API 调用来创建数据库快照。这些快照会一直保留，直到您使用控制台或 `DeleteDBSnapshot` API 调用将其明确删除。

中的 Amazon RDS 支持这两个备份选项 AWS Backup，它还提供其他功能。考虑使用 AWS Backup 为您的 Amazon RDS 数据库设置标准备份计划，如果特定数据库的备份计划是唯一的，则使用用户启动的实例备份选项。

Amazon RDS 禁止直接访问数据库实例使用的底层存储。这还可以防止您将 RDS 数据库实例上的数据库直接导出到其本地磁盘。在某些情况下，您可以使用客户端实用程序使用本机备份和还原功能。例如，您可以将 [mysqldump 命令与 Amazon RDS MySQL 数据库](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Exporting.NonRDSRepl.html)配合使用，将数据库导出到本地客户端计算机。在某些情况下，Amazon RDS 还提供了用于执行数据库原生备份和还原的增强选项。例如，Amazon RDS 提供了用于[导出和导入 SQL Server 数据库的 RDS 数据库备份的](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.Importing.html)存储过程。

作为整体备份和还原方法的一部分，请务必彻底测试数据库恢复过程及其对数据库客户端的影响。

## 使用 DNS CNAME 记录减少数据库恢复期间对客户端的影响
<a name="dns-cname"></a>

使用 PITR 或 RDS 数据库实例快照还原数据库时，会创建一个带有新端点的新数据库实例。通过这种方式，您可以根据特定的数据库快照或时间点创建多个数据库实例。在恢复 RDS 数据库实例以替换实时的 RDS 数据库实例时，需要注意一些特殊事项。例如，您必须确定如何将现有数据库客户端重定向到新实例，同时尽量减少中断和修改。您还必须考虑恢复数据的时间和新实例开始接收写入时的恢复时间，从而确保数据库内数据的连续性和一致性。

您可以创建指向您的数据库实例端点的单独 DNS CNAME 记录，并让您的客户端使用此 DNS 名称。然后，您可以更新 CNAME 以指向已恢复的新端点，而无需更新数据库客户端。

将 CNAME 记录的有效时间 (TTL) 设置为适当的值。您指定的 TTL 决定了在发出另一个请求之前用 DNS 解析器缓存记录的时间。值得注意的是，某些 DNS 解析器或应用程序可能不支持 TTL，并且它们缓存记录的时间可能会超过 TTL。对于 Amazon Route 53，如果您指定较长的值（例如，172,800 秒，即 2 天），则可以减少 DNS 递归解析器为获取此记录中的最新信息而必须对 Route 53 发出的调用数。这可以缩短延迟并降低您的 Route 53 服务账单。有关更多信息，请参阅 [Amazon Route 53 如何为您的域路由流量](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/welcome-dns-service.html#welcome-dns-service-how-route-53-routes-traffic)。

应用程序和客户端操作系统也可能缓存 DNS 信息，您必须刷新或重新启动这些信息，才能发起新的 DNS 解析请求并检索更新后的 CNAME 记录。

当您启动数据库还原并将流量转移到还原的实例时，请确认您的所有客户端都在写入还原的实例，而不是之前的实例。您的数据架构可能支持恢复数据库、更新 DNS 以将流量转移到已还原的实例，然后修复可能仍写入先前实例的所有数据。如果不是这种情况，则可以在更新 DNS CNAME 记录之前停止现有实例。然后，所有访问权限都来自您新恢复的实例。这可能会暂时导致某些可以单独处理的数据库客户端出现连接问题。为了减少对客户端的影响，可以在维护窗口内执行数据库还原。

通过使用指数回退进行重试，编写应用程序以优雅地处理数据库连接故障。这使您的应用程序能够在还原期间数据库连接不可用时进行恢复，而不会导致应用程序意外崩溃。

完成还原过程后，您可以将先前的实例保持在停止状态。或者，您可以使用安全组规则限制之前实例的流量，直到您确信不再需要该实例为止。对于逐步停用的方法，首先要限制安全组对运行中数据库的访问权限。如果不再需要实例，则可以最终将其停止。最后，拍摄数据库实例的快照并将其删除。