使用 Aurora 多主集群

接下来，您可以了解 Aurora 多主集群。在多主集群中，所有数据库实例都具有读/写功能。与单主集群相比，多主集群具有不同的可用性特征、对数据库功能的支持以及用于监控和故障排除的过程。

Aurora 多主集群概述

在设置新 Aurora 集群时，使用以下背景信息可帮助您选择多主集群或单主集群。为了让您做出明智的选择，我们建议您首先了解计划如何调整架构设计和应用程序逻辑，以便最好地与多主集群配合使用。

对于每个新 Amazon Aurora 集群，您可以选择是创建单主集群还是多主集群。

大多数类型的 Aurora 集群都是单主 集群。例如，预置集群、Aurora Serverless 集群、并行查询集群和全局数据库集群都是单主集群。在单主集群中，一个数据库实例执行所有写操作，任何其他数据库实例都是只读的。如果写入器数据库实例不可用，则故障转移机制会将其中一个只读实例提升为新的写入器。

在多主集群 中，所有数据库实例都可以执行写操作。单个读/写主实例和多个只读 Aurora 副本的概念不适用。当写入器数据库实例不可用时，不会发生任何故障转移，因为另一个写入器数据库实例可以立即接管失败实例的工作。我们将这种类型的可用性称为持续可用性，以区别于单主集群提供的高可用性（故障转移期间有短暂的停机时间）。

多主集群在许多方面与其他类型的 Aurora 集群不同，例如预置集群、Aurora Serverless 集群和并行查询集群。利用多主集群，您可以在高可用性、监控、连接管理和数据库功能等方面考虑不同的因素。例如，在您无法承受数据库写入操作的短暂停机时间的应用程序中，多主集群可以帮助避免在写入器实例变得不可用时发生中断。多主集群不使用故障转移机制，因为它不需要提升另一个数据库实例以具有读/写功能。利用多主集群，您可以检查与所有数据库实例而不是单个主实例的 DML 吞吐量、延迟和死锁相关的指标。

目前，多主集群需要 Aurora MySQL 版本 1，该版本与 MySQL 5.6 兼容。在 Amazon Web Services Management Console、Amazon CLI 或 RDS API 中指定数据库引擎版本时，请选择 5.6.10a。

要创建多主集群，您可以在创建集群时选择 Database features (数据库功能) 下的 Multiple writers (多个写入器)。与其他类型的 Aurora 集群相比，这样做可以在数据库实例、可用性和性能之间实现不同的复制行为。此选择对集群的生命周期仍有效。确保您了解适合于多主集群的专用案例。

多主集群术语

通过学习以下定义，您可以了解有关多主集群的术语。这些术语在多主集群的整个文档中都有使用。

多主集群架构

多主集群具有不同于其他类型的 Aurora 集群的架构。在多主集群中，所有数据库实例都具有读/写功能。其他类型的 Aurora 集群有一个执行所有写操作的专用数据库实例，而所有其他数据库实例都是只读的，并且仅处理 SELECT 查询。多主集群没有主实例或只读 Aurora 副本。

应用程序控制哪些写请求由哪个数据库实例处理。因此，利用多主集群，您可以连接到单个实例终端节点来发出 DML 和 DDL 语句。这与其他类型的 Aurora 集群不同，在这些集群中，通常将所有写操作指向单个集群终端节点，并将所有读操作指向单个读取器终端节点。

Aurora 多主集群的底层存储类似于单主集群的存储。您的数据仍存储在一个高度可靠且自动增长的共享存储卷中。核心差异在于数据库实例的数量和类型。在多主集群中，有 N 个读/写节点。目前，N 的最大值为 4。

多主集群没有专用的只读节点。因此，有关 Aurora 副本的 Aurora 过程和准则不适用于多主集群。您可以临时将数据库实例设置为只读，以将读写工作负载放在不同的数据库实例上。为此，请参阅 使用实例只读模式。

使用低延迟和低滞后 Aurora 复制连接多主集群节点。多主集群使用全对等复制。复制直接在写入器之间进行。每个写入器均会将其更改复制到所有其他写入器。

多主集群中的数据库实例独立地处理重新启动和恢复操作。如果一个写入器重新启动，则不需要其他写入器也重新启动。有关详细信息，请参阅Aurora 多主集群的高可用性注意事项。

