我有一个 Amazon Aurora MySQL 兼容版数据库实例,我在使用只读副本时遇到了问题。我想解决这些问题。
解决方法
升级 Aurora 只读副本
要将另一个只读副本实例升级为写入器实例,请执行手动失效转移。
完成以下步骤:
- 打开 Amazon Relational Database Service (Amazon RDS) 控制台。
- 在导航窗格中,选择数据库。
- 为您的 Aurora 数据库集群选择写入器实例。
- 选择操作,然后选择失效转移。
如果写入器实例不可用,Aurora 将自动失效转移到只读副本实例。有多个原因可能导致写入器实例不可用,如资源争用和维护活动。
如果您有多个读取器,为集群中的每个实例指定升级优先级层。当写入器实例出现故障时,Aurora 会将优先级最高的副本升级为新写入器。
您还可以将跨 AWS 区域 Aurora 副本升级为独立的数据库集群。开始升级流程后,跨区域复制将停止。新升级的集群充当独立数据库集群,管理读取和写入操作。
测量复制延迟
由于数据库集群中的所有 Aurora 数据库实例共用数据量,因此复制延迟最小。但是,在某些情况下,您可能会注意到读取器的延迟时间略有增加。
**注意:**跨区域副本使用逻辑复制。更改和应用所选区域之间网络通信的速率和延迟可能会影响跨区域副本。使用 Aurora 数据库的跨区域副本的延迟通常在 1 秒以内。
要测量复制延迟,使用以下 Amazon CloudWatch 指标:
- AuroraReplicaLag 以毫秒为单位测量同一区域内写入器和读取器节点之间的副本延迟。
- AuroraBinlogReplicaLag 测量使用二进制日志的 Aurora 数据库集群之间的副本延迟。
提高复制性能
要改善复制延迟,执行以下操作:
- 如果读取器实例小于写入器实例,更改量可能太大,读取器无法应付。为避免读取器实例的工作负载太大,最佳做法是将集群中的所有实例设置为相同大小。
**注意:**如果写入器实例的工作负载很大,您可能会注意到暂时的只读副本延迟。当读取器实例赶上写入器实例后,延迟会减少。
- 如果正在进行长时间运行的事务,读取器可能会出现副本延迟。为避免副本延迟,请以较小的批次运行事务,并频繁地运行提交。
有关如何使用基于二进制日志的本机 MySQL 复制来解决副本延迟问题的信息,请参阅备份和恢复 Aurora 数据库集群概述。
解决高复制延迟问题
您可以在 AuroraReplicaLag CloudWatch 指标中查看高复制延迟。高复制延迟可能会导致读取器实例重启。要防止由于高复制延迟导致读取器实例频繁重启,请参阅为什么我的 Amazon Aurora 只读副本滞后并重启?
设置基于 GTID 的复制
Aurora 不使用本机二进制日志复制来将数据复制到只读副本实例。您不能使用全局事务标识符 (GTID) 在同一集群中的实例之间复制数据。但是,在某些情况下,您可以设置基于 GTID 的复制。有关如何在 Aurora MySQL 兼容版中使用基于 GTID 的复制的更多信息,请参阅 Amazon Aurora for MySQL 兼容性现在支持全局事务标识符 (GTID) 复制。
**注意:**您可以在 Amazon RDS MySQL 与 Aurora 集群之间以及各 Aurora 集群之间设置基于 GTID 的复制。源需要是外部主要源。在开始复制过程之前,确保在源上启用二进制日志。
有关 GTID 的更多信息,请参阅 MySQL 网站上的 GTID 格式和存储。
相关信息
跨 AWS 区域复制 Amazon Aurora MySQL 数据库集群
使用 Amazon Aurora 复制