Fehlerbehandlung mit DynamoDB

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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 der häufigsten Fehler, die für alle AWS Dienste gelten, finden Sie unter Access Management

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:

AWS SDKs Sie kümmern sich darum, dass Fehler an Ihre Anwendung weitergegeben werden, 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.

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?

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.

AWS SDKs Sie führen ihre eigenen Wiederholungen und Fehlerprüfungen durch. Wenn Sie bei der Verwendung eines der Geräte auf einen Fehler stoßen AWS SDKs, können Ihnen der Fehlercode und die Beschreibung bei der Behebung helfen.

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

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 die Wiederholungslogik automatisch. 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 dem AWS SDK for Java könnten Sie die ClientConfiguration Klasse verwenden und den maxErrorRetry Wert von angeben, 0 um die Wiederholungsversuche auszuschalten. Weitere Informationen finden Sie in der AWS SDK-Dokumentation für Ihre Programmiersprache.

Wenn Sie kein AWS SDK verwenden, sollten Sie die ursprünglichen Anfragen, bei denen Serverfehler auftreten, erneut versuchen (5xx). 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.

Zusätzlich zu einfachen Wiederholungsversuchen implementiert jedes AWS SDK einen exponentiellen Backoff-Algorithmus für eine bessere Flusskontrolle. 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.

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.