多主集群跟踪所有数据库实例中数据的所有更改。度量单位是数据页，其固定大小为 16 KB。这些更改包括对表数据、二级索引和系统表的修改。Aurora 内部管理任务也可能造成更改。在共享存储卷中与数据库实例内存中，Aurora 会确保为每个数据页保留的多个物理副本之间的一致性。

如果两个数据库实例几乎在同一时刻尝试修改同一数据页，则会发生写冲突。最早的更改请求是使用法定数量投票机制批准的。该更改将保存到永久存储中。未批准更改的数据库实例将回滚包含尝试更改的整个事务。回滚事务可确保数据保持一致状态，并且应用程序始终能看到可预测的数据视图。您的应用程序可以检测死锁情况并重试整个事务。

有关如何最大程度地减少写冲突和相关性能开销的详细信息，请参阅 多主集群的冲突解决。

建议的多主集群工作负载

多主集群最适合特定类型的工作负载。

主动/被动工作负载

利用主动/被动 工作负载，您可以一次在一个数据库实例上执行所有读写操作。您可以保留 Aurora 集群中的任何其他数据库实例。如果原始活动数据库实例变得不可用，则立即将所有读和写操作切换到另一个数据库实例。利用此配置，可以最大程度地减少写操作的任何停机时间。另一个数据库实例可以接管应用程序的所有处理，而无需执行故障转移。

主动/主动工作负载

利用主动/主动 工作负载，您可以同时对所有数据库实例执行读和写操作。在此配置中，通常会对工作负载进行分段，以便不同的数据库实例不会同时修改相同的基础数据。这样做可最大程度地降低发生写冲突的可能性。

多主集群可以很好地与专为分段工作负载 设计的应用程序逻辑配合使用。在此类工作负载中，您可以按数据库实例、数据库、表或表分区划分写操作。例如，您可以在同一个集群上运行多个应用程序，每个应用程序均分配给一个特定的数据库实例。或者，您可以运行一个使用多个小型表的应用程序，例如为在线服务的每个用户使用一个表。理想情况下，您可以设计架构，以便不同的数据库实例的写操作不会同时更新同一表中的重叠行。分片应用程序就是此类架构的一个例子。

有关主动/主动工作负载的设计的示例，请参阅 将多主集群用于分片数据库。

多主集群的优势

您可以利用 Aurora 多主集群的以下优势：

多主集群的限制

Amazon和 Aurora 限制

以下限制当前适用于Amazon以及可用于多主集群的 Aurora 功能：

数据库引擎限制

以下限制适用于可用于多主集群的数据库引擎功能：

从多主集群迁移

从 Aurora 多主集群迁移意味着更改回 Aurora 单主数据库集群。请使用 Amazon Database Migration Service (Amazon DMS) 之类的工具或 mysqldump 命令生成的逻辑转储。

创建 Aurora 多主集群

您无法再使用 Amazon Web Services Management Console创建 Aurora 多主数据库集群。使用 Amazon CLI 或 RDS API。如果您之前未创建任何 Aurora 集群，则可了解 创建 Amazon Aurora 数据库集群 中的一般过程。

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora \
    --engine-version 5.6.10a --master-username user_name --master-user-password password \
    --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id \
    --engine-mode multimaster

aws rds create-db-cluster --db-cluster-identifier sample-cluster --engine aurora ^
    --engine-version 5.6.10a --master-username user_name --master-user-password password ^
    --db-subnet-group-name my_subnet_group --vpc-security-group-ids my_vpc_id ^
    --engine-mode multimaster

向 Aurora 多主集群添加数据库实例

您需要多个数据库实例才能看到 Aurora 多主集群的优势。创建第一个实例后，您可以创建其他数据库实例，最多可创建四个数据库实例。多主集群的区别在于新数据库实例具有读/写功能而不是只读 Aurora 副本。

控制台

您可以使用 Amazon Web Services Management Console同时向多主数据库集群添加两个初始写入器数据库实例。后续的数据库实例将单独添加。

Amazon CLI 或 RDS API

使用 Amazon CLI 或 RDS API 可一次添加一个写入器数据库实例。按照将 Aurora 副本添加到数据库集群中的常规程序进行操作。

以下 Amazon CLI 示例向 Aurora 多主数据库集群添加写入器实例。

对于 Linux、macOS 或 Unix：

aws rds create-db-instance \
    --db-instance-identifier mm-cluster2-instance \
    --db-cluster-identifier mm-cluster2 \
    --db-instance-class db.r4.2xlarge \
    --engine aurora

