Daftar periksa persiapan untuk tabel global DynamoDB

Tentukan apakah kasus penggunaan Anda lebih diuntungkan dari mode konsistensi MRSC atau MREC. Apakah Anda membutuhkan konsistensi yang kuat, bahkan dengan latensi yang lebih tinggi dan pertukaran 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 Menulis mode dengan tabel global DynamoDB.

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

Tentukan Anda 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 yang harus diamati, lihat Meman tau Amazon DynamoDB untuk Kesadaran Operasional di Blog Database. AWS 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 peningkatan ReplicationLatency berkelanjutan. 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 penurunan ReplicationLatency 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 Mem bangun 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 Hub untuk menggunakan untuk 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 setiap 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 aktif, Anda tidak akan dapat mencakup banyak mode kegagalan seperti kesalahan konfigurasi AWS Identity and Access Management (IAM), masalah penerapan kode, kegagalan dalam tumpukan di luar DynamoDB, latensi baca atau tulis yang lebih tinggi dari rata-rata, dan seterusnya.

Operasi penulisan dalam tabel DynamoDB tradisional dihargai dalam unit kapasitas tulis (WCU, untuk tabel yang disediakan) atau unit permintaan tulis (WRU) untuk tabel sesuai permintaan. Jika Anda menulis item 5 KB, itu dikenakan biaya 5 unit. Penulisan ke tabel global dihargai dalam unit kapasitas tulis yang direplikasi (RWCU, untuk tabel yang disediakan) atau unit permintaan tulis yang direplikasi (RWRU, untuk tabel sesuai permintaan). rwCU dan RWU dihargai sama dengan WGU dan WRU.

Perubahan RWCu dan RWru terjadi di setiap Wilayah di mana item ditulis secara langsung atau ditulis melalui replikasi. DynamoDB tidak membebankan biaya transfer data lintas wilayah untuk replikasi ini.

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

Tidak ada kapasitas cadangan yang tersedia untuk RWCU atau RWRU saat ini. Membeli kapasitas cadangan untuk WCU dapat bermanfaat untuk tabel di mana GSI menggunakan unit tulis.

Saat Anda menambahkan Region baru ke tabel global, DynamoDB melakukan bootstrap Wilayah baru secara otomatis dan menagih Anda seolah-olah itu adalah pemulihan tabel, berdasarkan ukuran GB tabel.

Wilayah AS ditetapkan: AS Timur (N.Virginia), AS Timur (Ohio), AS Barat (Oregon)

Wilayah UE ditetapkan: 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 digunakan 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 mulai. 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 operasi menyisipkan dan memperbarui, 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, Streams 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 operasi penulisan tunggal yang direplikasi. Akibatnya, aliran setiap replika mungkin berisi catatan yang sedikit berbeda. Catatan Streams DynamoDB 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 Streams DynamoDB untuk replikasi, jadi fitur ini tidak diaktifkan secara default pada replika MRSC. Anda dapat mengaktifkan Streams DynamoDB pada replika MRSC. Catatan Streams DynamoDB pada replika MRSC identik untuk setiap replika dan selalu dipesan 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 dalam 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 AS Timur (Ohio), Anda mungkin mengamati transaksi yang diselesaikan sebagian di Wilayah AS Barat (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 salah dihapus atau dimodifikasi, gunakan DynamoDB point-in-time recovery (PITR) di satu Wilayah.

CloudFormation mewakili tabel DynamoDB dan tabel global sebagai dua sumber daya terpisah: AWS::DynamoDB::Table dan. AWS::DynamoDB::GlobalTable Salah satu pendekatannya adalah membuat semua tabel yang berpotensi menjadi global dengan menggunakan GlobalTable konstruksi menyimpannya sebagai tabel mandiri pada awalnya, dan menambahkan Regions nanti jika perlu.

Di CloudFormation, setiap tabel global dikendalikan oleh satu tumpukan, dalam satu Wilayah, terlepas dari jumlah replika. Saat Anda menerapkan template Anda, buat CloudFormation dan perbarui semua replika sebagai bagian dari operasi tumpukan tunggal. Anda tidak boleh menggunakan GlobalTable sumber daya AWS::Dynamo DB:: 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 biasa dan Anda ingin mengonversinya ke tabel global sambil tetap dikelola CloudFormation kemudian setel kebijakan penghapusan keRetain, hapus tabel dari tumpukan, ubah tabel menjadi tabel global di konsol, lalu impor tabel global sebagai sumber daya baru ke tumpukan. Untuk informasi selengkapnya, lihat AWS GitHub repositori.

Anda dapat menggunakan CloudFormation (dan AWS CDK) untuk mengonfigurasi tabel global multi-akun (lintas akun). Untuk informasi selengkapnya, lihat Tabel global multi-akun DynamoDB.