亚马逊AWS官方博客
使用 Amazon Aurora 进行本地写入转发
在云端设计的应用程序需要能够扩展。对于应用程序服务器之类的无状态资源，这是一项简单的任务，只需在负载均衡器后面添加额外的计算资源即可实现。对于数据库等有状态的资源，扩展可能更具挑战性。
随着 2015 年 Amazon Aurora 的发布，客户可以在由 1 个写入器和最多 15 个低延迟读取器节点组成的 Aurora 集群中运行关系数据库。这使应用程序能够显著扩展读取规模。但是，与任何支持多个端点的数据库一样，开发人员已经构建了复杂的应用程序逻辑，或者依赖代理在节点之间分配连接。此外，出于性能原因，对于大多数工作负载来说，异步读取器都是理想的选择。但是，有时开发人员需要运行同步读取。
2020 年，Amazon 为 Amazon Aurora Global Database 推出了只读副本写入转发功能。此功能使开发人员能够向 Aurora 全球数据库读取器区域中的读取器节点发出 DML 命令，而无需任何特殊的网络配置，对应用程序设计的影响也最小。此外，此功能使开发人员能够在写入后以开发人员指定的一致性级别执行读取。
为全球数据库集群之间的写入转发而开发的功能现在可在单个集群、单个区域内使用。这使应用程序能够向该单个集群中的读取器节点发送写入命令，然后将这些命令转发到同一集群中的写入器节点。
在这篇文章中，我们将讨论这项新功能的好处。
| 截至撰写本文时，此功能仅适用于 Amazon Aurora MySQL 兼容版。 |
本地写入转发简介
根据应用程序的需求，本地写入转发即使不能消除，也可以大大减少对代理或对应用程序代码进行任何特殊修改的需求。应用程序现在可以连接到集群中的任何读取器节点并发出读取和写入操作。读取将直接由读取器提供，写入操作将自动转发给写入器运行，如下图所示。
读取一致性
aurora_replica_read_consistency 参数最初是在 Aurora 全局数据库的只读副本写入转发中引入的。此参数通过本地写入转发继续传递，使用户能够指定最终一致性、会话一致性或全局一致性，从而控制读取一致性的级别。aurora_replica_read_consistency 参数可以在参数组或会话级别使用如下所示的命令进行设置：
默认情况下，由于 Aurora 复制的异步性质，Aurora 集群中的读取器会在最终一致性级别上运行。无论是否启用写入转发，都是如此。
Aurora 集群中的写入器节点执行写入操作时，会使用 4/6 仲裁将重做日志记录发送到存储卷。它还会向集群中的每个读取器发送相同的日志记录。如果读取器的缓冲区缓存包含适用的页面，则读取器会将日志记录应用于存储在缓冲区缓存中的页面。发送给读取器的信息中还会包含 VDL（卷持久日志序列号）。该序列号将告知读取器刚刚收到的日志记录已永久存储到存储卷中，以及上次写入的记录的 LSN（日志序列号）是多少。将这些记录发送到存储节点的时间与读取器意识到这些记录的时间之间的差异就是写入器和读取器之间的延迟，通常在 20 毫秒以内。
通过修改读取器节点上的 aurora_replica_read_consistency 参数，可以指定写入后的读取一致性。当应用程序尝试使用最终一致性模式从读取器节点读取信息时，无论读取器上的最新 VDL 是什么，读取器都会立即返回。对于许多应用程序来说，这种过时程度是可以接受的，对于应用程序来说，读取器快速响应比最新的数据视图更重要。例如，每分钟更新一次天气数据的天气监控应用程序非常适合采用最终一致性。数据本质上不是事务性的，对写入延迟也不是特别敏感。
对于需要先写后读一致性的应用程序（但仅限于与当前会话相关的应用程序），session 值可用于 aurora_replica_read_consistency 参数。这将确保读取器等待与当前会话生成的最新写入相关的 VDL。这会导致延迟略有增加，但视图与当前会话中生成的写入内容一致。当写入后一致读取很重要，但会话只在意查看自己的更改，而不在意其他会话所做的更改，或者当没有其他会话对同一数据进行更改时，会话一致性很重要。其中一个示例可能是更新用户配置文件，其中，务必将对单个配置文件所做的更改回显到应用程序。
要求读取必须与数据库中所有其他写入操作保持全局一致的应用程序可以使用 aurora_replica_read_consistency 参数的 global 值。在这种情况下，当读取器在事务中发出第一次读取时，它会向写入器索要当前 VDL，然后等到复制赶上该 VDL。这仅针对事务中的第一次读取发生，因为所有使用本地写入转发的事务都将使用 REPEATABLE READ 事务隔离级别。此同步过程产生的延迟等于读取器和写入器之间的往返时间（请求 VDL）加上复制延迟（等待复制赶上 VDL）。对于某些应用程序，与读取器保持单一连接的便利性相对于请求中增加的延迟是利大于弊。对于需要绝对最低延迟响应的应用程序，从写入器节点读取仍然是最佳选择。可能需要全局一致性的应用程序的一个例子可能是银行应用程序，其中多个写入器可能会同时修改单个表，并且必须对最新数据执行所有读取和写入。
提高资源利用率
在本地写入转发之前，想要在写入后进行一致读取的用户必须在写入器上发出读取。写入器处理读取所需的额外资源会降低写入器用于处理新写入流量的容量。通过使读取器节点能够在任何时候获得一致的读取，开发人员可以更轻松地使用 Aurora 的 15 个只读副本实现工作负载所需的读取规模，并使他们的写入器可以专注于写入。
改进应用程序设计
对于需要偶尔写入的读取密集型工作负载，写入转发可以极大地简化应用程序设计。由于现在可以将写入内容从读取器转发到写入器，因此可以在读取器上为读取和写入维护单个会话，从而简化应用程序开发。
为了避免写入器不堪重负，请注意 aurora_fwd_writer_max_connections_pct 参数。此参数指定写入器上可用于写入转发的连接百分比。例如，如果写入器最多可以接受 1000 个连接，并且 aurora_fwd_writer_max_connections_pct 参数设置为 10，则写入器上最多允许 100 个连接用于从读取器转发的写入。
写入优先级
在本地写入转发之前，所有写入数据库的连接都连接到单个写入器端点，并发送 DML 语句，该语句随后将由写入器处理。使用本地写入转发时，读取器节点收到的 DML 语句将作为一种中继转发给写入器。写入器仍然会收到相同的 DML 语句，其处理方式就像应用程序直接连接到写入器一样。
摘要
本地写入转发使开发人员能够向区域 Aurora 集群中的任何节点发出读写语句，从而降低应用程序代码的复杂性或部署代理以区分读取和写入查询的需求。此外，开发人员现在可以通过指定 aurora_replica_read_consistency 参数在读取一致性和速度之间做出权衡。
立即开始使用 Amazon Aurora Global Database 和本地写入转发吧！
Original URL: https://aws.amazon.com/blogs/database/local-write-forwarding-with-amazon-aurora/