Fehlerbehandlung mit DynamoDB

Dieser Abschnitt beschreibt Laufzeitfehler und wie sie gehandhabt werden können. Es werden auch Fehlermeldungen und Codes beschrieben, die Amazon-DynamoDB-spezifisch sind. Eine Liste häufiger Fehler, die für alle AWS-Services gelten, finden Sie unter Zugriffsverwaltung.

Fehlerkomponenten

Wenn das Programm eine Anforderung sendet, versucht DynamoDB diese zu verarbeiten. Bei einer erfolgreichen Anforderung gibt DynamoDB einen HTTP-Erfolgscode (200 OK) sowie die Ergebnisse der angeforderten Operation zurück.

Wenn die Anforderung nicht erfolgreich ist, gibt DynamoDB einen Fehler zurück. Jeder Fehler hat drei Komponenten:

• Einen HTTP-Statuscode (z. B. 400).

• Einen Ausnahmenamen (z. B. ResourceNotFoundException).

• Eine Fehlermeldung (z. B. Requested resource not found: Table: tablename not found).

Die AWS-SDKs kümmern sich um die Weiterleitung von Fehlern an die Anwendung, sodass Sie entsprechende Maßnahmen ergreifen können. Sie können beispielsweise in einem Java-Programm eine try-catch-Logik schreiben, um eine ResourceNotFoundException zu verarbeiten.

Wenn Sie kein AWS SDK verwenden, müssen Sie den Inhalt der Low-Level-Antwort von DynamoDB analysieren. Nachfolgend finden Sie ein Beispiel einer solchen Antwort.

HTTP/1.1 400 Bad Request
x-amzn-RequestId: LDM6CJP8RMQ1FHKSC1RBVJFPNVV4KQNSO5AEMF66Q9ASUAAJG
Content-Type: application/x-amz-json-1.0
Content-Length: 240
Date: Thu, 15 Mar 2012 23:56:23 GMT

{"__type":"com.amazonaws.dynamodb.v20120810#ResourceNotFoundException",
"message":"Requested resource not found: Table: tablename not found"}

Transaktionsfehler

Informationen zu Transaktionsfehlern finden Sie unter Handhabung von Transaktionskonflikten in DynamoDB

Fehlermeldungen und Codes

Die folgende Liste enthält von DynamoDB zurückgegebene Ausnahmen, gruppiert nach HTTP-Statuscode. Wenn OK, um es erneut zu versuchen? Ja ist, können Sie die gleiche Anforderung erneut senden. Wenn OK, um es erneut zu versuchen? auf Nein eingestellt ist, müssen Sie das Problem clientseitig lösen, bevor Sie eine neue Anforderung absenden.

HTTP-Statuscode 400

Der HTTP-Statuscode 400 weist auf ein Problem mit der Anforderung hin, wie z. B. einen Authentifizierungsfehler, fehlende Parameter oder die Überschreitung des bereitgestellten Durchsatzes der Tabelle. Sie müssen das Problem zuerst in der Anwendung beheben, bevor Sie die Anforderung erneut senden.

AccessDeniedException

Meldung: Access denied. (Zugriff verweigert.)

Der Client hat die Anforderung nicht richtig signiert. Wenn Sie ein AWS-SDK verwenden, werden die Anforderungen automatisch für Sie signiert. Rufen Sie andernfalls Signaturprozess mit Signature Version 4 in der Allgemeine AWS-Referenz auf.

Erneut versuchen? Nein

ConditionalCheckFailedException

Meldung: The conditional request failed. (Die bedingte Anforderung ist fehlgeschlagen.)

Sie haben eine Bedingung angegeben, die als False ausgewertet wurde. Beispiel: Sie haben versucht, eine bedingte Aktualisierung für ein Element durchzuführen, aber der tatsächliche Wert des Attributs stimmt nicht mit dem erwarteten Wert in der Bedingung überein.

Erneut versuchen? Nein

IncompleteSignatureException

Meldung: Die angeforderte Signatur entspricht nicht den AWS Standards.

Die Anforderungssignatur enthielt nicht alle erforderlichen Komponenten. Wenn Sie ein AWS-SDK verwenden, werden die Anforderungen automatisch für Sie signiert. Rufen Sie andernfalls Signaturprozess mit Signature Version 4 in der Allgemeine AWS-Referenz auf.