对于 Windows：

aws rds create-db-instance ^
    --db-instance-identifier mm-cluster2-instance ^
    --db-cluster-identifier mm-cluster2 ^
    --db-instance-class db.r4.2xlarge ^
    --engine aurora

管理 Aurora 多主集群

您对 Aurora 多主集群进行大多数管理的方式与其他类型的 Aurora 集群相同。以下部分介绍了用于管理的多主集群的差异和独特功能。

监控 Aurora 多主集群

多主集群还支持 MySQL 和 Aurora 单主集群支持的大多数监控和诊断功能：

Aurora 多主集群目前不支持以下监控功能：

多主集群的数据摄取性能

在多主集群上进行 DML 操作的一个最佳实践是使事务保持小而简短。此外，将特定表或数据库的写操作路由到特定数据库实例。进行批量导入可能需要放松对事务大小的指导。但是，您仍可以分发写操作以最大程度地降低发生写冲突的可能性。

您可以使用以下方法将数据导入 Aurora 多主集群中：

有关迁移方法和建议的详细讨论，请参阅 Amazon Aurora 迁移手册 Amazon 白皮书。该手册中列出的某些迁移方法可能不适用于 Aurora 多主集群，但该文档是有关 Aurora 迁移主题的知识的总体来源。

从多主集群导出数据

您可以保存多主集群的快照并将其还原到另一个多主集群。目前，您无法将多主集群快照还原到单主集群中。

要将数据从多主集群迁移到单主集群，请使用逻辑转储并使用 mysqldump 等工具进行还原。

无法将多主集群用作二进制日志复制的源或目标。

Aurora 多主集群的高可用性注意事项

在 Aurora 多主集群中，任何数据库实例都可以重新启动，而不会导致任何其他实例重新启动。与 Aurora 单主集群相比，此行为为读/写和只读连接提供了更高级别的可用性。我们将此可用性级别称为连续可用性。在多主集群中，当写入器数据库实例失败时，写可用性没有停机时间。多主集群不使用故障转移机制，因为所有集群实例都是可写的。如果数据库实例在多主集群中失败，则您的应用程序可以将工作负载重定向到剩余的正常实例。

在单主集群中，重新启动主实例会使写操作不可用，直到故障转移机制提升新的主实例。只读操作也会遇到短暂的停机时间，因为集群中的所有 Aurora 副本都会重新启动。

要最大程度地减少多主集群中的应用程序的停机时间，请执行频繁的 SQL 级别运行状况检查。如果多主集群中的数据库实例变得不可用，您可以根据预期的中断长度和工作负载中写操作的紧急程度来决定要执行的操作。如果您希望中断很短且写操作不紧急，则可以等待数据库实例恢复，然后再恢复通常由该数据库实例处理的工作负载。或者，您可以将该工作负载重定向到其他数据库实例。基础数据始终对集群中的所有数据库实例可用。即使在不太可能发生影响整个可用区的故障的情况下，高度分布的 Aurora 存储卷也可以使数据持续可用。有关从不可用的数据库实例切换写操作的计时注意事项的信息，请参阅 将多主集群用作活动备用。

多主集群和其他集群之间的复制

多主集群不支持传入或传出二进制日志复制。

升级多主集群

Aurora 多主集群使用与其他类型的 Aurora 集群相同的版本编号方案，包括主版本号和次要版本号。不过，Enable auto minor version upgrade (启用自动次要版本升级) 设置不适用于多主集群。

在升级 Aurora 多主集群时，升级过程通常会将数据库引擎从当前版本移至下一个更高版本。如果升级到版本号增加 1 以上的 Aurora 版本，则升级将使用多步骤方法。每个数据库实例均升级到下一个更高版本，然后是下一个更高版本，依此类推，直到达到指定的升级版本。

根据旧版本和新版本之间是否存在任何向后不兼容的更改，该方法会有所不同。例如，对系统架构的更新被视为向后不兼容的更改。您可以通过参阅发布说明来检查特定版本是否包含任何向后不兼容的更改。

如果旧版本和新版本之间没有任何不兼容的更改，则会单独升级和重新启动每个数据库实例。升级是交错进行的，因此整个集群不会遇到任何停机时间。在升级过程中，至少有一个数据库实例随时可用。

