Daftar periksa persiapan untuk tabel global DynamoDB

Tentukan apakah kasus penggunaan Anda lebih diuntungkan dari mode konsistensi MRSC atau MREC. Apakah Anda memerlukan konsistensi yang kuat, bahkan dengan latensi yang lebih tinggi dan pengorbanan lainnya?

Tentukan jumlah dan Wilayah yang akan berpartisipasi dalam tabel global. Jika Anda berencana untuk menggunakan MRSC, putuskan apakah Anda ingin Wilayah ketiga menjadi replika atau saksi.

Tentukan mode tulis aplikasi Anda. Ini tidak sama dengan mode konsistensi. Untuk informasi selengkapnya, lihat Tulis mode dengan tabel global DynamoDB.

Rencanakan strategi Strategi perutean di DynamoDB, berdasarkan mode tulis Anda.

Tentukan Proses evakuasi, berdasarkan mode konsistensi, mode tulis, dan strategi perutean Anda.

Tangkap metrik tentang kesehatan, latensi, dan kesalahan di setiap Wilayah. Untuk daftar metrik DynamoDB, lihat AWS posting blog Memantau Amazon DynamoDB untuk Kesadaran Operasional untuk daftar metrik yang harus diamati. Anda juga harus menggunakan synthetic canary (permintaan buatan yang dirancang untuk mendeteksi kegagalan, dinamai menurut nama kenari di tambang batu bara), serta pengamatan langsung terhadap lalu lintas pelanggan. Tidak semua masalah akan muncul di metrik DynamoDB.

Jika Anda menggunakan MREC, atur alarm untuk setiap peningkatan berkelanjutan. ReplicationLatency Peningkatan mungkin menunjukkan kesalahan konfigurasi yang tidak disengaja, yaitu tabel global memiliki pengaturan tulis berbeda di Wilayah berbeda, yang menyebabkan kegagalan permintaan yang direplikasi dan peningkatan latensi. Hal ini juga dapat mengindikasikan adanya gangguan regional. Contoh yang baik adalah menghasilkan peringatan jika rata-rata terkini melebihi 180.000 milidetik. Anda mungkin juga memperhatikan ReplicationLatency penurunan ke 0, yang menunjukkan replikasi terhenti.

Tetapkan pengaturan baca dan tulis maksimum yang memadai untuk setiap tabel global.

Identifikasi terlebih dahulu alasan untuk mengevakuasi suatu Wilayah. Jika keputusan melibatkan penilaian manusia, dokumentasikan semua pertimbangannya. Pekerjaan ini harus dilakukan dengan hati-hati sebelumnya, bukan di bawah tekanan.

Simpan runbook untuk setiap tindakan yang harus dilakukan saat Anda mengevakuasi suatu Wilayah. Biasanya pekerjaan yang dilakukan untuk tabel global sangat sedikit, tetapi memindahkan sisa tumpukan dapat menjadi pekerjaan yang rumit.

Untuk informasi selengkapnya, lihat posting AWS blog Membangun aplikasi tangguh dengan tabel global Amazon DynamoDB: Bagian 4.

Uji semua aspek runbook secara berkala, termasuk evakuasi Wilayah. Runbook yang belum teruji adalah runbook yang tidak dapat diandalkan.

Pertimbangkan AWS Resilience Hubuntuk mengevaluasi ketahanan seluruh aplikasi Anda (termasuk tabel global). Resilience Hub memberikan pandangan komprehensif tentang status ketahanan portofolio aplikasi Anda secara keseluruhan melalui dasbornya.

Pertimbangkan untuk menggunakan pemeriksaan kesiapan ARC untuk mengevaluasi konfigurasi aplikasi Anda saat ini dan melacak penyimpangan dari praktik terbaik.

