InnoDB 历史记录列表长度显著增加
从 date
开始,您的行更改历史记录列表显著增加,最大达到 db-instance
上的 length
。这一增加会影响查询和数据库关闭性能。
支持的引擎版本
Aurora MySQL 的所有版本都支持这些见解信息。
上下文
InnoDB 事务系统维护多版本并发控制(MVCC)。修改行时,正在修改的数据的预修改版本将作为撤消记录存储在撤消日志中。每条撤消记录都引用其先前的重做记录,形成一个链接的列表。
InnoDB 历史记录列表是已提交事务的撤消日志的全局列表。当事务不再需要历史记录时,MySQL 使用历史记录列表来清除记录和日志页面。历史记录列表长度是包含历史记录列表中的修改的撤消日志总数。每个日志包含一个或多个修改。如果 InnoDB 历史记录列表长度过大,表明有大量的旧行版本,则查询和数据库关闭会变得更慢。
这个问题的可能原因
历史记录列表较长的典型原因包括以下几点:
-
长时间运行的事务,无论是读取还是写入
-
繁重的写入负载
操作
根据见解的原因,我们建议采取不同的操作。
在 InnoDB 历史记录列表减小之前,不要开始任何涉及数据库关闭的操作
由于 InnoDB 历史记录列表较长会减慢数据库关闭速度,因此请在启动涉及数据库关闭的操作之前减小列表大小。这些操作包括主要版本数据库升级。
识别并结束长时间运行的事务
您可以通过查询 information_schema.innodb_trx
来找到长时间运行的事务。
注意
还要确保在只读副本上查找长时间运行的事务。
识别并结束长时间运行的事务
-
在 SQL 客户端中,运行以下查询:
SELECT a.trx_id, a.trx_state, a.trx_started, TIMESTAMPDIFF(SECOND,a.trx_started, now()) as "Seconds Transaction Has Been Open", a.trx_rows_modified, b.USER, b.host, b.db, b.command, b.time, b.state FROM information_schema.innodb_trx a, information_schema.processlist b WHERE a.trx_mysql_thread_id=b.id AND TIMESTAMPDIFF(SECOND,a.trx_started, now()) > 10 ORDER BY trx_started
-
使用存储过程 mysql.rds_kill 结束每个长时间运行的事务。
使用性能详情确定首要主机和主要用户。
优化事务,以便立即提交大量修改后的行。
相关指标
以下指标与此见解相关:
-
trx_rseg_history_len
– 可以在性能详情以及INFORMATION_SCHEMA.INNODB_METRICS
表中查看此计数器指标。有关更多信息,请参阅 MySQL 文档中的 InnoDB INFORMATION_SCHEMA metrics table。 -
RollbackSegmentHistoryListLength
– 此 Amazon CloudWatch 指标衡量记录已提交事务(带有删除标记的记录)的撤销日志。这些记录安排为由 InnoDB 清除操作进行处理。指标trx_rseg_history_len
具有与RollbackSegmentHistoryListLength
相同的值。 -
PurgeBoundary
– 允许进行 InnoDB 清除的截止事务编号。如果此 CloudWatch 指标在很长一段时间内没有进展,这很好地表明 InnoDB 清除被长时间运行的事务阻止了。要进行调查,请检查 Aurora MySQL 数据库集群上的活跃事务。此指标仅适用于 Aurora MySQL 版本 2.11 及更高版本以及版本 3.08 及更高版本。 -
PurgeFinishedPoint
– 执行 InnoDB 清除的截止事务编号。此 CloudWatch 指标有助于您检查 InnoDB 清除的进展速度。此指标仅适用于 Aurora MySQL 版本 2.11 及更高版本以及版本 3.08 及更高版本。 -
TransactionAgeMaximum
– 最早的活动运行事务的期限。此 CloudWatch 指标仅适用于 Aurora MySQL 版本 3.08 及更高版本。 -
TruncateFinishedPoint
– 执行撤消截断的截止事务编号。此 CloudWatch 指标仅适用于 Aurora MySQL 版本 2.11 及更高版本以及版本 3.08 及更高版本。
有关 CloudWatch 指标的更多信息,请参阅 Amazon Aurora 的实例级指标。