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

Komponen kesalahan

Ketika program Anda mengirimkan permintaan, DynamoDB mencoba untuk memprosesnya. Jika permintaan berhasil, DynamoDB mengembalikan HTTP kode status sukses 200 OK (), bersama dengan hasil dari operasi yang diminta.

Jika permintaan tidak berhasil, DynamoDB menampilkan kesalahan. Setiap kesalahan memiliki tiga komponen:

AWS SDKsBerhati-hatilah menyebarkan 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

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.

HTTPkode status 400

Kode HTTP 400 status menunjukkan masalah dengan permintaan Anda, seperti kegagalan otentikasi, parameter yang diperlukan hilang, atau melebihi throughput yang disediakan tabel. Anda harus memperbaiki masalah di aplikasi Anda sebelum mengirimkan permintaan lagi.

HTTPkode status 5xx

Kode HTTP 5xx status 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 untuk melihat apakah ada masalah operasional dengan layanan ini.

Untuk informasi selengkapnya, lihat Bagaimana cara mengatasi kesalahan HTTP 5xx di Amazon DynamoDB?

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 SDKsMelakukan 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 pada jaringan, seperti DNS server, switch, load balancer, dan lainnya, dapat menghasilkan kesalahan di mana saja dalam kehidupan permintaan yang diberikan. Teknik biasa untuk menangani respons kesalahan ini dalam lingkungan jaringan adalah dengan menerapkan percobaan ulang dalam aplikasi klien. Teknik ini meningkatkan keandalan aplikasi.

Masing-masing AWS SDK mengimplementasikan logika coba lagi 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 for Java, Anda dapat menggunakan ClientConfiguration kelas dan memberikan maxErrorRetry nilai 0 untuk mematikan percobaan ulang. Untuk informasi selengkapnya, lihat AWS SDK dokumentasi 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.

Selain percobaan ulang sederhana, masing-masing 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.

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.

Operasi batch dan penanganan kesalahan

DynamoDB API tingkat rendah mendukung operasi batch untuk membaca dan menulis. BatchGetItemmembaca item dari satu atau beberapa tabel, dan BatchWriteItem menempatkan 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.