Saat Anda menulis pemeriksaan kesehatan untuk digunakan dengan Route 53 atau Global Accelerator, buat serangkaian panggilan yang mencakup alur database lengkap. Jika Anda membatasi pemeriksaan untuk mengonfirmasi hanya bahwa titik akhir DynamoDB sudah habis, Anda tidak akan dapat mencakup banyak mode kegagalan AWS Identity and Access Management seperti kesalahan konfigurasi (IAM), masalah penerapan kode, kegagalan dalam tumpukan di luar DynamoDB, latensi baca atau tulis yang lebih tinggi dari rata-rata, dan sebagainya.

Operasi tulis dalam tabel DynamoDB tradisional diberi harga dalam unit kapasitas tulis WCUs (, untuk tabel yang disediakan) atau unit permintaan tulis () untuk tabel sesuai permintaan. WRUs Jika Anda menulis item 5 KB, itu dikenakan biaya 5 unit. Tulis ke tabel global diberi harga dalam unit kapasitas tulis yang direplikasi (rWCUs, untuk tabel yang disediakan) atau unit permintaan tulis yang direplikasi (rWRUs, untuk tabel sesuai permintaan). r WCUs dan r WRUs dihargai sama dengan dan. WGUs WRUs

Perubahan RWCu dan RwRU terjadi di setiap Wilayah di mana item ditulis secara langsung atau ditulis melalui replikasi. Biaya transfer data Lintas Wilayah berlaku.

Menulis ke indeks sekunder global (GSI) dianggap sebagai operasi penulisan lokal dan menggunakan unit tulis reguler.

Tidak ada kapasitas cadangan yang tersedia untuk r WCUs atau r WRUs saat ini. Membeli kapasitas cadangan untuk WCUs dapat bermanfaat untuk tabel di mana GSIs mengkonsumsi unit tulis.

Saat Anda menambahkan Wilayah baru ke tabel global, DynamoDB bootstrap Wilayah baru secara otomatis dan menagih Anda seolah-olah itu adalah pemulihan tabel, berdasarkan ukuran GB tabel. Ini juga membebankan biaya transfer data lintas wilayah.

Set Wilayah AS: AS Timur (Virginia Utara), AS Timur (Ohio), AS Barat (Oregon)

Set Wilayah UE: Eropa (Irlandia), Eropa (London), Eropa (Paris), Eropa (Frankfort)

Set Wilayah AP: Asia Pasifik (Tokyo), Asia Pasifik (Seoul), dan Asia Pasifik (Osaka)

Anda dapat menghapus tabel replika seperti Anda menghapus tabel lainnya. Menghapus tabel global akan menghentikan replikasi ke Wilayah tersebut dan menghapus salinan tabel yang disimpan di Wilayah tersebut. Namun, Anda tidak dapat menghentikan replikasi sambil menyimpan salinan tabel sebagai entitas independen, Anda juga tidak dapat menjeda replikasi.

Tabel MRSC harus ditempatkan tepat di tiga Wilayah. Untuk menghapus replika Anda harus menghapus semua replika dan saksi sehingga tabel MRSC menjadi tabel lokal.

Setiap tabel global menghasilkan aliran independen berdasarkan semua operasi penulisannya, dari mana pun mereka memulai. Anda dapat menggunakan aliran DynamoDB di satu Wilayah atau di semua Wilayah (secara independen). Jika ingin memproses operasi tulis lokal tetapi tidak direplikasi, Anda dapat menambahkan atribut Wilayah Anda sendiri ke setiap item untuk mengidentifikasi Wilayah penulisan. Anda kemudian dapat menggunakan filter peristiwa Lambda untuk memanggil fungsi Lambda hanya untuk operasi tulis di Wilayah lokal. Ini membantu dengan menyisipkan dan memperbarui operasi, tetapi tidak menghapus operasi.

