多可用区数据库实例部署
Amazon RDS 使用带有一个备用数据库实例的多可用区部署为数据库实例提供高可用性和故障转移支持。这种类型的部署称为多可用区数据库实例部署。Amazon RDS 使用几种不同的技术来提供此故障转移支持。用于 MariaDB、MySQL、Oracle、PostgreSQL 和 RDS Custom for SQL Server 数据库实例的多可用区部署使用 Amazon 失效转移技术。Microsoft SQL Server 数据库实例使用 SQL Server 数据库镜像 (DBM) 或 Always On 可用性组 (AG)。有关多可用区的 SQL Server 版本支持的信息,请参阅Amazon RDS for Microsoft SQL Server 多可用区部署。有关将 RDS Custom for SQL Server 用于多可用区的信息,请参阅管理 RDS Custom for SQL Server 的多可用区部署。
在多可用区数据库实例部署中,Amazon RDS 会自动在不同可用区中配置和维护一个同步备用副本。主数据库实例将跨可用区同步复制到备用副本,以提供数据冗余并在系统备份期间将延迟峰值降至最小。在计划内的系统维护期间,运行具有高可用性的数据库实例可以提高可用性。它还可以帮助您保护数据库,以防数据库实例发生故障和可用区中断。有关可用区的更多信息,请参阅区域、可用区和 Local Zones。
注意
高可用性选项不是只读场景的扩缩解决方案。您不能使用备用副本来提供读取流量。要提供只读流量,请使用多可用区数据库集群或只读副本。有关多可用区数据库集群的更多信息,请参阅 多可用区数据库集群部署。有关只读副本的更多信息,请参阅 使用数据库实例只读副本。
使用 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(每秒输入/输出操作数)以获得快速、一致的性能。有关数据库实例类的更多信息,请参阅 数据库实例类。
将数据库实例修改为多可用区数据库部署
如果您有一个单可用区部署的数据库实例,并且要将它修改为多可用区数据库实例部署(对于 Amazon Aurora 之外的引擎),则 Amazon RDS 执行几个操作:
-
拍摄主数据库实例的 Amazon Elastic Block Store(EBS)卷的快照。
-
从快照中为备用副本创建新卷。这些卷在后台初始化,并在数据完全初始化后达到最大卷性能。
-
开启主副本卷与备用副本卷之间的同步块级复制。
重要
使用快照创建备用实例,可避免在从单可用区转换到多可用区时出现停机,但您会在转换到多可用区期间与转换后体验到明显的性能影响。对于对写入延迟敏感的工作负载而言,这可能会产生很大的影响。
尽管该功能可以快速从快照中还原大型卷,但由于同步复制,它可能会导致 I/O 操作的延迟大大提高。这种延迟可能会影响您的数据库性能。作为最佳实践,我们强烈建议不要在生产数据库实例上执行多可用区转换。
为避免影响当前为敏感工作负载提供服务的数据库实例的性能,请创建只读副本并在只读副本上启用备份。将只读副本转换为多可用区,然后运行查询,以将数据加载到只读副本的卷中(在两个可用区上)。然后,将只读副本提升为主数据库实例。有关更多信息,请参阅使用数据库实例只读副本。
有两种方法可将数据库实例修改为多可用区数据库实例部署:
使用 RDS 控制台转换为多可用区数据库实例部署
您可以使用 RDS 控制台将数据库实例转换为多可用区数据库实例部署。
您只能使用控制台来完成转换。要使用 AWS CLI 或 RDS API,请按照将数据库实例修改为多可用区数据库部署中的说明操作。
使用 RDS 控制台转换为多可用区数据库实例部署
登录 AWS Management Console 并通过以下网址打开 Amazon RDS 控制台:https://console.aws.amazon.com/rds/
。 -
在导航窗格中,选择数据库,然后选择要修改的数据库实例。
-
从 Actions(操作)中,选择 Convert to Multi-AZ deployment(转换为多可用区部署)。
-
在确认页面上,选择 Apply immediately(立即应用)以立即应用更改。选择此选项不会导致停机,但可能会对性能产生影响。或者,您可以选择在下一个维护时段内应用更新。有关更多信息,请参阅计划修改设置。
-
选择 Convert to Multi-AZ(转换为多可用区)。
将数据库实例修改为多可用区数据库部署
您可以通过以下方式将数据库实例修改为多可用区数据库实例部署:
-
使用 RDS 控制台,修改数据库实例,并将 Multi-AZ deployment(多可用区部署)设置为 Yes(是)。
-
使用 AWS CLI,调用 modify-db-instance 命令,然后设置
--multi-az
选项。 -
使用 RDS API,调用 ModifyDBInstance 操作并将
MultiAZ
参数设置为true
。
有关修改数据库实例的信息,请参阅修改 Amazon RDS 数据库实例。在修改完成后,Amazon RDS 会触发事件 (RDS-EVENT-0025),表示该过程已完成。您可以监控 Amazon RDS 事件。有关事件的更多信息,请参阅使用 Amazon RDS 事件通知。
Amazon RDS 的故障转移过程
如果由于基础设施缺陷而导致数据库实例发生计划内或计划外的中断时,此时如果您已启用多可用区,则 Amazon RDS 会自动切换到另一个可用区中的备用副本。完成故障转移所用的时间取决于在主数据库实例变为不可用时的数据库活动和其他条件。故障转移时间通常为 60–120 秒。不过,事务较多或时间较长的恢复过程可能延长故障转移时间。完成故障转移后,RDS 控制台还需要一段时间才能反映新的可用区。
注意
在重启数据库实例时,可以手动强制执行故障转移。有关更多信息,请参阅“重启中的数据库实例”。
Amazon RDS 会自动处理故障转移,因此,您可以尽快恢复数据库操作而无需管理干预。如果出现下表中描述的任一情况,主数据库实例会自动切换到备用副本:您可以在事件日志中查看这些故障转移原因。
故障转移原因 | 描述 |
---|---|
RDS 数据库实例所在的操作系统正在脱机操作中安装补丁。 |
在操作系统补丁或安全更新的维护时段内触发了故障切换。 有关更多信息,请参阅“维护数据库实例”。 |
RDS 多可用区实例的主要主机运行状况不佳。 |
多可用区数据库实例部署检测到受损的主数据库实例并进行故障转移。 |
由于网络连接断开,无法访问 RDS 多可用区实例的主机。 |
RDS 监控检测到主数据库实例的网络可达性故障并触发了故障转移。 |
客户修改了 RDS 实例。 |
RDS 数据库实例修改触发了故障转移。 有关更多信息,请参阅“修改 Amazon RDS 数据库实例”。 |
RDS 多可用区主实例正忙且无响应。 |
主数据库实例没有响应。建议您执行以下操作:
有关这些建议的更多信息,请参阅 Amazon RDS 的监控工具 和 Amazon RDS 的最佳实践。 |
RDS 多可用区实例的主要主机所在的存储卷出现故障。 |
多可用区数据库实例部署在主数据库实例上检测到存储问题并进行故障转移。 |
用户请求数据库实例的故障转移。 |
您重新启动了数据库实例,并选择了通过故障转移重启。 有关更多信息,请参阅重启中的数据库实例。 |
要确定多可用区数据库实例是否发生故障转移,您可以执行以下操作:
将数据库事件订阅设置为在故障转移启动时向您发送电子邮件或 SMS 通知。有关事件的更多信息,请参阅 使用 Amazon RDS 事件通知。
使用 RDS 控制台或 API 操作查看数据库事件。
使用 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 信息是极为重要的。
您可以通过检索 networkaddress.cache.ttl
String ttl = java.security.Security.getProperty("networkaddress.cache.ttl");
注意
默认 TTL 是变化的,具体取决于 JVM 的版本以及是否安装安全管理器。许多 JVM 提供的默认 TTL 小于 60 秒。如果您使用此类 JVM 并且未使用安全管理器,则您可以忽略本主题的剩余内容。有关 Oracle 中安全管理器的更多信息,请参阅 Oracle 文档中的安全管理器
要修改 JVM 的 TTL,请设置 networkaddress.cache.ttl
属性值。根据您的需求,使用下列方法之一:
-
要为使用 JVM 的所有应用程序全局设置属性值,请在
networkaddress.cache.ttl
文件中设置$JAVA_HOME/jre/lib/security/java.security
。networkaddress.cache.ttl=60
-
要仅在本地为应用程序设置属性,请在建立任何网络连接之前,在应用程序的初始化代码中设置
networkaddress.cache.ttl
。java.security.Security.setProperty("networkaddress.cache.ttl" , "60");