aurora mysql_使用 Amazon Aurora MySQL 进行单主复制 - Amazon Aurora

使用 Amazon Aurora MySQL 进行单主复制

Aurora MySQL 复制功能是集群获得较高的可用性和性能的关键所在。Aurora 可以轻松创建或调整最多具有 15 个 Aurora 副本的集群。

所有副本采用相同的基础数据。如果某些数据库实例脱机，其他数据库实例将保持可用状态以继续处理查询或在需要时作为写入器接替这些实例。Aurora 自动将只读连接分布到多个数据库实例中，从而帮助

Aurora 集群支持查询密集型工作负载。

在下文中，您可以了解 Aurora MySQL 复制的工作方式以及如何微调复制设置以获得最佳的可用性和性能。

注意

接下来，您可以了解使用单主复制的 Aurora 集群的复制功能。这种集群是 Aurora 的默认设置。有关 Aurora 多主集群的信息，请参阅 使用 Aurora 多主集群。

使用 Aurora 副本

Aurora 副本是 Aurora 数据库集群中的独立终端节点，最适合用于扩展读取操作以及提高可用性。对于数据库集群在 AWS 区域中所跨的多个可用区，最多可以分配

15 个 Aurora 副本。虽然数据库集群卷由数据库集群的多个数据副本组成，但集群卷中的数据表示为数据库集群中的主实例和 Aurora 副本的单个逻辑卷。有关 Aurora

副本的更多信息，请参阅 Aurora 副本。

Aurora 副本十分适用于读取扩展，因为它们完全专用于集群卷上的读取操作。写入操作由主实例进行管理。由于集群卷是在 Aurora MySQL 数据库集群中的所有实例之间共享的，因此，无需执行额外的操作以复制每个

Aurora 副本的数据副本。相比之下，MySQL 只读副本必须在单一线程上，重放从源数据库实例向其本地数据存储的所有写入操作。此限制会影响到 MySQL 只读副本支持海量读取流量的能力。

对于 Aurora MySQL，在删除 Aurora 副本时，将立即删除其实例终端节点，并将 Aurora 副本从读取器终端节点中删除。如果在正待删除的 Aurora

副本上运行语句，则有 3 分钟宽限期。现有语句可在此宽限期内正常完成。当此宽限期结束后，将关闭并删除 Aurora 副本。

重要

对于在 InnoDB 表上执行的操作，Aurora MySQL 的 Aurora 副本始终使用 REPEATABLE READ 默认事务隔离级别。仅对于 Aurora MySQL 数据库集群的主实例，您可以使用 SET TRANSACTION ISOLATION LEVEL 命令更改事务级别。该限制避免在 Aurora 副本上出现用户级锁定，并允许 Aurora 副本扩展以支持数千个活动用户连接，同时仍保持最小的副本滞后时间。

注意

在主实例上运行的 DDL 语句可能会中断关联的 Aurora 副本上的数据库连接。如果 Aurora 副本连接主动使用数据库对象(如表)，并且使用 DDL 语句在主实例上修改该对象，则会中断

Aurora 副本连接。

注意

中国 (宁夏) 区域不支持跨区域只读副本。

Amazon Aurora MySQL 的复制选项

您可以在以下任意选项之间设置复制：

不同 AWS 区域中的两个 Aurora MySQL 数据库集群(通过在不同的 AWS 区域中创建 Aurora MySQL 数据库集群的 Aurora 只读副本)。

相同 AWS 区域中的两个 Aurora MySQL 数据库集群 (通过使用 MySQL 二进制日志 (binlog) 复制)。

一个 Amazon RDS MySQL 数据库实例(作为源)和一个 Aurora MySQL 数据库集群(通过创建 Amazon RDS MySQL 数据库实例的

Aurora 只读副本)。

注意

重新引导 Amazon Aurora 数据库集群的主实例还会自动重新引导该数据库集群的 Aurora 副本，以便重新建立入口点以确保数据库集群中的读/写一致性。

Amazon Aurora MySQL 复制的性能注意事项

以下功能可以帮助您微调 Aurora MySQL 复制性能。

从 Aurora MySQL 1.17.4 开始，副本日志压缩功能自动降低复制消息的网络带宽。由于每条消息将传输到所有 Aurora 副本，因此，较大的集群的好处更大。该功能在写入方节点上产生一些

CPU 开销以执行压缩。因此，该功能仅适用于具有较高 CPU 容量的 8xlarge 和 16xlarge 实例类。默认情况下，将在这些实例类上启用该功能。您可以禁用 aurora_enable_replica_log_compression 参数以控制该功能。例如，如果写入方节点接近最大 CPU 容量，您可能会为较大的实例类禁用副本日志压缩。

从 Aurora MySQL 1.17.4 开始，二进制日志筛选功能自动降低复制消息的网络带宽。由于 Aurora 副本不使用复制消息中包含的二进制日志信息，因此，将从发送到这些节点的消息中省略该数据。您可以更改

aurora_enable_repl_bin_log_filtering 参数以控制该功能。默认情况下，该参数为 on。由于该优化应该是透明的，因此，您只能在诊断或故障排除期间禁用该设置以解决与复制相关的问题。例如，与无法使用该功能的旧

Aurora MySQL 集群的行为相符。

Amazon Aurora MySQL 复制的高可用性注意事项

在集群中包含更多 Aurora 副本有助于确保高可用性。您始终可以查询具有完整数据副本的数据库实例，即使某些数据库实例变得不可用。

具有多个 Aurora 副本的缺点是，在重新启动基础数据库实例时，副本在短时间内不可用。在维护操作期间或在副本开始远远落后于源时，可能会发生这些重新启动。重新启动副本将会中断到相应数据库实例的现有连接。重新启动

Aurora 集群导致所有副本同时变得不可用。

以下功能有助于确保高可用性，甚至在重新启动副本的这些间隔内。

从 Aurora 1.17.4 开始，在重新启动 Aurora MySQL 副本时(例如，如果副本远远落后于源)，零停机时间重新启动 (ZDR) 功能将保留现有连接。将回滚任何打开的事务，您的应用程序必须重试该事务。要启用该功能，请在集群参数组中启用 aurora_enable_zdr 参数。默认情况下，该参数为 off。

监控 Amazon Aurora MySQL 复制

读取扩展和高可用性依赖于尽可能短的滞后时间。您可以通过监控 Amazon CloudWatch AuroraReplicaLag 指标来监控 Aurora 副本滞后于 Aurora MySQL 数据库集群主实例的时间。AuroraReplicaLag 指标记录在每个 Aurora 副本中。

主数据库实例还记录 AuroraReplicaLagMaximum 和 AuroraReplicaLagMinimum Amazon CloudWatch 指标。AuroraReplicaLagMaximum 指标记录主数据库实例与数据库集群中每个 Aurora 副本之间的最大滞后量。AuroraReplicaLagMinimum 指标记录主数据库实例与数据库集群中每个 Aurora 副本之间的最小滞后量。

如果需要 Aurora 副本滞后的最新值，可在您的 Aurora MySQL 数据库集群中的主实例上查询 mysql.ro_replica_status 表并查看 Replica_lag_in_msec 列中的值。此列值作为 AuroraReplicaLag 指标的值提供给 Amazon CloudWatch。Aurora 副本滞后也会记录在 Aurora MySQL 数据库集群中 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表中的每个 Aurora 副本上。

有关监控 RDS 实例和 CloudWatch 指标的更多信息，请参阅监控 Amazon Aurora 数据库集群。