如果旧版本和新版本之间存在不兼容的更改，则 Aurora 将在脱机模式下执行升级。所有集群节点都会同时升级和重新启动。集群会经历一些停机时间，以避免旧引擎写入较新的系统表。

Aurora 多主集群目前不支持零停机时间修补 (ZDP)。

Aurora 多主集群的应用程序注意事项

接下来，您可以了解应用程序中可能需要进行的任何更改，因为多主机集群和单主机集群之间的功能支持或行为存在差异。

多主集群的 SQL 注意事项

以下是适用于可与多主集群结合使用的 SQL 语言功能的主要限制：

在为 Aurora 多主集群调整应用程序时，请将该活动作为迁移处理。您可能必须停止使用某些 SQL 功能，并更改其他 SQL 功能的应用程序逻辑：

多主集群的连接管理

多主集群的主要连接注意事项是可用的 DNS 终端节点的数量和类型。对于多主集群，您经常使用实例终端节点，这些终端节点很少用于其他类型的 Aurora 集群。

Aurora 多主集群具有以下类型的终端节点：

多主集群没有读取器终端节点。在可行的情况下，使用通常写入同一表的相同数据库实例终端节点发出 SELECT 查询。这样做可以更有效地使用缓冲池中的缓存数据，并避免因集群内的复制滞后而导致的过时数据的潜在问题。如果您没有在写入相同表的相同数据库实例上找到 SELECT 语句，并且您需要对某些查询进行严格的先写后读保证，请考虑使用 多主集群的一致性模型 中所述的全局先写后读 (GRAW) 机制来运行这些查询。

有关 Aurora 和 MySQL 连接管理的一般最佳实践，请参阅 Amazon Aurora 迁移手册Amazon白皮书。

有关如何在多主数据库集群中模拟只读数据库实例的信息，请参阅 使用实例只读模式。

在创建自定义 DNS 终端节点并为 Aurora 多主集群设计驱动程序和连接器时，请遵循以下准则：

多主集群的一致性模型

Aurora 多主集群支持可在会话级别配置的全局先写后读 (GRAW) 模式。此设置引入了额外同步，以便为每个查询创建一致性读取视图。这样一来，查询始终能看到最新数据。默认情况下，多主集群中的复制滞后意味着在数据更新之后，数据库实例可能会在几毫秒内看到旧数据。如果您的应用程序依赖于查看任何其他数据库实例所做的最新数据更改的查询，则启用此功能，即使必须等待查询结果也是如此。

在使用 GRAW 模式时，默认情况下不要为所有查询启用它。全局一致性读取明显慢于本地读取。因此，选择性地将 GRAW 用于需要它的查询。

请注意这些有关使用 GRAW 的注意事项：

多主集群和事务

标准 Aurora MySQL 指南适用于 Aurora 多主集群。Aurora MySQL 数据库引擎已针对短期 SQL 语句进行优化。这些类型的语句通常与在线事务处理 (OLTP) 应用程序关联。

特别是，使您的写事务尽可能短。这样做可降低发生写冲突的可能性。冲突解决机制是乐观的，这意味着它在写冲突很少时表现最佳。权衡的结果是，当冲突发生时，它们会产生大量开销。

一些工作负载可以从大型事务中受益。例如，当使用多 MB 事务而不是单语句事务运行时，批量数据导入的速度要快得多。如果在运行此类工作负载时发现冲突数量是不可接受的，请考虑以下选项：

多主集群中的写冲突和死锁

多主集群的一个重要性能方面是写冲突的频率。当 Aurora 存储子系统中出现此类问题时，您的应用程序会收到死锁错误，并对死锁情况进行常见错误处理。Aurora 使用无锁的乐观算法，该算法在此类冲突很少发生时表现最佳。

在多主集群中，所有数据库实例都可对共享存储卷进行写入。对于您修改的每个数据页，Aurora 自动在多个可用区 (AZ) 中分发多个副本。当多个数据库实例尝试在很短的时间内修改同一数据页时，会发生写冲突。Aurora 存储子系统在完成写操作之前检测到更改重叠并解决冲突。

Aurora 检测物理数据页面级别的写冲突，此数据页面的固定大小为 16 KiB。因此，即使更改影响不同的行，如果这些行都在同一个数据页中，也会发生冲突。

当发生冲突时，清理操作需要额外的工作来撤消来自某个数据库实例的更改。从应用程序的角度来看，引发冲突的事务会遇到死锁，并且 Aurora 会回滚整个事务。您的应用程序收到错误代码 1213。

