如何对导致 Aurora 只读副本出现延迟和重启的问题进行故障排除？

解决方法

**注意：**以下解决方案适用于单个 AWS 区域内的 Aurora 集群和全局数据库主集群，不适用于全局数据库辅助集群。

测量 AuroraReplicaLag

Aurora 副本连接至与写入器实例相同的存储卷。Aurora 会将更改同步写入共享存储卷，但会将更改异步复制到读取器实例。为了保证读取一致性，Aurora 会使与更改相关的内存缓存数据失效。数据缓存包括缓冲池或页面缓存。

在某些情况下，在读取器实例中传播更改时，可能会出现延迟。延迟显示为 Amazon CloudWatch 中 AuroraReplicaLag 指标的增加，这可能会导致重启，您可能会收到以下错误消息：

"Read Replica has fallen behind the master too much.Restarting"。

对于 Amazon Aurora MySQL 兼容版，请在 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表上运行以下查询来测量 AuroraReplicaLag：

select server_id AS Instance_Identifier, if(session_id = 'MASTER_SESSION_ID', 'writer', 'reader') as Role, replica_lag_in_milliseconds as AuroraReplicaLag from information_schema.replica_host_status;

输出示例：

+---------------------+--------+-------------------+  
| Instance_Identifier | Role   | AuroraReplicaLag  |  
+---------------------+--------+-------------------+  
| myamscluster-aza-1  | writer |                 0 |  
| myamscluster-azb-1  | reader | 5.150000095367432 |  
| myamscluster-aza-2  | reader | 5.033999919891357 |  
+---------------------+--------+-------------------+

对于 Amazon Aurora PostgreSQL 兼容版，请运行以下查询以获取 aurora_replica_status() 函数并筛选结果：

select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role, replica_lag_in_msec as AuroraReplicaLag from aurora_replica_status();

输出示例：

server_id          | role   | aurorareplicalag  
-------------------+--------+------------------  
myapgcluster-aza-1 | Reader | 19.641  
myapgcluster-azb-1 | Reader | 19.752  
myapgcluster-aza-2 | Writer |  
(3 rows)

确保集群中的所有实例使用相同规范

如果读取器实例的数据库实例类配置低于写入器数据库实例，则更改量可能过大。从而导致读取器实例无法在缓存中失效。为避免此问题，最佳做法是为 Aurora 集群中的所有数据库实例保留相同规范。

借助指标和增强监控来监控会话

当您同时运行多个会话时，读取器实例可能会延迟。Aurora 副本可能会因可用资源不足而缓慢应用写入器所做的必要更改。要检查延迟，请查看 CPUUtilization、DBConnections 以及 NetworkReceiveThroughput 指标。您还可以启用粒度为 1 或 5 秒的增强监控，以获取读取器上的资源使用量。或者，开启性能见解并使用数据库见解来可视化读取器的工作负载。对于 Aurora PostgreSQL 兼容版，您可以使用 ReadIOPS 指标。

重要事项：性能详情将于 2026 年 6 月 30 日到期。您可以在 2026 年 6 月 30 日之前升级到数据库洞察的高级模式。如果您不进行升级，则使用性能详情的数据库集群将默认采用数据库洞察的标准模式。只有数据库洞察的高级模式才支持执行计划和按需分析。如果您的集群默认采用标准模式，则您可能无法在控制台上使用这些功能。要开启高级模式，请参阅开启适用于 Amazon RDS 的数据库洞察的高级模式和开启适用于 Amazon Aurora 的数据库洞察的高级模式。

使用 CloudWatch 可视化写入活动

在已占用高写入负载的生产集群中，写入活动的突然激增可能会导致写入器数据库实例过载。过载可能导致读取器实例出现延迟。使用 CloudWatch 查看显示突增的 DMLThroughput、DDLThroughput 和 Queries 指标。对于 Aurora PostgreSQL 兼容版，请查看 WriteThroughput 指标。

对 Aurora PostgreSQL 兼容版长时间运行的事务进行故障排除

默认情况下，MySQL InnoDB 引擎使用多版本并发控制 (MVCC)。因此，您必须跟踪事务全程中发生的所有行更改。长时间运行的事务完成后，清除线程活动开始激增。由于长时间运行的事务会产生大量待办事项，突发的清除操作可能会导致 Aurora 副本产生延迟。

对于 Aurora MySQL 兼容版，请查看 CloudWatch 中的 RollbackSegmentHistoryListLength 指标以了解清除量激增情况。您可以运行 SHOW ENGINE INNODB STATUS 命令来查看清除情况。或者，运行以下查询：

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

输出示例：

+----------------------------------+-------+  
| RollbackSegmentHistoryListLength | COUNT |  
+----------------------------------+-------+  
| trx_rseg_history_len             |   358 |  
+----------------------------------+-------+  
1 row in set (0.00 sec)

设置 CloudWatch 警报来监控 RollbackSegmentHistoryListLength，以确保其数值不会过高。最佳做法是避免在关系数据库上进行长时间运行的事务。

预防短暂网络中断

尽管很少出现，但写入器与读取器实例之间或实例与 Aurora 存储层之间可能会发生短暂的网络通信故障。由于网络短暂中断，读取器实例可能会产生延迟或重新启动。Aurora 副本也可能会延迟，因为大量更改使得实例的网络带宽过载。为避免此问题，最佳做法是将数据库实例的大小修改为所能处理的更改量。

相关信息

将 Aurora 副本添加到数据库集群

使用 Amazon Aurora MySQL 兼容版进行复制

监控 Amazon Aurora 集群中的指标

Amazon Aurora 的实例级指标