Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Penanganan kesalahan dengan DynamoDB
Bagian ini menjelaskan kesalahan runtime dan cara menanganinya. Kode dan pesan kesalahan yang khusus untuk Amazon DynamoDB juga dijelaskan dalam bagian ini. Untuk daftar kesalahan umum yang berlaku untuk semua AWS layanan, lihat [Manajemen Akses](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/CommonErrors.html)
**Topics**
+ [Komponen kesalahan](#Programming.Errors.Components)
+ [Kesalahan transaksional](#Programming.Errors.TransactionalErrors)
+ [Pesan dan kode kesalahan](#Programming.Errors.MessagesAndCodes)
+ [Penanganan kesalahan dalam aplikasi Anda](#Programming.Errors.Handling)
+ [Percobaan ulang kesalahan dan penundaan eksponensial](#Programming.Errors.RetryAndBackoff)
+ [Operasi batch dan penanganan kesalahan](#Programming.Errors.BatchOperations)
## Komponen kesalahan
Ketika program Anda mengirimkan permintaan, DynamoDB mencoba untuk memprosesnya. Jika permintaan berhasil, DynamoDB akan menghasilkan kode status sukses HTTP (`200 OK`), bersama dengan hasil dari operasi yang diminta.
Jika permintaan tidak berhasil, DynamoDB menampilkan kesalahan. Setiap kesalahan memiliki tiga komponen:
+ Kode status HTTP (seperti `400`).
+ Nama pengecualian (seperti `ResourceNotFoundException`).
+ Pesan kesalahan (seperti `Requested resource not found: Table: tablename not found`).
AWS SDKs Jaga penyebaran kesalahan ke aplikasi Anda sehingga Anda dapat mengambil tindakan yang tepat. Misalnya, dalam program Java, Anda bisa menulis logika `try-catch` untuk menangani `ResourceNotFoundException`.
Jika Anda tidak menggunakan AWS SDK, Anda perlu mengurai konten respons tingkat rendah dari DynamoDB. Berikut ini adalah contoh respons tersebut.
```
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"}
```
## Kesalahan transaksional
Untuk informasi tentang kesalahan transaksional, lihat [Penanganan konflik transaksi di DynamoDB](transaction-apis.md#transaction-conflict-handling)
## Pesan dan kode kesalahan
Berikut ini adalah daftar pengecualian yang dikembalikan oleh DynamoDB, dikelompokkan berdasarkan kode status HTTP. Jika *Boleh diulang?* adalah *Ya*, Anda dapat mengirimkan permintaan yang sama lagi. Jika *Boleh diulang?* adalah *Tidak*, Anda harus memperbaiki masalah di sisi klien sebelum mengirimkan permintaan baru.
### Kode status HTTP 400
Kode status `400` HTTP menunjukkan adanya masalah dengan permintaan Anda, seperti kegagalan autentikasi, parameter yang diperlukan tidak ada, atau melebihi throughput yang disediakan tabel. Anda harus memperbaiki masalah di aplikasi Anda sebelum mengirimkan permintaan lagi.
**AccessDeniedException **
Pesan: *Akses ditolak.*
Klien salah menandatangani permintaan. Jika Anda menggunakan AWS SDK, permintaan ditandatangani untuk Anda secara otomatis; jika tidak, buka [Proses penandatanganan Tanda Tangan versi 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) di *Referensi Umum AWS*.
Boleh diulang? Tidak
**ConditionalCheckFailedException**
Pesan: *Permintaan bersyarat gagal.*
Anda menentukan syarat yang dievaluasi ke false. Misalnya, Anda mungkin telah mencoba melakukan pembaruan bersyarat pada suatu item, tetapi nilai atribut sebenarnya tidak cocok dengan nilai yang diharapkan dalam kondisi yang dihadapi.
Boleh diulang? Tidak
**IncompleteSignatureException**
Pesan: *Tanda tangan permintaan tidak sesuai dengan standar AWS .*
Tanda tangan permintaan tidak menyertakan semua komponen yang diperlukan. Jika Anda menggunakan AWS SDK, permintaan ditandatangani untuk Anda secara otomatis; jika tidak, buka [proses penandatanganan Versi Tanda Tangan 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) di *Referensi Umum AWS*.
Ingin mengulang? Tidak
**ItemCollectionSizeLimitExceededException**
Pesan: *Ukuran koleksi terlampaui.*
Untuk tabel dengan indeks sekunder lokal, sekelompok item dengan nilai kunci partisi yang sama telah melampaui batas ukuran maksimum 10 GB. Untuk informasi selengkapnya tentang kumpulan item, lihat [Kumpulan item dalam Indeks Sekunder Lokal](LSI.md#LSI.ItemCollections).
Boleh diulang? Ya
**LimitExceededException**
Pesan: *Terlalu banyak operasi untuk pelanggan tertentu.*
Terlalu banyak operasi bidang kontrol secara bersamaan. Jumlah kumulatif tabel dan indeks dalam `CREATING`, `DELETING`, atau keadaan `UPDATING` tidak boleh melebihi 500.
Boleh diulang? Ya
**MissingAuthenticationTokenException**
Pesan: *Permintaan harus berisi ID Kunci Akses AWS yang valid (terdaftar).*
Permintaan tidak menyertakan header otorisasi yang diperlukan, atau formatnya salah. Lihat [API tingkat rendah DynamoDB](Programming.LowLevelAPI.md).
Boleh diulang? Tidak
**ProvisionedThroughputExceededException**
Pesan: *Anda melampaui throughput maksimum yang diizinkan untuk sebuah tabel atau untuk satu atau beberapa indeks sekunder global. [Untuk melihat metrik kinerja untuk throughput yang disediakan vs. throughput yang dikonsumsi, buka konsol Amazon. CloudWatch](https://console.aws.amazon.com/cloudwatch/home)*
Kesalahan mencakup daftar `ThrottlingReason` bidang yang menyediakan konteks spesifik tentang mengapa pelambatan terjadi, mengikuti format `ResourceType+OperationType+LimitType` (misalnya,`TableReadProvisionedThroughputExceeded`) dan ARN sumber daya yang terpengaruh. Ini membantu Anda mengidentifikasi sumber daya mana yang sedang dibatasi (tabel atau indeks), jenis operasi apa yang memicu pelambatan (baca atau tulis), dan batas spesifik yang terlampaui (dalam hal ini: kapasitas yang disediakan). Untuk informasi selengkapnya tentang mendiagnosis dan menyelesaikan masalah pelambatan, lihat. [Mendiagnosis pelambatan](throttling-diagnosing-workflow.md)
Contoh: Tingkat permintaan Anda terlalu tinggi. AWS SDKs Untuk DynamoDB secara otomatis mencoba kembali permintaan yang menerima pengecualian ini. Permintaan Anda akhirnya berhasil, kecuali antrean percobaan ulang Anda terlalu besar untuk diselesaikan. Kurangi frekuensi permintaan menggunakan [Percobaan ulang kesalahan dan penundaan eksponensial](#Programming.Errors.RetryAndBackoff).
Boleh diulang? Ya
**ReplicatedWriteConflictException**
Pesan: *Satu atau beberapa item dalam permintaan ini sedang dimodifikasi oleh permintaan di Wilayah lain.*
Contoh: Operasi tulis diminta untuk item dalam tabel global Multi-region yang sangat konsisten (MRSC) yang saat ini sedang dimodifikasi oleh permintaan di Wilayah lain.
Boleh diulang? Ya
**RequestLimitExceeded**
Pesan: *Throughput melebihi batas throughput saat ini untuk akun Anda. Untuk meminta peningkatan batas, hubungi AWS Support di [https://aws.amazon.com/support](https://aws.amazon.com/support)*.
Kesalahan mencakup daftar `ThrottlingReason` bidang yang menyediakan konteks spesifik tentang mengapa pelambatan terjadi, mengikuti format `ResourceType+OperationType+LimitType` (misalnya, `TableWriteAccountLimitExceeded` atau`IndexReadAccountLimitExceeded`) dan ARN sumber daya yang terpengaruh. Ini membantu Anda mengidentifikasi sumber daya mana yang sedang dibatasi (tabel atau indeks), jenis operasi apa yang memicu pelambatan (baca atau tulis), dan bahwa Anda telah melampaui kuota layanan tingkat akun. Untuk informasi selengkapnya tentang mendiagnosis dan menyelesaikan masalah pelambatan, lihat. [Mendiagnosis pelambatan](throttling-diagnosing-workflow.md)
Contoh: Tingkat permintaan sesuai permintaan melebihi throughput akun yang diizinkan dan tabel tidak dapat diskalakan lebih lanjut.
Boleh diulang? Ya
**ResourceInUseException**
Pesan: *Sumber daya yang Anda coba ubah sedang digunakan.*
Contoh: Anda mencoba untuk membuat ulang tabel yang sudah ada, atau menghapus tabel yang saat ini dalam status `CREATING`.
Boleh diulang? Tidak
**ResourceNotFoundException **
Pesan: *Sumber daya yang diminta tidak ditemukan.*
Contoh: Tabel yang diminta tidak ada, atau terlalu dini dalam status `CREATING`.
Boleh diulang? Tidak
**ThrottlingException**
Pesan: *Tingkat permintaan melebihi throughput yang diizinkan.*
Pengecualian ini dikembalikan sebagai AmazonServiceException respons dengan kode status THROTTLING\$1EXCEPTION. Pengecualian ini mungkin dikembalikan jika Anda melakukan operasi API [bidang kontrol](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.ControlPlane) terlalu cepat.
Untuk tabel yang menggunakan mode sesuai permintaan, pengecualian ini mungkin dikembalikan untuk setiap operasi API [bidang data](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.API.html#HowItWorks.API.DataPlane) jika tingkat permintaan Anda terlalu tinggi. Untuk mempelajari lebih lanjut tentang penskalaan sesuai permintaan, lihat. [Throughput awal dan properti penskalaan](on-demand-capacity-mode.md#on-demand-capacity-mode-initial)
Kesalahan mencakup daftar `ThrottlingReason` bidang yang menyediakan konteks spesifik tentang mengapa pelambatan terjadi, mengikuti format `ResourceType+OperationType+LimitType` (misalnya, `TableReadKeyRangeThroughputExceeded` atau`IndexWriteMaxOnDemandThroughputExceeded`) dan ARN sumber daya yang terpengaruh. Informasi ini membantu Anda mengidentifikasi sumber daya mana yang sedang dibatasi (tabel atau indeks), jenis operasi apa yang memicu pelambatan (baca atau tulis), dan batas spesifik yang terlampaui (batas partisi atau throughput maksimum sesuai permintaan). Untuk informasi selengkapnya tentang mendiagnosis dan menyelesaikan masalah pelambatan, lihat. [Mendiagnosis pelambatan](throttling-diagnosing-workflow.md)
Boleh diulang? Ya
**UnrecognizedClientException**
Pesan: *ID Kunci Akses atau token keamanan tidak valid.*
Tanda tangan permintaan tidak benar. Penyebab yang paling mungkin adalah ID kunci AWS akses atau kunci rahasia yang tidak valid.
Boleh diulang? Ya
**ValidationException**
Pesan: Bervariasi, tergantung pada kesalahan tertentu yang dialami
Kesalahan ini dapat terjadi karena beberapa alasan, seperti parameter yang diperlukan tidak ada, nilai di luar rentang, atau jenis data tidak cocok. kesalahan berisi detail tentang bagian tertentu dari permintaan yang menyebabkan kesalahan.
Boleh diulang? Tidak
### Kode status HTTP 5xx
Kode status `5xx` HTTP menunjukkan masalah yang harus diselesaikan oleh AWS. Kemungkinan ini adalah kesalahan sementara, sehingga Anda dapat mencoba lagi permintaan Anda hingga berhasil. Jika tidak, masuk ke [Service Health Dashboard AWS](https://status.aws.amazon.com/) untuk melihat apakah ada masalah operasional dengan layanan ini.
Untuk informasi selengkapnya, lihat [Bagaimana cara mengatasi kesalahan HTTP 5xx di Amazon DynamoDB?](https://aws.amazon.com/premiumsupport/knowledge-center/dynamodb-http-5xx-errors/)
**InternalServerError (HTTP 500)**
DynamoDB tidak dapat memproses permintaan Anda.
Boleh diulang? Ya
Anda mungkin mengalami kesalahan server internal saat menggunakan item. Ini diduga terjadi selama masa aktif tabel. Setiap permintaan yang gagal dapat segera dicoba kembali.
Ketika Anda menerima kode status 500 pada operasi tulis, operasi tersebut mungkin berhasil atau gagal. Jika operasi tulis adalah permintaan `TransactWriteItem`, maka boleh saja mencoba ulang operasi tersebut. Jika operasi tulis adalah permintaan penulisan item tunggal seperti`PutItem`,, atau `UpdateItem``DeleteItem`, maka aplikasi Anda harus membaca status item sebelum mencoba kembali operasi, and/or gunakan [Contoh CLI ekspresi kondisi DynamoDB](Expressions.ConditionExpressions.md) untuk memastikan bahwa item tetap dalam keadaan yang benar setelah mencoba kembali terlepas dari apakah operasi sebelumnya berhasil atau gagal. Jika idempotensi adalah persyaratan untuk operasi tulis, gunakan [`TransactWriteItem`](transaction-apis.md#transaction-apis-txwriteitems), yang mendukung permintaan idempoten dengan menentukan `ClientRequestToken` secara otomatis untuk membedakan beberapa upaya untuk melakukan tindakan yang sama.
**ServiceUnavailable (HTTP 503)**
DynamoDB saat ini tidak tersedia. (Ini harus merupakan status sementara.)
Boleh diulang? Ya
## Penanganan kesalahan dalam aplikasi Anda
Agar aplikasi Anda berjalan lancar, Anda perlu menambahkan logika untuk menangkap dan merespons kesalahan. Pendekatan umum termasuk menggunakan blok `try-catch` atau pernyataan `if-then`.
AWS SDKs Melakukan percobaan ulang dan pengecekan kesalahan mereka sendiri. Jika Anda menemukan kesalahan saat menggunakan salah satu AWS SDKs, kode kesalahan dan deskripsi dapat membantu Anda memecahkan masalah itu.
Anda juga akan melihat `Request ID` dalam respons. Ini `Request ID` dapat membantu jika Anda perlu bekerja dengan AWS Support untuk mendiagnosis suatu masalah.
## Percobaan ulang kesalahan dan penundaan eksponensial
Banyak komponen di jaringan, seperti server DNS, sakelar, penyeimbang beban, dan lainnya, dapat menghasilkan kesalahan di mana pun selama permintaan tertentu. Teknik biasa untuk menangani respons kesalahan ini dalam lingkungan jaringan adalah dengan menerapkan percobaan ulang dalam aplikasi klien. Teknik ini meningkatkan keandalan aplikasi.
Setiap AWS SDK mengimplementasikan logika coba ulang secara otomatis. Anda dapat mengubah parameter percobaan ulang sesuai kebutuhan Anda. Misalnya, pertimbangkan aplikasi Java yang memerlukan strategi gagal cepat (fail fast), dengan tidak memperbolehkan percobaan ulang jika terjadi kesalahan. Dengan AWS SDK untuk Java, Anda dapat menggunakan `ClientConfiguration` kelas dan memberikan `maxErrorRetry` nilai `0` untuk mematikan percobaan ulang. Untuk informasi selengkapnya, lihat dokumentasi AWS SDK untuk bahasa pemrograman Anda.
Jika Anda tidak menggunakan AWS SDK, Anda harus mencoba kembali permintaan asli yang menerima kesalahan server (5xx). Namun, kesalahan klien (4xx, selain `ThrottlingException` atau `ProvisionedThroughputExceededException`) menunjukkan bahwa Anda perlu merevisi permintaan itu sendiri untuk memperbaiki masalah sebelum melakukan percobaan ulang. [Untuk rekomendasi terperinci untuk mengatasi skenario pelambatan tertentu, lihat bagian pemecahan masalah pelambatan DynamoDB.](TroubleshootingThrottling.md)
Selain percobaan ulang sederhana, setiap AWS SDK mengimplementasikan algoritma backoff eksponensial untuk kontrol aliran yang lebih baik. Konsep di balik penundaan eksponensial adalah menggunakan waktu tunggu yang lebih lama di antara percobaan ulang untuk respon kesalahan berturut-turut. Sebagai contoh, hinga 50 milidetik sebelum percobaan ulang pertama, hingga 100 milidetik sebelum percobaan ulang kedua, hingga 200 milidetik sebelum percobaan ulang ketiga, dan seterusnya. Namun, setelah satu menit, jika permintaan tidak berhasil, masalahnya mungkin pada ukuran permintaan yang melebihi throughput yang disediakan, dan bukan pada tingkat permintaan. Tetapkan jumlah maksimum percobaan ulang untuk berhenti sekitar satu menit. Jika permintaan tidak berhasil, selidiki opsi throughput yang disediakan.
**catatan**
AWS SDKs Mengimplementasikan logika coba ulang otomatis dan backoff eksponensial.
Kebanyakan algoritma penundaan eksponensial menggunakan jitter (penundaan acak) untuk mencegah tabrakan berturut-turut. Karena Anda tidak berusaha menghindari tabrakan seperti itu dalam kasus ini, Anda tidak perlu menggunakan nomor acak ini. Namun, jika Anda menggunakan klien secara bersamaan, jitter dapat membantu permintaan Anda berhasil lebih cepat. Untuk informasi selengkapnya, lihat postingan blog tentang [Penundaan eksponensial dan jitter](http://www.awsarchitectureblog.com/2015/03/backoff.html).
## Operasi batch dan penanganan kesalahan
API tingkat rendah DynamoDB mendukung operasi batch untuk baca dan tulis. `BatchGetItem` membaca item dari satu atau beberapa tabel, dan `BatchWriteItem` memasukkan atau menghapus item dalam satu atau beberapa tabel. Operasi batch ini diimplementasikan sebagai pembungkus di sekitar operasi DynamoDB non-batch lainnya. Dengan kata lain, `BatchGetItem` menginvokasi `GetItem` sekali untuk setiap item dalam batch. Demikian pula, `BatchWriteItem` menginvokasi `DeleteItem` atau `PutItem`, jika sesuai, untuk setiap item dalam batch.
Operasi batch dapat menoleransi kegagalan permintaan individual dalam batch. Misalnya, pertimbangkan `BatchGetItem` untuk membaca lima item. Meskipun beberapa permintaan `GetItem` yang mendasarinya gagal, ini tidak menyebabkan seluruh operasi `BatchGetItem` gagal. Namun, jika kelima operasi baca gagal, maka seluruh `BatchGetItem` akan gagal pula.
Operasi batch mengembalikan informasi tentang masing-masing permintaan yang gagal sehingga Anda dapat mendiagnosis masalah dan mencoba kembali operasi tersebut. Untuk `BatchGetItem`, tabel dan kunci primer yang dimaksud dikembalikan dalam nilai `UnprocessedKeys` respons. Untuk `BatchWriteItem`, informasi serupa dikembalikan dalam `UnprocessedItems`.
Kemungkinan besar penyebab gagalnya baca atau tulis adalah *throttling*. Untuk `BatchGetItem`, satu atau beberapa tabel dalam permintaan batch tidak memiliki kapasitas baca yang memadai untuk mendukung operasi. Untuk `BatchWriteItem`, satu atau beberapa tabel tidak memiliki kapasitas tulis yang memadai.
Jika DynamoDB mengembalikan item yang belum diproses, Anda harus mencoba ulang operasi batch pada item tersebut. Namun, *kami sangat merekomendasikan agar Anda menggunakan algoritma penundaan eksponensial*. Jika Anda segera mencoba ulang operasi batch, permintaan baca atau tulis yang mendasarinya masih bisa gagal karena throttling pada masing-masing tabel. Jika Anda menunda operasi batch menggunakan penundaan eksponensial, masing-masing permintaan dalam batch kemungkinan besar akan berhasil.
**catatan**
Beberapa AWS SDKs menyediakan klien tingkat tinggi yang menangani percobaan ulang item yang belum diproses secara otomatis, jadi Anda tidak perlu menerapkan logika coba lagi ini sendiri. Contoh:
**Java** [— [DynamoDB Enhanced](DynamoDBEnhanced.md) Client di AWS SDK untuk Java v2 dan DBMapper Dynamo in v1 keduanya secara otomatis mencoba kembali item yang belum diproses saat melakukan operasi batch.](DynamoDBMapper.md)
**Python** - Sumber daya Tabel boto3 `batch_writer` menangani percobaan ulang item yang belum diproses secara implisit untuk operasi penulisan batch. Untuk informasi selengkapnya, lihat [Menggunakan sumber daya tabel batch\$1writer](programming-with-python.md#programming-with-python-batch-writer).
Jika Anda menggunakan klien tingkat rendah atau SDK yang tidak memberikan perilaku ini, Anda harus menerapkan logika coba lagi sendiri seperti yang dijelaskan di atas.