Tabel global yang dikonfigurasi untuk konsistensi akhir Multi-wilayah (tabel MREC) mereplikasi perubahan dengan membaca perubahan tersebut dari aliran DynamoDB pada tabel replika dan menerapkan perubahan itu ke semua tabel replika lainnya. Oleh karena itu, DynamoDB diaktifkan secara default pada semua replika dalam tabel global MREC dan tidak dapat dinonaktifkan pada replika tersebut. Proses replikasi MREC dapat menggabungkan beberapa perubahan dalam waktu singkat menjadi satu operasi tulis yang direplikasi. Akibatnya, setiap aliran replika mungkin berisi catatan yang sedikit berbeda. Catatan DynamoDB Streams pada replika MREC selalu diurutkan berdasarkan per item, tetapi urutan antar item mungkin berbeda antar replika.

Tabel global yang dikonfigurasi untuk konsistensi kuat Multi-wilayah (tabel MRSC) tidak menggunakan DynamoDB Streams untuk replikasi, jadi fitur ini tidak diaktifkan secara default pada replika MRSC. Anda dapat mengaktifkan DynamoDB Streams pada replika MRSC. Catatan DynamoDB Streams pada replika MRSC identik untuk setiap replika dan selalu diurutkan berdasarkan per item, tetapi urutan antar item mungkin berbeda antar replika.

Operasi transaksional pada tabel MRSC akan menghasilkan kesalahan.

Operasi transaksional pada tabel MREC memberikan jaminan atomisitas, konsistensi, isolasi, dan daya tahan (ACID) hanya di Wilayah tempat operasi penulisan awalnya terjadi. Transaksi tidak didukung di seluruh Wilayah dalam tabel global. Misalnya, jika Anda memiliki tabel global MREC dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) dan melakukan TransactWriteItems operasi di Wilayah Timur AS (Ohio), Anda mungkin mengamati transaksi yang diselesaikan sebagian di Wilayah Barat AS (Oregon) saat perubahan direplikasi. Perubahan direplikasi ke Wilayah lain hanya setelah diterapkan di Wilayah sumber.

Jika Anda ingin memastikan ketahanan data, DynamoDB sudah menyediakan perlindungan itu. Layanan ini memastikan ketahanan.

Jika Anda ingin menyimpan snapshot untuk catatan historis (misalnya, untuk memenuhi persyaratan peraturan), membuat cadangan di satu Wilayah sudah cukup. Anda dapat menyalin cadangan ke Wilayah tambahan dengan menggunakan AWS Backup.

Jika Anda ingin memulihkan data yang dihapus atau dimodifikasi secara keliru, gunakan DynamoDB point-in-time recovery (PITR) di satu Wilayah.

CloudFormation merupakan tabel DynamoDB dan tabel global sebagai dua sumber daya terpisah: dan. AWS::DynamoDB::Table AWS::DynamoDB::GlobalTable Salah satu pendekatannya adalah membuat semua tabel yang berpotensi bersifat global dengan menggunakan GlobalTable konstruksi untuk menjaganya sebagai tabel mandiri pada awalnya, dan menambahkan Wilayah nanti jika perlu.

Dalam CloudFormation, setiap tabel global dikendalikan oleh satu tumpukan, dalam satu Wilayah, terlepas dari jumlah replika. Saat Anda menerapkan template Anda, CloudFormation membuat dan memperbarui semua replika sebagai bagian dari operasi tumpukan tunggal. Jangan 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 ketentuan untuk membuat sumber daya AWS::DynamoDB::GlobalTable 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 bahwa sumber daya tersebut disebarkan ke satu Wilayah.

Jika Anda memiliki tabel reguler dan Anda ingin mengonversinya menjadi tabel global sambil menjaganya agar tetap dikelola dengan CloudFormation kemudian mengatur kebijakan penghapusan keRetain, menghapus tabel dari tumpukan, mengonversi tabel ke tabel global di konsol, dan kemudian impor tabel global sebagai sumber daya baru ke tumpukan. Untuk informasi lebih lanjut, lihat AWS GitHub repositori.

Replikasi lintas akun tidak didukung saat ini.