Amazon RDS 的高可用性(多可用区)

Amazon RDS 使用多可用区部署为数据库实例提供高可用性和故障转移支持。Amazon RDS 使用几种不同的技术来提供故障转移支持。用于 MariaDB、MySQL、Oracle

和 PostgreSQL 数据库实例的多可用区部署使用 Amazon 的故障转移技术。SQL Server 数据库实例使用 SQL Server 数据库镜像 (DBM)

或 Always On 可用性组 (AG)。

在多可用区部署中，Amazon RDS 会自动在不同可用区中配置和维护一个同步备用副本。主数据库实例将跨可用区同步复制到备用副本，以提供数据冗余、消除 I/O 冻结并在系统备份期间将延迟峰值降至最小。在计划内的系统维护期间，运行高性能的数据库实例可以提高可用性，并帮助保护数据库以防数据库实例发生故障和可用区中断。有关可用区的更多信息，请参阅区域、可用区和本地扩展区。

注意

高可用性功能不是面向只读情况的扩展解决方案；您不能使用备用副本处理读取流量。要处理只读流量，您应当使用只读副本。有关更多信息，请参阅 使用只读副本。

使用 RDS 控制台，您只需在创建数据库实例时指定多可用区，即可创建多可用区部署。您可以使用控制台修改数据库实例并指定多可用区选项，从而将现有数据库实例转换为多可用区部署。您还可以使用

AWS CLI 或 Amazon RDS API 指定多可用区部署。使用 create-db-instance 或 modify-db-instance CLI 命令，或者 CreateDBInstance 或 ModifyDBInstance API 操作。

RDS 控制台显示备用副本的可用区(称为辅助可用区)。您还可以使用 describe-db-instances CLI 命令或 DescribeDBInstances API 操作来查找辅助可用区。

与单可用区部署相比，使用多可用区部署的数据库实例由于执行同步数据复制，因此会增加写入和提交延迟。尽管 AWS 设计用于在可用区之间提供低延迟网络连接，但如果您的部署故障转移到备用副本，延迟可能会发生变化。对于生产工作负载，建议您使用预配置

IOPS 和针对预配置 IOPS 进行了优化的数据库实例类，以实现高速、一致的性能。有关数据库实例类的更多信息，请参阅数据库实例类。

将数据库实例修改为多可用区部署

如果您有一个单可用区部署的数据库实例，并且要将它修改为多可用区部署(对于 Amazon Aurora 之外的引擎)，则 Amazon RDS 需要执行几个步骤。首先，Amazon

RDS 从您的部署中拍摄主数据库实例的快照，然后将该快照还原到另一个可用区。然后，Amazon RDS 在主数据库实例与新实例之间设置同步复制。

重要

该操作可避免在从单可用区转换到多可用区时出现停机，但您会在转换到多可用区期间以及转换后体验到明显的性能影响。对于大型写入密集型数据库实例，这可能会有很大的影响。

为了对数据库实例启用多可用区，RDS 将为主数据库实例的 EBS 卷生成快照并将其还原到新创建的备用副本上，然后同步这两个卷。基于现有 EBS 快照创建的新卷在后台延时加载。此功能允许快速从快照恢复大型卷，但在修改期间及修改完成后可能会增加延迟。有关更多信息，请参阅

Amazon EC2 文档中的从快照还原 Amazon EBS 卷。

在修改完成后，Amazon RDS 会触发事件 (RDS-EVENT-0025)，表示该过程已完成。您可以监控 Amazon RDS 事件；有关事件的更多信息，请参阅使用 Amazon RDS 事件通知。

Amazon RDS 的故障转移过程

数据库实例发生计划内或计划外的中断时，如果您已启用多可用区，则 Amazon RDS 会自动切换到另一个可用区中的备用副本。完成故障转移所用的时间取决于在主数据库实例变为不可用时的数据库活动和其他条件。故障转移时间通常为

60–120 秒。不过，事务较多或时间较长的恢复过程可能延长故障转移时间。完成故障转移后，RDS 控制台还需要一段时间才能反映新的可用区。

注意

在重启数据库实例时，可以手动强制执行故障转移。有关更多信息，请参阅 重启中的数据库实例。

Amazon RDS 会自动处理故障转移，因此，您可以尽快恢复数据库操作而无需管理干预。如果出现以下任一情况，主数据库实例会自动切换到备用副本：

可用区中断

主数据库实例故障

更改数据库实例服务器类型

数据库实例的操作系统在进行软件修补

数据库实例的手动故障转移是使用 Reboot with failover 启动的。

可通过多种方法确定多可用区数据库实例是否进行了故障转移：

数据库事件订阅可设置为在故障转移启动时向您发送电子邮件或 SMS 通知。有关事件的更多信息，请参阅 使用 Amazon RDS 事件通知。

您可以使用 Amazon RDS 控制台或 API 操作查看数据库事件。

您可以使用 Amazon RDS 控制台和 API 操作查看多可用区部署的当前状态。

有关如何响应故障转移、缩短恢复时间以及 Amazon RDS 的其他最佳实践的信息，请参阅 Amazon RDS 的最佳实践。

设置 DNS 名称查找的 JVM TTL

故障转移机制自动更改数据库实例的域名系统 (DNS) 记录，使其指向备用数据库实例。因此，您需要重新建立与数据库实例之间的所有现有连接。在 Java 虚拟机 (JVM)

环境中，由于 Java DNS 缓存机制的工作原理，您可能需要重新配置 JVM 设置。

JVM 缓存 DNS 名称查找。当 JVM 将主机名解析为 IP 地址时，它会在指定时间段内 (称为生存时间 (TTL)) 缓存 IP 地址。

由于 AWS 资源使用偶尔变更的 DNS 名称条目，因此建议您为 JVM 配置的 TTL 值不超过 60 秒。这样做可确保在资源的 IP 地址发生更改时，您的应用程序可以通过重新查询

DNS 来接收和使用资源的新 IP 地址。

对于一些 Java 配置，将设置 JVM 默认 TTL，以便在重新启动 JVM 之前绝不刷新 DNS 条目。因此，如果 AWS 资源的 IP 地址在应用程序仍在运行时发生更改，则在您手动重新启动

JVM 并刷新缓存的 IP 信息之前，将无法使用该资源。在此情况下，设置 JVM 的 TTL，以便定期刷新其缓存的 IP 信息是极为重要的。

注意

默认 TTL 是变化的，具体取决于 JVM 的版本以及是否安装安全管理器。许多 JVM 提供的默认 TTL 小于 60 秒。如果您使用此类 JVM 并且未使用安全管理器，则您可以忽略本主题的剩余内容。有关

Oracle 中安全管理器的更多信息，请参阅 Oracle 文档中的安全管理器。

要修改 JVM 的 TTL，请设置 networkaddress.cache.ttl 属性值。根据您的需求，使用下列方法之一：

要为使用 JVM 的所有应用程序全局设置属性值，请在 $JAVA_HOME/jre/lib/security/java.security 文件中设置 networkaddress.cache.ttl。

networkaddress.cache.ttl=60

要仅在本地为应用程序设置属性，请在建立任何网络连接之前，在应用程序的初始化代码中设置 networkaddress.cache.ttl。

java.security.Security.setProperty("networkaddress.cache.ttl" , "60");