Erneut versuchen? Nein

ItemCollectionSizeLimitExceededException

Meldung: Collection size exceeded. (Sammlungsgröße überschritten.)

Für eine Tabelle mit einem lokalen sekundären Index hat eine Gruppe von Elementen mit demselben Partitionsschlüsselwert die maximale Größe von 10 GB überschritten. Weitere Informationen zu Elementsammlungen finden Sie unter Elementauflistungen in lokalen sekundären Indizes.

Erneut versuchen? Ja

LimitExceededException

Meldung: Too many operations for a given subscriber. (Zu viele Operationen für einen bestimmten Abonnenten.)

Es gibt zu viele gleichzeitige Operationen auf Steuerebene. Die kumulative Anzahl von Tabellen und Indizes im Status CREATING, DELETING oder UPDATING darf 500 nicht überschreiten.

Erneut versuchen? Ja

MissingAuthenticationTokenException

Meldung: Anforderung muss eine gültige (registrierte) AWS-Zugriffsschlüssel-ID enthalten.

Die Anforderung schloss die erforderliche Autorisierungskopfzeile nicht ein oder sie war falsch formatiert. Siehe DynamoDB Low-Level-API.

Erneut versuchen? Nein

ProvisionedThroughputExceededException

Meldung: Sie haben Ihren maximal erlaubten bereitgestellten Durchsatz für eine Tabelle oder für einen oder mehrere globale sekundäre Indizes überschritten. Für das Anzeigen von Leistungsmetriken für den bereitgestellten Durchsatz im Vergleich zum verbrauchten Durchsatz, öffnen Sie die Amazon-CloudWatch-Konsole.

Der Fehler enthält eine Liste von ThrottlingReason-Feldern, die spezifischen Kontext darüber liefern, warum eine Drosselung aufgetreten ist. Diese folgen dem Format ResourceType+OperationType+LimitType (z. B. TableReadProvisionedThroughputExceeded) sowie dem ARN der betroffenen Ressource. Dies hilft Ihnen dabei zu erkennen, welche Ressource von der Drosselung betroffen ist (Tabelle oder Index), welcher Operationstyp die Drosselung ausgelöst hat (Lese- oder Schreibvorgang) und welche spezifische Beschränkung überschritten wurde (in diesem Fall: bereitgestellte Kapazität). Weitere Informationen zur Diagnose und Lösung von Drosselungsproblemen finden Sie unter Drosselungsdiagnose.

Beispiel: Die Anforderungsrate ist zu hoch. Die AWS SDKs für DynamoDB wiederholen automatisch Anforderungen, die diese Ausnahme empfangen. Die Anforderung ist letztendlich erfolgreich, sofern die Warteschlange für Wiederholungsversuche für das Beenden nicht zu groß ist. Verringern Sie die Häufigkeit der Anforderungen mit Wiederholversuche bei Fehlern und exponentielles Backoff.

Erneut versuchen? Ja

ReplicatedWriteConflictException

Nachricht: Ein oder mehrere Elemente in dieser Anfrage werden durch eine Anfrage in einer anderen Region geändert.

Beispiel: Eine Schreiboperation wurde für ein Element in einer globalen Tabelle mit Multi-Region Strong Consistency (MRSC) angefordert, das derzeit durch eine Anfrage in einer anderen Region geändert wird.

Erneut versuchen? Ja

RequestLimitExceeded

Meldung: Throughput exceeds the current throughput limit for your account. (Der Durchsatz überschreitet die aktuelle Durchsatzbegrenzung für Ihr Konto.) Um eine Beschränkungserhöhung anzufordern, wenden Sie sich an den AWS-Support unter https://aws.amazon.com/support.

Der Fehler enthält eine Liste von ThrottlingReason-Feldern, die spezifischen Kontext darüber liefern, warum eine Drosselung aufgetreten ist. Diese folgen dem Format ResourceType+OperationType+LimitType (z. B. TableWriteAccountLimitExceeded oder IndexReadAccountLimitExceeded) sowie dem ARN der betroffenen Ressource. Dies hilft Ihnen zu erkennen, welche Ressource von der Drosselung betroffen ist (Tabelle oder Index), welcher Operationstyp die Drosselung ausgelöst hat (Lese- oder Schreibvorgang) und dass Sie die servicebezogenen Kontingente auf Kontoebene überschritten haben. Weitere Informationen zur Diagnose und Lösung von Drosselungsproblemen finden Sie unter Drosselungsdiagnose.

