提高亚马逊 Aurora 上的应用程序可用性

# cat /etc/hosts
(...)
XX.XX.XX.XX aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com

2022-12-09 19:12:43	writer
2022-12-09 19:12:44	writer
2022-12-09 19:12:45	writer
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
(... message repeats as previously ...)
2022-12-09 19:12:55	reader
2022-12-09 19:12:56	reader
2022-12-09 19:12:57	reader
2022-12-09 19:12:58	reader
(... the output continues to report “reader” instance status ...)

[ec2-user@ip-XX-XX-XX-XX ~]$ dig <Aurora read/write endpoint>
...
;; ANSWER SECTION:
<Aurora read/write endpoint>. 120 IN A XX.XX.XX.XX
...
;; SERVER: 127.0.0.1#53(127.0.0.1)
...

使用缓存 DNS 解析器没有根本错误，甚至可能是防止 DNS 解 析限制 所必需的。也就是说，如果您必须使用 DNS 缓存，请将 TTL 保持在尽可能低的水平，并避免使用更高的自定义值覆盖默认 TTL。在调查 DNS 缓存问题时，请记住检查应用程序堆栈的所有层，包括虚拟环境（例如 JVM）和容器。

请记住，DNS 系统是分层的，因此在缓存层配置的任何 TTL 值都将计入 Aurora 区域的现有 5 秒 TTL。因此，调整客户端设置可以帮助避免在默认 DNS 行为之外出现额外的 DNS 延迟（从而避免额外的停机时间），但客户端仍将依赖 DNS 来识别实例角色的变化。

使用亚马逊 RDS 代理

亚马逊 RDS 代理 是亚马逊 Aurora 和 亚马逊关系数据库服务 (RDS) 的托管代理。除了连接池和多路传输等常见代理功能外，RDS 代理绕过集群 DNS 终端节点，直接连接到数据库实例，从而帮助最大限度地减少应用程序停机时间。

与 Aurora 配对时，RDS 代理提供读/写和只读 DNS 终端节点，可供使用，而不是 Aurora 集群可用的终端节点。关键区别在于，代理端点在数据库故障转移期间不会发生变化，因此客户端不会错过任何可能错过的 DNS 更新。代理继续接受同一 Endpoint/IP 下的客户端连接，监控数据库实例的状态，并自动将读取和写入查询定向到可用实例。它甚至可以在不中断空闲连接的情况下处理故障转移，这进一步减少了对应用程序可用性的影响。

使用 RDS 代理有助于避免前面列出的所有问题：

• 客户端不再需要识别实例角色的变化。RDS 代理根据集群元数据自动跟踪实例角色，无需使用 DNS。
• 代理提供不变的静态端点，因此客户端不会因 DNS 更改（例如添加、删除或重命名实例时）而看到延迟或连接错误。
• 在建立新的副本之前，代理会考虑每个副本的连接数，因此大大降低了工作负载分布不均匀的风险。

有关在 Aurora 集群中使用 RDS 代理的更多信息，请参阅 RDS 代理 入门 。

让我们使用前面介绍的客户端命令来演示 RDS 代理。这次，我们将使用两个同步的客户端会话进行并排比较。除 DNS 端点外，这些命令是相同的：其中一个会话 ping 集群的写入端点，另一个会话 ping 代理读/写端点。未使用 DNS 缓存，我们从/ et c/hosts 中删除了经过硬编码的集群 IP。

使用内置集群写入器端点的示例命令：

while true; do mysql -haurora-test.cluster-xxx.us-west-2.rds.amazonaws.com --batch --skip-column-names -e "select now(), if(@@innodb_read_only = 1, 'reader', 'writer')"; sleep 1; done;

while true; do mysql -htest-proxy.proxy-xxx.us-west-2.rds.amazonaws.com --batch --skip-column-names -e "select now(), if(@@innodb_read_only = 1, 'reader', 'writer')"; sleep 1; done;

2022-12-13 02:22:41	writer
2022-12-13 02:22:42	writer
2022-12-13 02:22:43	writer
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
ERROR 2003 (HY000): Can't connect to MySQL server on 'aurora-test.cluster-xxx.us-west-2.rds.amazonaws.com:3306' (111)
2022-12-13 02:22:51	reader
2022-12-13 02:22:52	writer
2022-12-13 02:22:53	writer

2022-12-13 02:22:41	writer
2022-12-13 02:22:42	writer
2022-12-13 02:22:43	writer << downtime starts here
2022-12-13 02:22:45	writer << downtime ends here
2022-12-13 02:22:46	writer
2022-12-13 02:22:47	writer
2022-12-13 02:22:48	writer
2022-12-13 02:22:49	writer
2022-12-13 02:22:50	writer
2022-12-13 02:22:51	writer

使用适用于 MySQL 和 PostgreSQL 的 亚马逊云科技