撤消事务可能需要修改其更改已应用于 Aurora 存储子系统的许多其他数据页。根据事务更改的数据量，撤消事务可能会产生大量开销。因此，最大程度减小写冲突的可能性是 Aurora 多主集群的关键设计考虑因素。

一些冲突是由您发起的更改造成的。这些更改包括 SQL 语句、事务和事务回滚。您可以通过应用程序中的架构设计和连接管理逻辑来最大程度地减少这些类型的冲突。

发生其他冲突的原因是，SQL 语句和内部服务器线程同时发生了更改。这些冲突很难预测，因为它们依赖于您可能不知道的内部服务器活动。导致这些冲突的两种主要内部活动是垃圾回收（称为清除），以及由 Aurora 自动执行的事务回滚。例如，Aurora 在崩溃恢复期间或客户端连接丢失时自动执行回滚。

事务回滚会物理还原已进行的页面更改。回滚会像原始事务一样产生页面更改。回滚需要时间，可能是原始事务的几倍。当回滚正在进行时，它产生的更改可能会与您的事务发生冲突。

垃圾回收与多版本并发控制 (MVCC) 有关，它是 Aurora MySQL 事务引擎使用的并发控制方法。利用 MVCC，数据更改会创建新的行版本，并且数据库会保留多个版本的行以实现事务隔离，同时允许对数据进行并发访问。当不再需要行版本时，将删除（清除）它们。同样，清除过程会产生页面更改，这可能会与您的事务发生冲突。根据工作负载，数据库可以产生清除滞后：等待垃圾回收的更改队列。如果滞后显著增加，即使您停止提交 SQL 语句，数据库也可能需要相当长的时间才能完成清除。

如果内部服务器线程遇到写冲突，则 Aurora 会自动重试。相反，应用程序必须处理任何遇到冲突的事务的重试逻辑。

当来自同一数据库实例的多个事务导致这些类型的重叠更改时，Aurora 将使用标准事务并发规则。例如，如果同一数据库实例上的两个事务修改同一行，则其中一个事务将等待。如果等待时间长于配置的超时时间（innodb_lock_wait_timeout，默认为 50 秒），则等待事务将中止，并显示“Lock wait timeout exceeded (超过锁定等待超时)”消息。

多主集群和锁定读取

Aurora 多主集群支持以下形式的锁定读取。

SELECT ... FOR UPDATE
SELECT ... LOCK IN SHARE MODE

有关锁定读取的更多信息，请参阅 MySQL 参考手册。

所有节点都支持锁定读操作，但锁定范围对于运行此命令的节点是本地的。在一个写入器上执行的锁定读取不会阻止其他写入器访问或修改锁定的行。尽管有此限制，您仍然可以在保证写入器之间的严格工作负载范围隔离的使用案例中使用锁定读取，例如在分片数据库或多租户数据库中。

请考虑以下准则：

使用 aurora_mm_session_consistency_level 会话变量控制先写后读功能。有效值为 INSTANCE_RAW（对于本地一致性模式）（ 默认值）和 REGIONAL_RAW（对于集群范围内的一致性）：

对多主集群执行 DDL 操作

SQL 数据定义语言 (DDL) 语句对多主集群有特殊注意事项。这些语句有时会导致基础数据的重大重组。此类大规模更改可能会影响共享存储卷中的许多数据页。针对表和其他架构对象的定义保存在 INFORMATION_SCHEMA 表中。Aurora 会专门处理对这些表的更改，以免在多个数据库实例同时运行 DDL 语句时发生写入冲突。

对于 DDL 语句，Aurora 自动将语句处理委派给集群中的一个特殊服务器进程。由于 Aurora 将更改集中到 INFORMATION_SCHEMA 表中，因此，此机制将消除 DDL 语句之间发生写冲突的可能性。

DDL 操作会阻止对该表进行的并发写入。在对表执行 DDL 操作期间，多主集群中的所有数据库实例都限制为对该表的只读访问，直到 DDL 语句完成。

以下 DDL 行为在 Aurora 单主集群和多主集群中相同：

请注意多主集群中的以下 DDL 性能注意事项：

将 Percona Online Schema Change 与多主集群结合使用

pt-online-schema-change 工具使用多主集群。如果您的优先级是以最无阻塞的方式运行表修改，则可以使用它。但是，请注意架构更改过程的写冲突含义。

