DynamoDB Streams: TrimmedDataAccessException

TL;DR — DynamoDB Streams behält Datensätze 24 Stunden; ältere Datensätze werden getrimmt und sind aus dem Stream verschwunden. Diese Exception bedeutet, dass du nach einer Position gefragt hast, die getrimmt wurde — ein Checkpoint, der mehr als einen Tag alt ist, meist von einem Consumer, der ausgefallen war oder zurückfiel. Du kannst diese Datensätze nicht aus dem Stream zurückholen: setze ab TRIM_HORIZON (ältester überlebender Datensatz) fort und gleiche die Lücke aus der Tabelle selbst ab.

Was es bedeutet

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

Anders als bei einem abgelaufenen Iterator — wo nur dein Positions-Handle veraltet ist — sind getrimmte Daten wirklich entfernt. Einen Shard-Iterator bei einer getrimmten SequenceNumber anzufordern oder einen Shard zu lesen, dessen Datensätze abgelaufen sind, wirft diese. Der Stream ist ein rollierender 24-Stunden-Puffer, kein Archiv.

Warum es passiert

• Der Consumer war länger als 24 Stunden ausgefallen — ein Ausfall, ein pausierter Worker, ein vergessener deaktivierter Trigger — und sein Checkpoint zeigt jetzt in getrimmtes Gebiet.
• Verarbeitungsverzögerung überschritt die Aufbewahrung — der Consumer läuft, aber langsamer als die Schreibrate, und driftete mehr als einen Tag zurück.
• Ein veralteter gespeicherter Checkpoint — einen alten Consumer mit einer vor Wochen persistierten SequenceNumber neu starten.
• Einen alten Shard von Anfang bis Ende lesen — die Shard-Abstammung eines langlebigen Streams durchlaufen und Bereiche anfordern, die vor der Aufbewahrung liegen.

So behebst du es

1. Setze ab dem ältesten verfügbaren Datensatz fort und akzeptiere die Lücke:

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

   Nutze stattdessen LATEST, wenn nur neue Aktivität zählt.

2. Gleiche das verpasste Fenster aus der Source of Truth ab — die Tabelle hat noch den aktuellen Zustand jedes Items. Ein begrenzter Scan/Query über die betroffenen Schlüssel (oder ein Export bei großen Tabellen) rekonstruiert, was die getrimmten Datensätze dir gesagt hätten, minus Zwischenversionen.

3. Alarmiere bei Consumer-Verzögerung — überwache das Alter der Datensätze, die du verarbeitest (oder Lambdas IteratorAge-Metrik) und alarmiere lange, bevor es sich den 24 Stunden nähert.

4. Brauchst du längere Aufbewahrung? Streame Datensätze bei ihrer Ankunft in einen dauerhaften Puffer (z. B. Kinesis Data Streams via Kinesis-Adapter-Muster, oder persistiere verarbeitete Datensätze selbst) — DynamoDB Streams selbst kann nicht über 24 Stunden hinaus verlängert werden.

Den Zustand nach einer Lücke wiederaufzubauen bedeutet, sich anzusehen, was jetzt tatsächlich in der Tabelle ist — die DynoTable-Desktop-App macht diesen Abgleich-Durchlauf zu einer durchsuchbaren Abfrage statt zu einem Skript. Den Aufhol-Read dimensionieren? Der DynamoDB-Preisrechner schätzt die RCU-Kosten.

Verwandte Fehler

• ExpiredIteratorException — der behebbare Cousin: Position veraltet, Daten noch da.
• Stream not enabled
• Invalid StreamArn
• Learn: DynamoDB Streams

Referenzen

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

Zuletzt verifiziert am 2026-07-13 gegen die oben verlinkte offizielle AWS-Dokumentation.