如果解决我在 Aurora MySQL 兼容版数据库实例中使用只读副本时遇到的问题？

解决方法

升级 Aurora MySQL 兼容版只读副本

如果写入器实例需要重启或维护，请执行手动失效转移，以将只读副本升级为写入器实例。

要执行手动失效转移，请完成以下步骤：

1. 打开 Amazon RDS 控制台。
2. 在导航窗格中，选择 Databases（数据库）。
3. 为您的 Aurora 数据库集群选择写入器实例。
4. 选择 Actions（操作），然后选择 Failover（失效转移）。

如果写入器实例不可用，Aurora MySQL 兼容版将自动失效转移到只读副本实例。写入器实例可能由于多种原因而不可用，例如资源争用或维护活动。

如果您有多个读取器，请为集群中的每个实例指定升级优先级层。当写入器实例出现故障时，Aurora MySQL 兼容版会将优先级最高的副本升级为新写入器。

您还可以将跨 AWS 区域 Aurora 副本升级为独立的数据库集群。开始升级流程后，跨区域复制将停止。升级后的集群将作为独立的数据库集群运行，并管理读取和写入操作。

测量复制延迟

由于数据库集群中的所有 Aurora 数据库实例共用数据量，因此复制延迟最小。但是，在某些情况下，读取器的延迟可能会略有增加。

**注意：**跨区域副本使用二进制日志复制。更改和应用所选区域之间网络通信的速率和延迟可能会影响跨区域副本。使用 Aurora MySQL 数据库的跨区域副本的延迟通常小于 1 秒。

要测量复制延迟，请使用以下 Amazon CloudWatch 指标：

• AuroraReplicaLag 指标以毫秒为单位测量同一区域内写入器和读取器节点之间的副本延迟。
• AuroraBinlogReplicaLag 指标测量使用二进制日志的 Aurora 数据库集群之间的副本延迟。

有关上述指标的详细信息，请参阅 Amazon Aurora 的实例级指标。

提高复制性能

执行以下操作：

• 为避免读取器实例的工作负载太大，最佳做法是将集群中的所有实例设置为相同大小。如果读取器实例小于写入器实例，更改量会过大，导致读取器无法赶上。
  **注意：**如果写入器实例的工作负载很大，您可能会注意到暂时的只读副本延迟。当读取器实例赶上写入器实例后，延迟会减少。
• 为避免长时间运行的事务在运行时出现复制延迟，请以较小的批次运行事务并频繁提交。

有关如何使用基于二进制日志的本机 MySQL 复制来解决副本延迟问题的信息，请参阅 Amazon Aurora MySQL 复制问题。

对高复制延迟进行故障排除

使用 AuroraReplicaLag CloudWatch 指标来检查高复制延迟。高复制延迟可能会导致读取器实例重启。要解决此问题，请参阅我的 Amazon Aurora 只读副本为什么会滞后并重新启动？

设置基于 GTID 的复制

Aurora 不使用本机二进制日志复制来将数据复制到只读副本实例。您不能使用全局事务标识符 (GTID) 在同一集群中的实例之间复制数据。但是，在某些情况下，您可以设置基于 GTID 的复制。有关如何在 Aurora MySQL 兼容版中使用基于 GTID 的复制的更多信息，请参阅 Amazon Aurora for MySQL 兼容性现在支持全局事务标识符 (GTID) 复制。

对于 Aurora MySQL 兼容版 3.04 及更高版本，默认情况下，多线程二进制日志复制已激活，且 replica_parallel_workers 设置为 4。由于多线程二进制日志复制已激活，因此必须提高数据库在意外停机时的弹性。最佳做法是在源上激活 GTID 复制并允许在副本上使用 GTID。

**注意：**您可以在 Amazon Relational Database Service (Amazon RDS) for MySQL 与 Aurora 集群之间以及各 Aurora 集群之间设置基于 GTID 的复制。源必须是外部主服务器。在开始复制过程之前，请务必在源上激活二进制日志记录。

有关 GTID 的更多信息，请参阅 MySQL 网站上的 GTID format and storage（GTID 格式和存储）。

相关信息

跨 AWS 区域复制 Amazon Aurora MySQL 数据库集群

使用 Amazon Aurora 复制