亚马逊云科技 数据库驱动程序旨在减少应用程序停机时间并避免 DNS 传播问题。适用于 MySQL 的开源 亚马逊云科技 JDBC 驱动程序 和适用于 PostgreSQ L 的 亚马逊云科技 JDBC 驱动程序 是为 Java 应用程序构建的智能驱动程序的很好的例子。当驱动程序连接到 Aurora 集群时，它会从 复制状态表 中学习集群拓扑。然后，它会监视各个实例并相应地更新其拓扑元数据。拓扑元数据用于将客户端连接和查询定向到相应的实例。

下图描述了应用程序、适用于 MySQL 的 亚马逊云科技 JDBC 驱动程序和数据库之间的交互：

对于每个客户端会话，驱动程序都保持逻辑连接（应用程序到驱动程序）和物理连接（驱动程序到数据库）。如果物理连接因故障转移而失败，则驱动程序会注意到故障并启动自己的故障转移处理协议，同时保持逻辑连接处于活动状态。一经推广，它就会发现一个新的作者实例。检测到新的写入器后，驱动程序会打开新的物理连接并将控制权返回给客户端。

适用于 MySQL 的 亚马逊云科技 JDBC 驱动程序使用以 jdbc: mysql: aws 开头的连接字符串 URL，但除此以外，它可以用作其他 Java 的 MySQL 驱动程序的直接替代品：

jdbc:mysql:aws://<cluster name>.<cluster id>.<region>.rds.amazonaws.com:3306/<database name>?useSSL=<true>&characterEncoding=<utf-8>

Aurora 的更快故障转移处理在默认情况下处于启用状态，可以通过调整驱动程序参数来禁用。请注意，适用于 MySQL 的 亚马逊云科技 JDBC 驱动程序主要用于减少故障转移的影响，但不支持当前 RDS 代理提供的连接多路传输或负载平衡。由于驱动程序分别在每台客户端计算机上运行，因此最终结果将部分取决于客户端架构和行为。

要详细了解 亚马逊云科技 JDBC 驱动程序与其他驱动程序相比的故障转移性能，请阅读我们的文章： 使用适用于 Amazon Aurora MySQL 的 亚马逊云科技 JDBC 驱动程序 提高应用程序可用性 。

如果您的客户端不使用 JDBC 接口，您仍然可以使用驱动程序的故障转移处理逻辑作为灵感，在应用程序中构建类似的功能。这样做时，你可以使用以下构件：

• 用于学习集群拓扑的 复制状态表 。
• 用于确定实例角色（作者或 读者）的 innodb_read_ only 变量。
• 运行状况检查查询的超时时间足够短，可以快速发现问题，但不够短，不足以导致假阴性结果。

在出现连接问题时改善应用程序响应

上述选项可以通过解决客户端配置问题来解决可用性和 DNS 传播问题，或者更广泛地说，通过在客户端和数据库之间引入智能抽象层来解决可用性和 DNS 传播问题。如果你无法使用这些选项中的任何一个，仍然有办法改善应用程序对故障转移和其他连接相关事件的响应。

示例：

• 对查询错误引入显式异常处理，这些错误表明连接上重复出现了预期可写的只读错误。检测到错误后，应用程序可以尝试修复步骤，例如重新打开连接或重新启动应用程序容器。
• 通过订阅 RDS 事件来检测故障转移和其他可用性事件。 事件订阅可用于为数据库操作员生成警报，或调用自动化例程，例如应用程序重启。
• 定期分析应用程序日志，以检测和调查意外连接关闭、超时和其他错误，这些错误表明实际数据库状态与应用程序假定的状态不一致。

结论

通过充分利用 Aurora 的快速故障转移功能，可以极大地提高关键业务工作负载的可用性。在这篇文章中，我们讨论了故障转移期间可能延长应用程序停机时间的问题，并提出了许多解决方案。总的来说，RDS Proxy 是最完整的解决方案，应该可以很好地适用于各种应用程序和客户端类型。如果您的应用程序使用 Java 编程语言，亚马逊云科技 JDBC 驱动程序是一个不错的选择。最后，在没有诸如代理之类的抽象层的情况下，有针对性地改进应用程序的错误处理逻辑可能会有所帮助。

如果您有任何意见或问题，请将其留在评论部分。

作者简介

Lili Ma 是 亚马逊云科技 的数据库解决方案架构师，在数据库行业拥有超过 10 年的经验。Lili 参与了 Hadoop/Hive NoSQL 数据库、企业级数据库 DB2、分布式数据仓库 Greenplum/Apache HAWQ 以及亚马逊 Aurora、亚马逊 ElastiCache 和亚马逊 MemoryDB 等亚马逊云原生数据库的研发。

Szymon Komendera 是 亚马逊云科技 的数据库解决方案架构师，在数据库、软件开发和应用程序可用性方面拥有近 20 年的经验。他在亚马逊云科技任职的8年大部分时间里都在开发Aurora MySQL，并为亚马逊 Redshift 和亚马逊 ElastiCache 等其他 亚马逊云科技 数据库提供支持。