Beispiel: Die Rate der On-Demand-Anforderungen überschreitet den zulässigen Kontodurchsatz.

Erneut versuchen? Ja

ResourceInUseException

Meldung: The resource which you are attempting to change is in use. (Die Ressource, die Sie verändern möchten, wird gerade benutzt.)

Beispiel: Sie haben versucht, eine vorhandene Tabelle neu zu erstellen oder eine Tabelle zu löschen, die sich momentan im Status CREATING befindet.

Erneut versuchen? Nein

ResourceNotFoundException

Meldung: Requested resource not found. (Angefragte Ressource nicht gefunden.)

Beispiel: Die Tabelle, die angefordert wird, ist nicht vorhanden oder befindet sich zu früh im Status CREATING.

Erneut versuchen? Nein

ThrottlingException

Meldung: Rate of requests exceeds the allowed throughput. (Anforderungsrate überschreitet den erlaubten Durchsatz.)

Diese Ausnahme wird als AmazonServiceException-Antwort mit dem Statuscode THROTTLING_EXCEPTION zurückgegeben. Diese Ausnahme wird möglicherweise zurückgegeben, wenn Sie API-Operationen der Steuerebene zu schnell ausführen.

Bei Tabellen, die den On-Demand-Modus verwenden, wird diese Ausnahme möglicherweise für alle API-Operationen der Datenebene zurückgegeben, wenn Ihre Anforderungsrate zu hoch ist. Weitere Informationen zu On-Demand-Skalierungen finden Sie unter Anfänglicher Durchsatz und Skalierungseigenschaften.

Der Fehler enthält eine Liste von ThrottlingReason-Feldern, die spezifischen Kontext darüber liefern, warum eine Drosselung aufgetreten ist. Diese folgen dem Format ResourceType+OperationType+LimitType (z. B. TableReadKeyRangeThroughputExceeded oder IndexWriteMaxOnDemandThroughputExceeded) sowie dem ARN der betroffenen Ressource. Diese Informationen helfen Ihnen zu erkennen, welche Ressource von der Drosselung betroffen ist (Tabelle oder Index), welcher Operationstyp die Drosselung ausgelöst hat (Lese- oder Schreibvorgang) und welches spezifische Beschränkung überschritten wurde (Partitionsgrenzen oder maximale Durchsatzrate im On-Demand-Modus). Weitere Informationen zur Diagnose und Lösung von Drosselungsproblemen finden Sie unter Drosselungsdiagnose.

Erneut versuchen? Ja

UnrecognizedClientException

Meldung: The Access Key ID or security token is invalid. (Die Zugriffsschlüssel-ID oder der Sicherheitstoken ist ungültig.)

Die Anforderungssignatur ist nicht korrekt. Höchstwahrscheinlich ist ein ungültiger AWS-Zugriffsschlüssel-ID oder ein geheimer Schlüssel die Ursache.

Erneut versuchen? Ja

ValidationException

Meldung: Variiert je nach auftretendem spezifischen Fehler(n)

Dieser Fehler kann aus verschiedenen Gründen auftreten, z. B. wenn ein erforderlicher Parameter fehlt, ein Wert außerhalb des Bereichs liegt oder Datentypen nicht übereinstimmen. Die Fehlermeldung enthält Details zum spezifischen Teil der Anforderung, die den Fehler verursacht hat.

Erneut versuchen? Nein

HTTP-Statuscode 5xx

Der HTTP-Statuscode 5xx weist auf ein Problem hin, das von AWS behoben werden muss. Dies kann ein vorübergehender Fehler sein. In diesem Fall können Sie Ihre Anforderung wiederholen, bis sie korrekt ausgeführt wird. Andernfalls rufen Sie das AWS Service Health Dashboard auf, um zu sehen, ob es Betriebsprobleme mit dem Service gibt.

Weitere Informationen finden Sie unter Wie behebe ich HTTP-5xx-Fehler in Amazon DynamoDB?

InternalServerError (HTTP 500)

DynamoDB konnte die Anforderung nicht verarbeiten.

Erneut versuchen? Ja

