Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Praktik dan persyaratan terbaik untuk mengelola tabel global DynamoDB

Menggunakan tabel global Amazon DynamoDB, Anda dapat mereplikasi data tabel Anda di seluruh Wilayah. AWS Tabel replika dan indeks sekunder di tabel global Anda harus memiliki pengaturan kapasitas tulis yang identik untuk memastikan replikasi data yang tepat.

Untuk kejelasan di masa mendatang, sebaiknya jangan mencantumkan Wilayah dalam nama tabel mana pun yang mungkin suatu saat akan diubah menjadi tabel global.

Versi tabel global

Untuk menentukan versi tabel global yang Anda gunakan, lihatMenentukan versi tabel global DynamoDB yang Anda gunakan.

Persyaratan untuk Mengelola Kapasitas

Tabel global harus memiliki kapasitas throughput yang dikonfigurasi dengan salah satu dari dua cara berikut:

Penggunaan mode kapasitas yang disediakan dengan penskalaan otomatis atau mode kapasitas sesuai permintaan membantu memastikan tabel global memiliki kapasitas yang memadai untuk melakukan replikasi tulis ke semua wilayah tabel global.

Men-deploy tabel global

Dalam AWS CloudFormation, setiap tabel global dikendalikan oleh satu tumpukan dalam satu Wilayah. Hal ini terlepas dari jumlah replika. Ketika Anda menerapkan template Anda, CloudFormation akan membuat/memperbarui semua replika sebagai bagian dari operasi tumpukan tunggal. Oleh karena itu, Anda tidak boleh men-deploy sumber daya AWS::DynamoDB::GlobalTable yang sama di beberapa Wilayah. Tindakan tersebut tidak didukung dan akan mengakibatkan kesalahan.

Jika men-deploy templat aplikasi di beberapa Wilayah, Anda dapat menggunakan syarat untuk membuat sumber daya hanya di satu Wilayah. Alternatifnya, Anda dapat memilih untuk menentukan sumber daya AWS::DynamoDB::GlobalTable Anda dalam tumpukan yang terpisah dari tumpukan aplikasi Anda dan memastikan sumber daya tersebut hanya disebarkan ke satu Wilayah. Untuk informasi selengkapnya lihat tabel Global di CloudFormation

Tabel DynamoDB disebut sebagai AWS::DynamoDB::Table, dan tabel global adalah AWS::DynamoDB::GlobalTable. CloudFormation Sejauh menyangkut, ini pada dasarnya menjadikan mereka dua sumber daya yang berbeda. Dengan demikian, salah satu pendekatannya adalah membuat semua tabel yang mungkin bersifat global menggunakan konstruksi GlobalTable. Anda kemudian dapat menyimpannya sebagai tabel mandiri untuk memulai, dan menambahkannya nanti ke Wilayah jika diperlukan.

Jika Anda memiliki tabel biasa dan Anda ingin mengonversinya saat menggunakan CloudFormation, metode yang disarankan adalah:

Menggunakan tabel global untuk membantu menangani potensi gangguan Wilayah

Memiliki atau dapat dengan cepat membuat salinan independen dari tumpukan eksekusi Anda di Wilayah alternatif, masing-masing mengakses titik akhir DynamoDB lokalnya.

Gunakan Route53 atau rute AWS Global Accelerator ke Wilayah sehat terdekat. Sebagai alternatif, buat klien mengetahui beberapa titik akhir yang mungkin digunakannya.

Gunakan pemeriksaan kondisi di setiap Wilayah yang akan dapat menentukan secara andal apakah ada masalah dengan tumpukan, termasuk apakah DynamoDB mengalami degradasi. Misalnya, jangan hanya melakukan ping bahwa titik akhir DynamoDB sudah aktif. Lakukan panggilan untuk memastikan aliran basis data berhasil sepenuhnya.

Jika pemeriksaan kesehatan gagal, lalu lintas dapat merutekan ke Wilayah lain (dengan memperbarui DNS entri dengan Route53, dengan memiliki rute Akselerator Global secara berbeda, atau dengan meminta klien memilih titik akhir yang berbeda). Tabel global memiliki RPO (tujuan titik pemulihan) yang baik karena data terus disinkronkan dan baik RTO (tujuan waktu pemulihan) karena kedua Wilayah selalu menyiapkan tabel untuk lalu lintas baca dan tulis.

Untuk informasi selengkapnya tentang pemeriksaan kondisi, lihat Jenis pemeriksaan kondisi.

Mencadangkan tabel global

Saat mencadangkan tabel global, pencadangan tabel di satu Wilayah sudah cukup dan mencadangkan semua tabel di semua Wilayah seharusnya tidak diperlukan. Jika tujuannya adalah untuk dapat memulihkan data yang dihapus atau dimodifikasi secara keliru, maka PITR dalam satu Wilayah sudah cukup. Demikian pula, ketika menyimpan snapshot untuk tujuan historis seperti persyaratan peraturan, maka pencadangan di satu Wilayah sudah cukup. Data yang dicadangkan dapat direplikasi ke beberapa Wilayah melalui AWS Backup.

Replika dan menghitung unit tulis

Untuk perencanaan, Anda harus mengambil jumlah penulisan yang akan dilakukan oleh satu Wilayah dan menambahkannya ke jumlah penulisan yang terjadi di setiap Wilayah lainnya. Ini sangat penting karena setiap penulisan yang dilakukan di satu Wilayah juga harus dilakukan di setiap Wilayah replika. Jika Anda tidak memiliki kapasitas yang mamadai untuk menangani semua penulisan, pengecualian kapasitas akan terjadi. Selain itu, waktu tunggu replikasi antarwilayah akan meningkat.

Misalnya, anggaplah Anda mengharapkan 5 aktivitas tulis per detik untuk tabel replika Anda di Ohio, 10 aktivitas tulis per detik untuk tabel replika Anda di Virginia Utara, dan 5 aktivitas tulis per detik untuk tabel replika Anda di Irlandia. Dalam hal ini, Anda harus mengharapkan untuk mengkonsumsi 20 rWCUs atau rWRUs di setiap Wilayah: Ohio, Virginia N., dan Irlandia. Dengan kata lain, Anda harus mengharapkan untuk mengkonsumsi rWCUs total 60 di ketiga Wilayah.

Untuk detail tentang kapasitas yang disediakan dengan penskalaan otomatis dan DynamoDB, lihat Mengelola kapasitas throughput secara otomatis dengan penskalaan otomatis DynamoDB.