DynamoDB Streams: TrimmedDataAccessException

TL;DR — DynamoDB Streams 把记录保留 24 小时；更旧的记录被修剪，从 stream 中消失了。这个异常意味着你请求了一个已被修剪的位置——一个超过一天的检查点，通常来自一个宕机或落后的消费者。你无法从 stream 取回那些记录：从 TRIM_HORIZON（最旧的存留记录）恢复，并从表本身调和这个缺口。

含义

TrimmedDataAccessException: The data you are trying to access has been trimmed.

与过期的迭代器——那里只有你的_位置句柄_陈旧了——不同，被修剪的数据是真正被移除了。在一个被修剪的 SequenceNumber 请求分片迭代器，或读取一个其记录已老化淘汰的分片，都会抛出它。stream 是一个滚动的 24 小时缓冲区，而不是一个归档。

为什么会发生

• 消费者宕机超过 24 小时——一次中断、一个暂停的 worker、一个被遗忘的禁用触发器——而它的检查点现在指向被修剪的区域。
• 处理滞后超过了保留期——消费者在运行，但慢于写入速率，落后了超过一天。
• 一个陈旧的存储检查点——用几周前持久化的一个 SequenceNumber 重启一个旧消费者。
• 端到端读取一个旧分片——遍历一个长期存在的 stream 的分片谱系，请求早于保留期的范围。

如何修复

1. 从最旧的可用记录恢复并接受缺口：

   const {ShardIterator} = await streams.send(
     new GetShardIteratorCommand({
       StreamArn: streamArn,
       ShardId: shardId,
       ShardIteratorType: 'TRIM_HORIZON' // oldest untrimmed record
     })
   );

   如果只有新活动重要，就改用 LATEST。

2. 从真相之源调和错过的窗口——表仍然拥有每个项目的_当前_状态。对受影响的键做一次有界的 Scan/Query（或对大表做一次导出）能重建被修剪记录本会告诉你的东西，只缺中间版本。

3. 对消费者滞后告警——监控你正在处理的记录的年龄（或 Lambda 的 IteratorAge 指标），并在它接近 24 小时之前很早就寻呼。

4. 需要更长的保留？ 在记录到达时把它们流入一个持久缓冲区（例如通过 Kinesis 适配器模式流入 Kinesis Data Streams，或自己持久化已处理的记录）——DynamoDB Streams 本身无法延长超过 24 小时。

在缺口之后重建状态意味着看现在表中实际有什么——DynoTable 桌面应用把那次调和过程变成一个可浏览的查询而非一个脚本。在规划追赶读取？DynamoDB 定价计算器会估算 RCU 成本。

相关错误

• ExpiredIteratorException——可恢复的表亲：位置陈旧，数据还在。
• Stream not enabled
• Invalid StreamArn
• 学习：DynamoDB Streams

References

• GetRecords — Amazon DynamoDB Streams API Reference
• GetShardIterator — Amazon DynamoDB Streams API Reference
• Change data capture for DynamoDB Streams — Amazon DynamoDB Developer Guide

最后核实于 2026-07-13，依据上方链接的 AWS 官方文档。