Amazon Aurora
Aurora 用户指南 (API 版本 2014-10-31)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

使用 Amazon Aurora MySQL 进行复制

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

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

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

使用 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 的复制选项

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

注意

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

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

从 Aurora MySQL 1.17.4 开始,以下功能可以帮助您微调 Aurora MySQL 复制性能。

"副本日志压缩"功能自动降低复制消息的网络带宽。由于每条消息将传输到所有 Aurora 副本,因此,较大的集群的好处更大。该功能在写入方节点上产生一些 CPU 开销以执行压缩。因此,该功能仅适用于具有较高 CPU 容量的 8xlarge16xlarge 实例类。默认情况下,将在这些实例类上启用该功能。您可以禁用 aurora_enable_replica_log_compression 参数以控制该功能。例如,如果写入方节点接近最大 CPU 容量,您可能会为较大的实例类禁用副本日志压缩。

"binlog 筛选"功能自动降低复制消息的网络带宽。由于 Aurora 副本不使用复制消息中包含的 binlog 信息,因此,将从发送到这些节点的消息中省略该数据。您可以更改 aurora_enable_repl_bin_log_filtering 参数以控制该功能。默认情况下,该参数为 on。由于该优化应该是透明的,因此,您只能在诊断或故障排除期间禁用该设置以解决与复制相关的问题,例如,与无法使用该功能的旧 Aurora MySQL 集群的行为相符。

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

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

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

从 Aurora MySQL 1.17.4 开始,以下功能有助于确保高可用性,甚至在重新启动副本的这些间隔内。

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

监控 Amazon Aurora MySQL 复制

读取扩展和高可用性依赖于尽可能短的滞后时间。您可以通过监控 Amazon CloudWatch ReplicaLag 指标来监控 Aurora 副本滞后于 Aurora MySQL 数据库集群主实例的时间。由于 Aurora 副本从主实例所在的同一个集群卷读取数据,因此 ReplicaLag 指标对于 Aurora MySQL 数据库集群有不同的含义。Aurora 副本的 ReplicaLag 指标表示 Aurora 副本的页面缓存相较主实例页面缓存的滞后时间。

如果需要 Aurora 副本滞后的最新值,可在您的 Aurora MySQL 数据库集群中查询 mysql.ro_replica_status 表并查看 Replica_lag_in_msec 列中的值。此列值作为 ReplicaLag 指标值提供给 Amazon CloudWatch。Aurora MySQL 数据库集群中的 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表中还提供了 mysql.ro_replica_status 中的值。

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