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

上次更新日期:2021 年 2 月 1 日

我有一个 Amazon Aurora MySQL 数据库实例,并且我在使用只读副本时遇到了问题。如何解决在 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 的复制(假设源为外部主服务器)。请确保先在源上启用二进制日志,然后再启动复制流程。


这篇文章对您有帮助吗?


您是否需要账单或技术支持?