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

上次更新时间:2020 年 6 月 22 日

我在运行生产型 Amazon Aurora 数据库集群,我的读取器节点已重启并显示错误消息“只读副本比主节点滞后太多。重新启动 MySQL”或“只读副本比主节点滞后太多。重新启动 postgres”。我的读取器为什么会重启?

简短描述

将主 Aurora 数据库实例中的更新复制到 Aurora 数据库集群中的读取器节点时,AuroraReplicaLag 是滞后衡量指标,以毫秒为单位。Aurora 副本与主数据库实例连接到相同的存储卷中,并且仅支持读取操作。您可以通过使用 Amazon CloudWatch 中的 AuroraReplicaLag 指标衡量主节点和读取器节点之间的滞后

对于 Aurora PostgreSQL 数据库集群,AuroraReplicaLag 指标表示 Aurora 副本的页面缓存比主数据库实例的页面缓存滞后。这意味着,将数据写入集群卷后,写入器和读取器节点都可以近乎实时地访问它。

为了确保您的更改已传播到读取器节点间,您必须使缓存的数据失效,以实现读取一致性。在某些情况下,更改在读取器节点之间的传播可能会有延迟。您可以通过 CloudWatch 中的 AuroraReplicaLag 指标增加观察到这一点,这最终会导致重启。

对于 Aurora MySQL,您可以通过 INFORMATION_SCHEMA.REPLICA_HOST_STATUS 表按照下面的方法测量有关 AuroraReplicaLag 的近乎实时的元数据:
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  |
+---------------------+--------+-------------------+
| primary-instance    | writer |                 0 |
| reader-node-02      | reader | 5.150000095367432 |
| reader-node-03      | reader | 5.033999919891357 |
+---------------------+--------+-------------------+

对于 Aurora PostgreSQL,请调用 aurora_replica_status() 函数并按照下面的方法筛选结果:

postgres=> select server_id, case when session_id= 'MASTER_SESSION_ID' then 'Writer' else 'Reader' end AS Role,
cur_replay_latency_in_usec*1000/60/60/60 as AuroraReplicaLag 
from aurora_replica_status();

  server_id   |  role  | aurorareplicalag 
--------------+--------+---------------------
 read-node-01 | Reader |                 71
 read-node-02 | Reader |                 79
 primary-node | Writer |                    

解决方法

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

如果读取器节点具有比写入器数据库实例弱的数据库实例类配置,则更改量对于读取器而言可能太大,以至于无法在缓存和处理中使其失效。在这种情况下,最佳实践是确保 Aurora 集群中的所有数据库实例均具有相同的规范。

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

当多个会话同时运行时,读取器节点可能会发生之后。由于缺乏可用的资源,Aurora 副本在应用来自主节点的必要更改时可能会很慢。您可以使用诸如 CPUUtilizationDBConnectionsNetworkReceiveThroughputActiveTransactions 之类的指标对其进行可视化。

对于r Aurora PostgreSQL,请使用 ReadIOPS 指标,而不是 ActiveTransactions。您可以启用至少 5/1 秒粒度的增强监控,以了解读取器节点的利用率。您还可以使用性能详情来可视化工作负载。

使用 Amazon CloudWatch 可视化写入活动

在已有密集写入活动的生产集群中,写入活动突然激增可能会导致写入器数据库实例过载。激增导致的压力增加可能会导致读取器节点滞后。您可以通过使用 Amazon CloudWatch 对其进行可视化,在该服务中,您将观察到 DMLThroughputDDLThroughputQueries 指标的突然激增。

对于 Aurora PostgreSQL,您可以使用 WriteThroughPut 指标对其进行可视化。

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

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

截至 1.19.22.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 存储层之间可能会发展临时性网络通信失败,尽管这种情况很罕见。由于网络短暂中断,读取器节点可能会滞后或重启。由于更改量大造成网络饱和或者可用区间发生短暂的数据包丢失,Aurora 副本可能会滞后。您应考虑数据库实例的大小以及其联网功能,以避免此问题。

要考虑的重要注释

从 1.17.4 版开始的 Aurora MySQL 1.x 版本内有一些显著的功能,您应该了解它们:

  • aurora_enable_replica_log_compression 是可用于压缩复制负载的集群参数,以提高主节点与 Aurora 副本之间的网络带宽利用率。它在网络明显饱和时有用。

  • aurora_enable_zdr 是可用于保持所有打开连接并在 Aurora 副本重启时保留它们的集群参数。

  • aurora_enable_staggered_replica_restart允许 Aurora 副本遵照交错重启计划以提高集群可用性的集群参数。