概括来说，pt-online-schema-change 工具的工作方式如下所示：

在将数据传输到新表时，可能会出现争用点。最初创建新表时，它完全为空，因此会成为锁定热点。在其他类型的数据库系统中也是如此。由于触发器是同步的，因此，来自热点的影响可传播回查询。

在多主集群中，影响会更明显。这种可见性是因为新表不仅引发锁争用，而且增大了发生写冲突的可能性。该表最初只有很少的页面，这意味着写入是高度本地化的，因此容易发生冲突。在表增长之后，写操作应展开，并且写冲突应不再成为问题。

可以将该在线架构更改工具与多主集群结合使用。不过，它可能需要更仔细的测试，并且在操作的最初几分钟，它对正在进行的工作负载的影响可能会略微明显一些。

使用自动递增列

Aurora 多主集群使用现有配置参数 auto_increment_increment 和 auto_increment_offset 处理自动递增列。有关更多信息，请参阅 MySQL 参考手册。

参数值是预先确定的，无法更改。具体来说，auto_increment_increment 参数已硬编码为 16，这是任何类型的 Aurora 集群中的数据库实例的最大数目。

由于硬编码的递增设置，自动递增值的使用速度比在单主集群中快得多。即使给定的表仅由单个数据库实例修改过，也是如此。要获得最佳结果，请始终对自动递增列使用 BIGINT 数据类型而非 INT。

在多主集群中，您的应用程序逻辑必须准备好容忍具有以下属性的自动递增列：

以下示例说明多主集群中自动递增值的序列与预期的不同。

mysql> create table autoinc (id bigint not null auto_increment, s varchar(64), primary key (id));

mysql> insert into autoinc (s) values ('row 1'), ('row 2'), ('row 3');
Query OK, 3 rows affected (0.02 sec)

mysql> select * from autoinc order by id;
+----+-------+
| id | s     |
+----+-------+
|  2 | row 1 |
| 18 | row 2 |
| 34 | row 3 |
+----+-------+
3 rows in set (0.00 sec)

您可以更改 AUTO_INCREMENT 表属性。只有当非默认值大于表中已有的任何主键值时，才能可靠地使用该值。不能使用较小的值来填充表中的空间隔。如果这样做的话，更改将暂时生效或根本不生效。此行为继承自 MySQL 5.6，并且不特定于 Aurora 实现。

多主集群功能参考

接下来，您可以查找特定于 Aurora 多主集群的命令、过程和状态变量的快速参考。

使用先写后读功能

使用 aurora_mm_session_consistency_level 会话变量控制先写后读功能。有效值为 INSTANCE_RAW（对于本地一致性模式）（ 默认值）和 REGIONAL_RAW（对于集群范围内的一致性）。

下面是一个示例。

mysql> select @@aurora_mm_session_consistency_level;
+---------------------------------------+
| @@aurora_mm_session_consistency_level |
+---------------------------------------+
| INSTANCE_RAW                          |
+---------------------------------------+
1 row in set (0.01 sec)
mysql> set session aurora_mm_session_consistency_level = 'REGIONAL_RAW';
Query OK, 0 rows affected (0.00 sec)
mysql> select @@aurora_mm_session_consistency_level;
+---------------------------------------+
| @@aurora_mm_session_consistency_level |
+---------------------------------------+
| REGIONAL_RAW                          |
+---------------------------------------+
1 row in set (0.03 sec)

检查数据库实例读写模式

在多主集群中，所有节点都在读/写模式下运行。innodb_read_only 变量始终返回零。以下示例说明当您连接到多主集群中的任何数据库实例时，数据库实例会报告它具有读/写功能。

$ mysql -h mysql -A -h multi-master-instance-1.example123.us-east-1.rds.amazonaws.com
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  0 |
+--------------------+
mysql> quit;
Bye

$ mysql -h mysql -A -h multi-master-instance-2.example123.us-east-1.rds.amazonaws.com
mysql> select @@innodb_read_only;
+--------------------+
| @@innodb_read_only |
+--------------------+
|                  0 |
+--------------------+

检查节点名称和角色

您可以使用 aurora_server_id 状态变量检查当前连接到的数据库实例的名称。下面的示例演示如何操作。

mysql> select @@aurora_server_id;
+----------------------+
| @@aurora_server_id   |
+----------------------+
| mmr-demo-test-mm-3-1 |
+----------------------+
1 row in set (0.00 sec)

