如何解决在 Amazon Aurora 中使用只读副本时的常见问题？

简短描述

Amazon Aurora MySQL 支持与同一 AWS 区域中的写入器数据库实例共用常见基础卷的只读副本。如果您更改写入器数据库实例，则更新对数据库集群中的副本实例可见。此外，你还可以创建跨区域 MySQL 只读副本。这些都是使用基于二进制日志的 MySQL 复制引擎实施的。

最好是在扩展只读操作时使用 Aurora 副本。您可以通过减少写入器上的只读工作负载来实现这一点。然后，提高可用性以处理减慢或阻止扩展的事件。

解决方法

如何提升 Aurora 只读副本？

手动故障转移 - 通过执行以下步骤执行手动故障转移，将其他只读副本实例提升为写入器实例：

1. 登录到 Amazon Relational Database Service (Amazon RDS) 控制台。
2. 从导航面板中选择数据库。
3. 为您的 Aurora 数据库集群选择写入器实例。
4. 选择操作，然后再选择故障转移。

自动故障转移 - 如果写入器实例不可用，则 Aurora 会自动故障转移至只读副本实例。出现这种情况的原因可能有多个，包括资源争用和维护活动。如果您有多个读取器，则可以赋予集群中的每个实例一个提升优先级层。如果写入器实例故障，则 Aurora 会将具有最高优先级的副本提升为新的写入器。

此外，您还可以将跨区域 Aurora 副本提升为独立的数据库集群。启动提升流程后，跨区域复制将会停止。新提升的集群将作为独立的数据库集群运行，并处理读取和写入操作。

我该如何衡量复制滞后？

由于单个数据库集群中的所有 Aurora 数据库实例共用一个通用数据卷，因此，复制滞后最短。通常情况下，滞后时间在 10 毫秒之内。但是，在一些特定情况下，您可能会发现读取器上的滞后稍有延长。

**注意：**对于使用逻辑复制的跨区域副本，其滞后时间会受到更改/应用速度以及所选区域之间的网络通信延迟情况的影响。使用 Aurora 数据库的跨区域副本通常有不到一秒的滞后时间。

您可以使用以下 Amazon CloudWatch 指标衡量复制滞后：

• 使用 AuroraReplicaLag 衡量写入器与读取器节点（相同区域）之间的副本滞后，以毫秒为单位。
• 使用 AuroraBinlogReplicaLag 衡量使用二进制日志的 Aurora 数据库集群之间的副本滞后。

如何提高复制性能？

请按照以下建议操作，以改善副本滞后：

• 如果读取器实例小于写入器实例，则可能是更改量太大而读取器无法跟上。最佳做法是集群中的所有实例拥有相同的大小，以免读取器实例上出现任何工作负载过载。
• 如果写入器上的工作负载过重，则您可能会发现只读副本临时滞后。滞后将在读取器实例跟上写入器实例之后缩小。
• 如果有任何长时间运行的事务正在进行，则可能会发现读取器上会出现副本滞后。为了避免副本滞后，请以较小的批量运行事务并更频繁地运行提交。

有关使用基于二进制日志的本地 MySQL 复制解决高副本滞后问题的更多信息，请参阅备份和恢复 Aurora 数据库集群的概述。

我可以使用全局事务标识符 (GTID)？

全局事务标识符是与其 Commit 上的事务关联的唯一字符串。GTID 在所有服务器中都是唯一的，并且将会基于 GTID 值在目标上应用更改。有关更多信息，请参阅 MySQL 文档中的 GTID 概念。

Aurora 不会使用本地二进制日志复制来将数据复制到只读副本实例。不可能使用 GTID 在相同集群中的实例之间复制数据。但是，在某些情况下，您可以设置基于 GTID 的复制。有关在 Aurora MySQL 中使用基于 GTID 复制的更多信息，请参阅有关 GTID 的 AWS 博客。

**注意：**您可以设置 Amazon RDS MySQL 与 Aurora 集群之间以及 Aurora 集群之间的基于 GTID 的复制（假设源为外部主服务器）。请确保先在源上启用二进制日志，然后再启动复制流程。

---

相关信息

使用 Amazon Aurora 进行复制

什么是 Amazon Aurora？