我的 Amazon Aurora 只读副本为什么会滞后并重新启动？

2 分钟阅读

我正在运行生产型 Amazon Aurora 数据库集群。我的读取器实例已重启并显示错误消息“只读副本比主实例滞后过多。重新启动 MySQL”或“只读副本比主实例滞后过多。重新启动 postgres。”

简短描述

将写入器 Aurora 数据库实例中的更改复制到 Aurora 数据库集群中的读取器实例时，AuroraReplicaLag 是滞后衡量指标，以毫秒为单位。Aurora 副本连接到与写入器实例相同的存储卷。要衡量写入器与读取器实例之间的延迟，请使用 Amazon CloudWatch 中的 AuroraReplicaLag 指标。

对于 Aurora 数据库集群，AuroraReplicaLag 指标表示 Aurora 副本的数据缓存比写入器数据库实例的数据缓存滞后。数据缓存包括缓冲池或页面缓存。更改将同步写入共享存储卷。但是，更改会异步复制到读取器实例，在这些实例中，缓存在内存中与更改相关的任何数据都将失效，以实现读取一致性。在某些情况下，更改在读取器实例之间的传播可能会有延迟。这种延迟表现为 CloudWatch 中 AuroraReplicaLag 指标的增加，最终可能导致重新启动。

您可以测量关于 AuroraReplicaLag 的近乎实时的元数据：

对于 Amazon Aurora MySQL 兼容版，请从 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表中进行选择：

mysql> 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() 函数并筛选结果：

postgres=> 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)

**注意：**本文中提供的解决方案适用于 Amazon Aurora 单区域全局数据库主集群，而非全局数据库辅助集群。

解决方法

确保集群中的所有实例均具有相同的规范

如果读取器实例的数据库实例类配置比写入器数据库实例弱，则更改量可能太大。在这种情况下，读取器实例无法在缓存中失效，然后赶上。因此，最佳实践是让 Aurora 集群中的所有数据库实例均具有相同的规范。

使用指标和增强监控功能监控会话

当多个会话同时运行时，读取器实例可能会发生滞后。由于缺乏可用的资源，Aurora 副本在应用来自写入器的必要更改时可能会很慢。您可以在诸如 CPUUtilization、DBConnections 和 NetworkReceiveThroughput 之类指标中的观察到该滞后。您还可以使用 1 或 5 秒的粒度启用增强监控，以了解读取器上的资源使用情况。您可以使用性能详情来可视化工作负载。此外，对于仅兼容 Aurora PostgreSQL 的实例，请使用 ReadIOPS 指标。

使用 CloudWatch 可视化写入活动

在已有密集写入活动的生产集群中，写入活动突然激增可能会导致写入器数据库实例过载。激增带来的压力增加可能会导致一个或多个读取器实例滞后。您可以在 CloudWatch 中观察到滞后，它表现为 DMLThroughput、DDLThroughput 和 Queries 指标的突然激增。

对于 Aurora PostgreSQL，您可以在 WriteThroughput 指标中观察到这一点。

调查越来越高的历史记录列表长度 (HLL) 值（Aurora MySQL 兼容）

MySQL 的 InnoDB 引擎默认合并了多版本并发控制 (MVCC)。这意味着您必须跟踪整个事务过程中所有受影响的行上发生的所有更改。长时间运行的事务完成后，清理线程活动开始发生突增。由于长期运行事务创建的待办事项数量庞大，突然清理可能会导致 Aurora 副本滞后。

在 1.19.2、2.06 及更高版本中，Aurora MySQL 中包含指标 RollbackSegmentHistoryListLength。您可以在 CloudWatch 中使用此指标来观察此突增。同时，还可以在 SHOW ENGINE INNODB STATUS 的输出上或按以下方式查询信息架构来对其进行可视化：

mysql> 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 警报来监控此指标，这样，它就不会达到过高的数值。在关系数据库中，最佳实践是避免长时间运行的事务。

防止网络短暂中断

写入器与读取器实例或实例与 Aurora 存储层之间可能会发生暂时性网络通信失败，尽管这种情况很罕见。由于网络短暂中断，读取器实例可能会滞后或重启。由于大量更改导致实例的网络带宽饱和，Aurora 副本也可能落后。最佳实践是考虑数据库实例的大小以及它拥有的联网能力，以避免此问题。