要查找多主集群中所有数据库实例的此信息，请参阅 描述集群拓扑。

描述集群拓扑

您可以通过从 information_schema.replica_host_status 表中进行选择来描述多主集群拓扑。多主集群与单主集群的区别如下：

下面是一个示例。

mysql> select server_id, has_primary, replica_lag_in_milliseconds, last_reported_status
    -> from information_schema.replica_host_status;
+----------------------+-------------+-----------------------------+----------------------+
| server_id            | has_primary | replica_lag_in_milliseconds | last_reported_status |
+----------------------+------------------+------------------------+----------------------+
| mmr-demo-test-mm-3-1 | true        |                      37.302 | Online               |
| mmr-demo-test-mm-3-2 | false       |                      39.907 | Online               |
+----------------------+-------------+-----------------------------+----------------------+

使用实例只读模式

在 Aurora 多主集群中，通常会向特定的数据库实例发出 SELECT 语句，该实例对关联的表执行写操作。这样做可以避免因复制滞后导致的一致性问题，并最大程度地重用缓冲池中的表和索引数据。

如果需要跨多个表运行查询密集型工作负载，则可将多主集群中的一个或多个数据库实例指定为只读。

要在运行时将整个数据库实例置于只读模式中，请调用 mysql.rds_set_read_only 存储过程。

mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)
mysql> call mysql.rds_set_read_only(1);
Query OK, 0 rows affected (0.00 sec)
mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           1 |
+-------------+
1 row in set (0.00 sec)
mysql> call mysql.rds_set_read_only(0);
Query OK, 0 rows affected (0.00 sec)
mysql> select @@read_only;
+-------------+
| @@read_only |
+-------------+
|           0 |
+-------------+
1 row in set (0.00 sec)

调用此存储过程等同于运行 SET GLOBAL read_only = 0|1。该设置仅为运行时设置，且不能在引擎重启后继续运行。通过在数据库实例的参数组中将 read_only 参数设置为 true，可以将数据库实例永久设置为只读。

Aurora 多主集群的性能注意事项

对于单主集群和多主集群，Aurora 引擎已针对 OLTP 工作负载进行优化。OLTP 应用程序主要由具有高选择性、随机访问查询的短期事务组成。借助同时运行许多此类操作的工作负载，您可以从 Aurora 获得最大优势。

避免始终以 100% 的利用率运行。这样做可让 Aurora 跟上内部维护工作。要了解如何测量多主集群的繁忙程度以及需要的维护工作量，请参阅 监控 Aurora 多主集群。

多主集群的查询性能

多主集群不提供专用的只读节点或只读 DNS 终端节点，但可以创建只读数据库实例组并将其用于预期目的。有关更多信息，请参阅“使用实例只读模式”。

您可以使用以下方法来优化多主集群的查询性能：

多主集群的冲突解决

多主集群的许多最佳实践都侧重于降低发生写冲突的可能性。解决写冲突涉及到网络开销。您的应用程序还必须处理错误情况并重试事务。如果可能，请尝试最大程度地减少这些不必要的后果：

在页面级别检测冲突。由于来自不同的数据库实例的建议更改会修改页面中的不同行，因此可能会发生冲突。系统中引入的所有页面更改都将进行冲突检测。无论源是用户事务还是服务器后台进程，此规则都将适用。无论数据页是来自表、二级索引、撤消空间等，此规则也将适用。

您可以划分写操作，以便每个数据库实例处理一组架构对象的所有写操作。在此情况下，每个数据页面的所有更改都由一个特定实例进行。

优化缓冲池和词典缓存使用

多主集群中的每个数据库实例都维护单独的内存缓冲区和缓存，例如缓冲池、表处理程序缓存和表词典缓存。对于每个数据库实例，缓冲区和缓存的内容和周转量取决于该实例处理的 SQL 语句。

有效使用内存可帮助提高多主集群的性能并降低 I/O 成本。使用分片设计可物理分隔数据并从特定数据库实例对每个分片进行写入。这样做可在每个数据库实例上最有效地使用缓冲区缓存。尝试将表的 SELECT 语句分配给执行该表的写操作的同一数据库实例。这样做可帮助这些查询在该数据库实例上重用缓存数据。如果您有大量表或分区，则此技术还会减少每个数据库实例在内存中保留的唯一表处理程序和词典对象的数量。