Anmerkung

Während der Arbeit mit Elementen können interne Serverfehler auftreten. Diese sind während der Lebensdauer einer Tabelle zu erwarten. Alle fehlgeschlagenen Anforderungen können sofort abgerufen werden.

Wenn Sie bei einem Schreibvorgang einen Statuscode 500 erhalten, ist der Vorgang entweder erfolgreich oder ist fehlgeschlagen. Wenn der Schreibvorgang eine TransactWriteItem-Anforderung ist, dann ist es in Ordnung, den Vorgang erneut zu versuchen. Wenn es sich bei der Schreiboperation um eine Schreibanfrage mit einem Einzelelement handelt, wie z. B. PutItem, UpdateItem, oder DeleteItem, dann sollte Ihre Anwendung den Status des Elements lesen, bevor Sie den Vorgang erneut versuchen und/oder CLI-Beispiel für DynamoDB-Bedingungsausdrücke verwenden, um sicherzustellen, dass das Element nach einem erneuten Versuch in einem korrekten Zustand bleibt, unabhängig davon, ob der vorherige Vorgang erfolgreich oder fehlgeschlagen war. Wenn Idempotenz eine Voraussetzung für die Schreiboperation ist, verwenden Sie bitte TransactWriteItem, das idempotente Anfragen durch automatische Angabe eines ClientRequestToken unterstützt, um mehrere Versuche zu disambiguieren, dieselbe Aktion auszuführen.

ServiceUnavailable (HTTP 503)

DynamoDB ist derzeit nicht verfügbar. (Dies sollte ein vorübergehender Status sein.)

Erneut versuchen? Ja

Fehlerbehandlung in Ihrer Anwendung

Damit Ihre Anwendung reibungslos ausgeführt wird, müssen Sie Logik zum Erfassen und Behandeln von Fehlern integrieren. Typische Ansätze umfassen die Verwendung von try-catch-Blöcken oder if-then-Anweisungen.

Die AWS SDKs führen eigene Wiederholversuche und Fehlerprüfungen aus. Wenn bei der Verwendung eines der AWS-SDKs ein Fehler auftritt, können der Fehlercode und die Beschreibung zur Fehlerbehebung beitragen.

Sie sollten auch eine Request ID in der Antwort sehen. Die Request ID kann hilfreich sein, wenn Sie mit dem AWS Support ein Problem diagnostizieren müssen.

Wiederholversuche bei Fehlern und exponentielles Backoff

Zahlreiche Komponenten im Netzwerk, wie z. B. DNS-Server, Switches und Load Balancer, können irgendwann im Lebenszyklus einer Anforderung Fehler generieren. Die übliche Methode zum Umgang mit diesen Fehlermeldungen in einer vernetzten Umgebung besteht darin, Wiederholversuche in der Client-Anwendung zu implementieren. Diese Methode erhöht die Zuverlässigkeit der Anwendung.

Jedes AWS SDK implementiert automatisch eine Wiederholungsversuchslogik. Sie können die Parameter für Wiederholversuche an Ihre Bedürfnisse anpassen. Nehmen wir als Beispiel eine Java-Anwendung, die eine Fail-Fast-Strategie erfordert, in der im Falle eines Fehlers keine Wiederholversuche zulässig sind. Mit AWS SDK für Java können Sie die Klasse ClientConfiguration verwenden und einen maxErrorRetry-Wert von 0 eingeben, um die Wiederholversuche zu deaktivieren. Weitere Informationen finden Sie in der AWS SDK-Dokumentation für Ihre Programmiersprache.

Wenn Sie kein AWS SDK verwenden, sollten ursprüngliche Anforderungen wiederholt werden, die Server-Fehler (5xx) erhalten. Client-Fehler (4xx, außer ThrottlingException oder ProvisionedThroughputExceededException) weisen hingegen darauf hin, dass die Anforderung selbst geändert werden muss, um das Problem zu beheben. Erst dann sollte sie wiederholt werden. Detaillierte Empfehlungen zur Behandlung bestimmter Drosselungsszenarien finden Sie im Abschnitt Problembehandlung bei DynamoDB-Drosselung.

