在最近的一则声明中，亚马逊公布了Aurora Multi-Master的普遍可用性，它允许跨多个可用区（AZ）读取和写入多个MySQL数据库实例。这带来了高可用性功能，因为平台不再需要在数据库实例发生故障时触发故障转移或促进读取替换。
Amazon Aurora是一个与开源数据库MySQL和PostgreSQL兼容的关系数据库。它由多个计算节点和多个AZ存储层支持，并由Amazon Relational Database Service（RDS）完全管理。相应地，该服务类似于其他大型云提供商的服务，如Microsoft的Azure数据库服务和Google的Cloud SQL。关于新的多主机功能，必须注意，目前仅在MySQL兼容版本上提供，仅限于特定区域，并且最多支持两个写入节点。
以前，当只有单主模式可用时，Aurora数据库实例的故障导致故障转移到另一个实例。写操作的停机时间伴随着此故障转移，根据数据库的不同，故障转移可以运行在CNAME记录调整的情况下最多30秒，或者在平台需要重新启动数据库的情况下甚至60秒。然而，随着Multi-Master的推出，亚马逊现在已经提出了一种消除故障转移需求的方法。相反，应用程序可以将其读取和写入操作重定向到已经启动并运行的另一个实例，并且之前也处理其他数据库操作。优选地，专用连接管理器应该协调这一点，例如，通过实现跟踪连接，数据库健康的单个单元，并进行数据库调用的逻辑分配。
使用Aurora Multi-Master时，群集中的每个节点都是读取器和写入器，因此应用程序可以使用所有节点来处理其工作负载。这为数据库提供了高可用性，但这也可能引入有关复制和一致性的问题。平台通过使用法定数量的存储节点来处理此问题，这些存储节点批准或拒绝主节点向其呈现的任何更改。为了获得最佳性能，连接管理器应尽可能通过分配连接以尽可能少地访问相同页面来避免写入冲突。
默认情况下，Aurora使用写后读写一致性，如果在写入器写入其信息的同一节点上完成读取数据，则读取数据是一致的。同步此写入可能需要几毫秒才能在其他节点上达到一致性。此外，多主集群在会话级别提供另一种称为全局读写后（GRAW）的选项。使用GRAW，无论哪个节点更新了这一点，都可以只看到一致的数据。实施这些措施确实会带来性能损失，因此亚马逊建议仅将此应用于需要此行为的特定查询。
