DynamoDB Streams: TrimmedDataAccessException

TL;DR — DynamoDB Streams hält Records 24 Stunden lang; ältere werden getrimmt und sind aus dem Stream verschwunden. Diese Exception heißt, dass du nach einer Position gefragt hast, die getrimmt wurde — ein Checkpoint, der älter als ein Tag ist, meist von einem Consumer, der ausgefallen oder zurückgefallen war. Über den Stream bekommst du diese Records nicht zurück: Setz bei TRIM_HORIZON (dem ältesten noch vorhandenen Record) wieder auf und gleich 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

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.

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.
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.
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.

In DynoTable

Nachdem a trim gap, reconcile current item state from the table — open it with ⌘K and browse or filter the keys your consumer missed. DynoTable shows live table data independent of the 24-hour stream window.

Size the catch-up read with the Pricing-Rechner. Copy the table's LatestStreamArn from the metadata panel bevor du restart the consumer. Wechsle Profile mit ⌘P; see Mit AWS verbinden and Installation.

Quellen

GetRecords — Amazon DynamoDB Streams API Reference (verifiziert 2026-07-13)
Change data capture for DynamoDB Streams (verifiziert 2026-07-13)

Referenzen

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