Daftar periksa persiapan untuk tabel global dan Pertanyaan yang Sering Diajukan

Gunakan daftar periksa berikut untuk keputusan dan tugas saat Anda men-deploy tabel global.

• Tentukan jumlah dan Wilayah yang akan berpartisipasi dalam tabel global.

• Tentukan mode tulis aplikasi Anda. Untuk informasi selengkapnya, lihat Mode tulis dengan tabel global.

• Rencanakan strategi Meminta perutean dengan tabel global, berdasarkan mode tulis Anda.

• Tentukan rencana evakuasi Anda, berdasarkan 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 untuk 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.

• Atur alarm untuk peningkatan ReplicationLatency yang 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 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.

  catatan

  Praktik terbaiknya adalah hanya mengandalkan operasi bidang data, bukan operasi bidang kontrol karena beberapa operasi bidang kontrol mungkin terdegradasi selama kegagalan wilayah.

  Untuk informasi lebih lanjut, lihat AWS posting blog 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 untuk menggunakan Resilience Hub 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 ARC kesiapan untuk mengevaluasi konfigurasi aplikasi Anda saat ini dan melacak penyimpangan dari praktik terbaik.

• Saat menulis pemeriksaan kondisi untuk digunakan dengan Route 53 atau Global Accelerator, tidak cukup hanya dengan melakukan ping untuk mengetahui bahwa titik akhir DynamoDB sudah aktif. Itu tidak mencakup banyak mode kegagalan seperti kesalahan IAM konfigurasi, masalah penerapan kode, kegagalan dalam tumpukan di luar DynamoDB, latensi baca atau tulis yang lebih tinggi dari rata-rata, dan sebagainya. Praktik terbaiknya adalah melakukan serangkaian panggilan yang menggunakan aliran basis data penuh.

Pertanyaan yang Sering Diajukan (FAQ) untuk menyebarkan tabel global

Apa saja prinsip yang berguna untuk penggunaan keseluruhan tabel global DynamoDB?

Tabel global DynamoDB memiliki sedikit tombol kontrol, tetapi masih memerlukan sejumlah pertimbangan. Anda harus menentukan mode tulis, model perutean, dan proses evakuasi. Anda harus melengkapi aplikasi Anda di setiap Wilayah dan siap menyesuaikan rute atau melakukan evakuasi untuk menjaga kesehatan global. Sehingga Anda akan mendapatkan kumpulan data yang terdistribusi secara global dengan pembacaan dan penulisan latensi rendah serta perjanjian tingkat layanan 99,999%.

Berapa harga untuk tabel global?

Tulis ke tabel DynamoDB tradisional diberi harga dalam Unit Kapasitas Tulis WCUs (, untuk tabel yang disediakan) atau Unit Permintaan Tulis (, untuk tabel sesuai permintaan). WRUs Jika menulis item 5 KB, Anda dikenakan biaya 5 unit. Tulis ke tabel global diberi harga dalam Unit Kapasitas Tulis Replikasi (rWCUs, untuk tabel yang disediakan) atau Unit Permintaan Tulis Replikasi (rWRUs, untuk tabel sesuai permintaan).

Itu rWCUs dan rWRUs termasuk biaya infrastruktur streaming yang diperlukan untuk mengelola replikasi. Dengan demikian, mereka dihargai 50% lebih tinggi dari WCUs danWRUs. Biaya transfer data lintas Wilayah berlaku.

Biaya Unit Tulis yang Direplikasi dikenakan di setiap Wilayah tempat item tersebut ditulis langsung atau ditulis dengan replikasi.

Menulis ke Global Secondary Index (GSI) dianggap sebagai penulisan lokal dan menggunakan Unit Tulis biasa.

Tidak ada Kapasitas Cadangan yang tersedia untuk rWCUs saat ini. Membeli Kapasitas Cadangan mungkin masih bermanfaat untuk tabel dengan unit tulis yang GSIs dikonsumsi.

Bootstrap awal saat menambahkan Wilayah baru ke tabel global dikenakan biaya seperti pemulihan per GB data yang dipulihkan, ditambah biaya transfer data lintas Wilayah.

Wilayah mana yang didukung tabel global?

Versi Tabel Global 2019.11.21 (Saat Ini) tersedia di sebagian besar Wilayah. Anda dapat melihat daftar terbaru di daftar dropdown Wilayah di konsol DynamoDB saat menambahkan replika.

Bagaimana GSIs ditangani dengan tabel global?

Di Tabel Global versi 2019.11.21 (Saat Ini), saat Anda membuat GSI di satu Wilayah, itu secara otomatis dibuat di Wilayah lain yang berpartisipasi dan diisi ulang secara otomatis.

Bagaimana cara menghentikan replikasi tabel global?

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, dan Anda juga tidak dapat menjeda replikasi.

Bagaimana DynamoDB Streams berinteraksi dengan tabel global?

Setiap tabel global menghasilkan aliran independen berdasarkan semua penulisannya, dari mana pun tabel tersebut dimulai. 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 akan membantu dalam operasi penyisipan dan pembaruan, tetapi sayangnya tidak membantu operasi penghapusan.

Bagaimana tabel global menangani transaksi?

Operasi transaksional 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 dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) serta melakukan operasi TransactWriteItems di Wilayah AS Timur (Ohio), Anda mungkin melihat transaksi yang selesai sebagian di Wilayah AS Barat (Oregon) seiring perubahan direplikasi. Perubahan direplikasi ke Wilayah lain hanya setelah diterapkan di Wilayah sumber.

Bagaimana tabel global berinteraksi dengan cache DynamoDB Accelerator ()? DAX

Tabel global mem-bypass DAX dengan memperbarui DynamoDB secara langsung, DAX jadi tidak menyadari bahwa itu menyimpan data basi. DAXCache disegarkan hanya ketika cache TTL kedaluwarsa.

Apakah tanda pada tabel disebarkan?

Tidak, tanda tidak disebarkan secara otomatis.

Apakah saya harus mencadangkan tabel di semua Wilayah atau cukup satu Wilayah?

Jawabannya tergantung pada tujuan pencadangan. 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 () di satu Wilayah. PITR

Bagaimana cara menerapkan tabel global menggunakan AWS CloudFormation?

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 menggunakan konsep GlobalTable. Anda kemudian dapat menyimpannya sebagai tabel mandiri pada awalnya, dan menambahkan Wilayah nanti jika diperlukan.

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. Anda tidak boleh menggunakan GlobalTable sumber daya AWS: :DynamoDB:: 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 CloudFormation kemudian mengatur kebijakan penghapusan ke Retain, hapus tabel dari tumpukan, ubah tabel menjadi tabel global di konsol, lalu impor tabel global sebagai sumber daya baru ke tumpukan.

Replikasi lintas akun tidak didukung saat ini.