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 的分片譜系，請求早於保留期的範圍。

如何修正

從最舊的可用記錄恢復並接受缺口：

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

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

從真相之源調和錯過的視窗——表仍然擁有每個項目的_當前_狀態。對受影響的鍵做一次有界的 Scan/Query（或對大表做一次匯出）能重建被修剪記錄本會告訴你的東西，只缺中間版本。
對消費者滯後告警——監控你正在處理的記錄的年齡（或 Lambda 的 IteratorAge 指標），並在它接近 24 小時之前很早就尋呼。
需要更長的保留？ 在記錄到達時把它們流入一個持久緩衝區（例如透過 Kinesis 介面卡模式流入 Kinesis Data Streams，或自己持久化已處理的記錄）——DynamoDB Streams 本身無法延長超過 24 小時。

在缺口之後重建狀態意味著看現在表中實際有什麼——DynoTable 桌面應用把那次調和過程變成一個可瀏覽的查詢而非一個指令碼。在規劃追趕讀取？DynamoDB 定價計算器會估算 RCU 成本。

在 DynoTable 中

修剪間隙後，從表中協調當前項目狀態 - 使用 ⌘K 開啟它並瀏覽或過濾消費者錯過的鍵。 DynoTable 顯示獨立於 24 小時流視窗的實時表資料。使用 pricing calculator 調整追趕閱讀的大小。在重新啟動使用者之前，從後設資料面板複製表的 LatestStreamArn。使用 ⌘P 切換設定檔案；參見連線 AWS和安裝。

來源

GetRecords — Amazon DynamoDB Streams API Reference（2026-07-13 驗證）
Change data capture for DynamoDB Streams（2026-07-13 驗證）

參考資料

最後核實於 2026-07-13，依據上方連結的 AWS 官方文件。