Zusätzlich zu einfachen Wiederholversuchen implementiert jedes AWS SDK einen Algorithmus für das exponentielle Backoff, um den Fluss besser zu steuern. Das Konzept hinter dem exponentiellen Backoff ist die Verwendung von progressiv längeren Wartezeiten zwischen Wiederholversuchen für aufeinanderfolgende Fehlermeldungen. Zum Beispiel bis zu 50 Millisekunden vor dem ersten Wiederholversuch, bis zu 100 Millisekunden vor dem zweiten, bis zu 200 Millisekunden vor dem dritten und so weiter. Wenn die Anforderung hingegen nach einer Minute nicht erfolgreich war, liegt das Problem möglicherweise an der Anforderungsgröße, die den bereitgestellten Durchsatz übersteigt, und nicht an der Anforderungsrate. Grenzen Sie die maximale Anzahl von Wiederholversuchen bis zu etwa einer Minute ein. Wenn die Anforderung nicht erfolgreich ist, untersuchen Sie Ihre bereitgestellten Durchsatzoptionen.

Anmerkung

Die AWS SDKs implementieren eine automatische Wiederholungsversuchslogik und exponentielles Backoff.

Die meisten Algorithmen für das exponentielle Backoff verwenden Jitter (zufällige Verzögerung), um nachfolgende Kollisionen zu verhindern. Da Sie hier nicht versuchen, solche Kollisionen zu verhindern, müssen Sie diese Zufallszahl nicht verwenden. Wenn Sie jedoch gleichzeitige Clients verwenden, kann Jitter dazu beitragen, dass Ihre Anforderungen schneller verarbeitet werden. Weitere Informationen finden Sie im Blogbeitrag zu Exponentielles Backoff und Jitter.

Batchoperationen und Fehlerbehandlung

Die Low-Level-API von DynamoDB unterstützt Batch-Operationen für Lese- und Schreibvorgänge. BatchGetItem liest Elemente aus einzelnen oder mehreren Tabellen und BatchWriteItem schreibt Elemente in einzelne oder mehrere Tabellen oder löscht sie daraus. Diese Batchoperationen werden als Wrapper um andere Nicht-Batch-DynamoDB-Operationen herum implementiert. Mit anderen Worten, BatchGetItem ruft GetItem einmal für jedes Element im Stapel auf. Ebenso ruft BatchWriteItem DeleteItem oder PutItem für jedes Element im Stapel auf, je nachdem.

Eine Stapeloperation kann den Ausfall einzelner Anforderungen im Stapel tolerieren. Nehmen Sie beispielsweise eine BatchGetItem-Anforderung für das Lesen von fünf Elementen. Auch wenn einige der zugrunde liegenden GetItem-Anforderungen fehlschlagen, führt dies nicht zum Ausfall der gesamten BatchGetItem-Operation. Wenn jedoch alle fünf Leseoperationen fehlschlagen, schlägt der gesamte BatchGetItem-Vorgang fehl.

Die Stapeloperationen geben Informationen zu ausgefallenen individuellen Anforderungen zurück, sodass Sie das Problem diagnostizieren und die Operation wiederholen können. Für BatchGetItem werden die jeweiligen Tabellen und primären Schlüssel in den UnprocessedKeys-Wert der Antwort zurückgegeben. Für BatchWriteItem werden die gleichen Informationen in UnprocessedItems zurückgegeben.

Vermutlich ist die Ursache für einen fehlgeschlagenen Lese- oder Schreibvorgang eine Drosselung. Für BatchGetItem steht einer oder mehreren Tabellen in der Stapelanforderung nicht ausreichend Lesekapazität zur Verfügung, um die Operation zu unterstützen. Für BatchWriteItem steht einer oder mehreren Tabellen nicht ausreichend Schreibkapazität zur Verfügung.

Wenn DynamoDB unverarbeitete Elemente zurückgibt, sollten Sie die Batchoperation für diese Elemente wiederholen. Jedoch empfehlen wir dringend, dass Sie einen exponentiellen Backoff-Algorithmus verwenden. Wenn Sie die Stapeloperation sofort wiederholen, können die zugrunde liegenden Lese- und Schreibanforderungen dennoch aufgrund einer Drosselung der einzelnen Tabellen fehlschlagen. Wenn Sie die Stapeloperation mithilfe des exponentiellen Backoff verzögern, werden die einzelnen Anforderungen in dem Stapel eher erfolgreich sein.