Aurora 多主集群的方法

在以下部分中，您可以找到适用于多主集群的特定部署的方法。这些方法涉及划分工作负载的方式，以便数据库实例对不重叠的数据部分执行写操作。这样做可最大程度地降低发生写入冲突的可能性。写冲突是多主集群的性能调优和故障排除的主要焦点。

将多主集群用于分片数据库

分片是一种流行的架构设计，能很好地适用于 Aurora 多主集群。在分片架构中，分配每个数据库实例以更新一组特定的架构对象。这样一来，多个数据库实例可对同一个共享存储卷进行写入，而不会因并发更改而产生冲突。每个数据库实例均可处理多个分片的写操作。您可以通过更新应用程序配置来随时更改数据库实例到分片的映射。执行此操作时，您无需重新组织数据库存储或重新配置数据库实例。

使用分片架构设计的应用程序非常适合与 Aurora 多主集群一起使用。数据在分片系统中的物理划分方式有助于避免写冲突。您将每个分片映射到架构对象，例如分区、表或数据库。您的应用程序将特定分片的所有写操作定向到相应的数据库实例。

自带分片 (BYOS) 描述了一个使用案例，其中您已拥有分片/分区数据库和能够访问该数据库的应用程序。分片在物理上已经是分离的。因此，您可以轻松地将工作负载移至 Aurora 多主集群，而无需更改架构设计。相同的简单迁移路径适用于多租户数据库，其中每个租户使用一个专用表、一组表或整个数据库。

您可以将分片或租户以一对一或多对一的方式映射到数据库实例。每个数据库实例处理一个或多个分片。分片设计主要适用于写操作。您可以从具有相同性能的任何数据库实例发出对任何分片的 SELECT 查询。

假设您将多主集群用于分片游戏应用程序。您可以分发工作，以便特定的数据库实例执行数据库更新，这具体取决于玩家的用户名。您的应用程序会处理将每个播放器映射到相应的数据库实例并连接到该实例的终端节点的逻辑。每个数据库实例均可处理多个不同分片的写操作。您可以向任何数据库实例提交查询，因为只有在写操作期间才会发生冲突。您可以指定一个数据库实例来执行所有 SELECT 查询，以最大限度地减少执行写入操作的数据库实例的开销。

假设随着时间的推移，其中一个分片变得更加活跃。要重新平衡工作负载，可以切换负责该分片的数据库实例。在非 Aurora 系统中，您可能必须将数据物理移至其他服务器。利用 Aurora 多主集群，您可以通过将分片的所有写操作定向到具有未使用计算容量的其他数据库实例来重新进行此类分片。Aurora 共享存储模型避免了物理重新组织数据的需要。

使用不带分片的多主集群

如果架构设计未将数据细分为物理上独立的容器（例如数据库、表或分区），您仍可以在多主集群的数据库实例中分割 DML 语句之类的写操作。

您可能会看到一些性能开销，并且当写冲突被视为死锁条件时，您的应用程序可能必须处理偶尔的事务回滚。在对小型表执行写操作期间，更有可能发生写冲突。如果表包含很少的数据页，则主键范围的各个部分中的行可能位于同一数据页中。如果这些行由不同的数据库实例同时更改，则此重叠可能会导致写冲突。

在此情况下，您还应最大程度地减少二级索引的数量。在对表中的索引列进行更改时，Aurora 会在关联的二级索引中进行相应的更改。由于二级索引和关联表之间的行的顺序和分组不同，因此，更改索引可能会导致发生写冲突。

由于您在使用此技术时可能仍会遇到一些写冲突，因此 Amazon 建议您使用其他方法（如果可行）。查看您是否能使用将数据细分为不同架构对象的备用数据库设计。

将多主集群用作活动备用

活动备用 是与另一个数据库实例保持同步的数据库实例，可以很快地接管它。此配置有助于在单个数据库实例可以处理完整工作负载的情况下实现高可用性。

通过将所有流量（读/写和只读流量）定向到单个数据库实例，可以在活动的备用配置中使用多主集群。如果该数据库实例变得不可用，则应用程序必须检测问题并将所有连接切换到其他数据库实例。在此情况下，Aurora 不执行任何故障转移，因为其他数据库实例已可用于接受读/写连接。通过一次只对一个数据库实例进行写入，可以避免写冲突。因此，您无需使用分片数据库架构来以该方式使用多主集群。