Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Konsep inti tabel global
Bagian berikut menjelaskan konsep dan perilaku tabel global di Amazon DynamoDB
Konsep
Tabel global adalah fitur DynamoDB yang mereplikasi data tabel di seluruh Wilayah. AWS
Tabel replika (atau replika) adalah tabel DynamoDB yang berfungsi sebagai bagian dari tabel global. Tabel global terdiri dari dua atau lebih tabel replika di berbagai AWS Wilayah. Setiap tabel global hanya dapat memiliki satu replika per AWS Wilayah. Semua replika dalam tabel global berbagi nama tabel, skema kunci primer, dan data item yang sama.
Saat aplikasi menulis data ke replika di satu Wilayah, DynamoDB secara otomatis mereplikasi penulisan ke semua replika lain dalam tabel global. Untuk informasi selengkapnya tentang cara memulai dengan tabel global, lihat Tutorial: Membuat tabel global atauTutorial: Membuat tabel global multi-akun.
Versi
Ada dua versi tabel global DynamoDB yang tersedia: Tabel Global versi 2019.11.21 (Saat Ini) dan. Versi tabel global 2017.11.29 (Legacy) Anda harus menggunakan Tabel Global versi 2019.11.21 (Saat ini) bila memungkinkan. Informasi di bagian dokumentasi ini adalah untuk Versi 2019.11.21 (Saat ini). Untuk informasi selengkapnya, lihat Menentukan versi tabel globalMenentukan versi tabel global.
Ketersediaan
Tabel global membantu meningkatkan kelangsungan bisnis Anda dengan membuatnya lebih mudah untuk menerapkan arsitektur ketersediaan tinggi Multi-wilayah. Jika beban kerja di satu AWS Wilayah menjadi terganggu, Anda dapat mengalihkan lalu lintas aplikasi ke Wilayah yang berbeda dan melakukan pembacaan dan penulisan ke tabel replika yang berbeda dalam tabel global yang sama.
Setiap tabel replika dalam tabel global memberikan daya tahan dan ketersediaan yang sama dengan tabel DynamoDB wilayah Tunggal. Tabel global menawarkan 99,999% ketersediaan Service Level Agreement (SLA)
Pengujian injeksi kesalahan
Baik tabel global MREC dan MRSC terintegrasi dengan AWSAWS Fault Injection Service (FIS), layanan yang dikelola sepenuhnya untuk menjalankan eksperimen injeksi kesalahan terkontrol untuk meningkatkan ketahanan aplikasi. Menggunakan AWS FIS, Anda dapat:
-
Buat templat eksperimen yang menentukan skenario kegagalan tertentu.
-
Menyuntikkan kegagalan untuk memvalidasi ketahanan aplikasi dengan mensimulasikan isolasi Wilayah (yaitu, menjeda replikasi ke dan dari replika yang dipilih) untuk menguji penanganan kesalahan, mekanisme pemulihan, dan perilaku pergeseran lalu lintas multi-wilayah ketika satu Wilayah mengalami gangguan. AWS
Misalnya, dalam tabel global dengan replika di AS Timur (Virginia N.), AS Timur (Ohio), dan AS Barat (Oregon), Anda dapat menjalankan eksperimen di AS Timur (Ohio) untuk menguji isolasi wilayah di sana sementara AS Timur (Virginia N.) dan AS Barat (Oregon) melanjutkan operasi normal. Pengujian terkontrol ini membantu Anda mengidentifikasi dan menyelesaikan masalah potensial sebelum memengaruhi beban kerja produksi.
Lihat Target tindakan dalam panduan pengguna AWS FIS untuk daftar lengkap tindakan yang didukung AWS FIS dan Konektivitas Lintas Wilayah untuk menjeda replikasi DynamoDB antar wilayah.
Untuk informasi tentang tindakan tabel global Amazon DynamoDB yang tersedia AWS di FIS, lihat referensi tindakan tabel global DynamoDB di Panduan Pengguna FIS.AWS
Untuk mulai menjalankan eksperimen injeksi kesalahan, lihat Merencanakan eksperimen AWS FIS Anda di panduan pengguna AWS FIS.
catatan
Selama AWS FIS percobaan di MRSC, pembacaan yang konsisten pada akhirnya diizinkan, tetapi pembaruan pengaturan tabel - seperti mengubah mode penagihan atau mengonfigurasi throughput tabel - tidak diizinkan, mirip dengan MREC. Silakan periksa CloudWatch metrik FaultInjectionServiceInducedErrorsuntuk detail tambahan mengenai kode kesalahan.
Waktu Untuk Tayang (TTL)
Tabel global yang dikonfigurasi untuk dukungan MREC mengonfigurasi penghapusan Time To Live (TTL). Pengaturan TTL secara otomatis disinkronkan untuk semua replika dalam tabel global. Ketika TTL menghapus item dari replika di Wilayah, penghapusan direplikasi ke semua replika lain di tabel global. TTL tidak menggunakan kapasitas tulis, jadi Anda tidak dikenakan biaya untuk penghapusan TTL di Wilayah tempat penghapusan terjadi. Namun, Anda dikenakan biaya untuk penghapusan yang direplikasi di setiap wilayah lain dengan replika di tabel global.
Replikasi penghapusan TTL mengkonsumsi kapasitas tulis pada replika tempat penghapusan direplikasi. Replika yang dikonfigurasi untuk kapasitas yang disediakan dapat membatasi permintaan jika kombinasi throughput tulis dan throughput penghapusan TTL lebih tinggi daripada kapasitas tulis yang disediakan.
Tabel global yang dikonfigurasi untuk konsistensi kuat Multi-wilayah (MRSC) tidak mendukung konfigurasi penghapusan Time To Live (TTL).
Pengaliran
Tabel global yang dikonfigurasi untuk konsistensi akhir Multi-wilayah (MREC) mereplikasi perubahan dengan membaca perubahan tersebut dari DynamoDB Stream pada tabel replika dan menerapkan perubahan itu ke semua tabel replika lainnya. Oleh karena itu, aliran 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 penulisan yang direplikasi, sehingga setiap Stream replika berisi catatan yang sedikit berbeda. Streaming rekaman pada replika MREC mempertahankan urutan untuk semua perubahan pada item yang sama, tetapi urutan relatif perubahan pada item yang berbeda dapat bervariasi di seluruh replika.
Jika Anda ingin menulis aplikasi yang memproses catatan Streams untuk perubahan yang terjadi di Wilayah tertentu tetapi tidak Wilayah lain dalam tabel global, Anda dapat menambahkan atribut ke setiap item yang menentukan di Wilayah mana perubahan untuk item tersebut terjadi. Anda dapat menggunakan atribut ini untuk memfilter catatan Streams untuk perubahan yang terjadi di Wilayah lain, termasuk penggunaan filter peristiwa Lambda untuk hanya memanggil fungsi Lambda untuk perubahan di Wilayah tertentu.
Tabel global yang dikonfigurasi untuk Multi-region strong consistency (MRSC) tidak menggunakan DynamoDB Streams untuk replikasi, sehingga Streams tidak diaktifkan secara default pada replika MRSC. Anda dapat mengaktifkan Streams pada replika MRSC. Catatan aliran pada replika MRSC identik untuk setiap replika, termasuk urutan rekaman Stream.
Transaksi
Pada tabel global yang dikonfigurasi untuk MREC, operasi transaksi DynamoDB (TransactWriteItemsdan TransactGetItems) hanya atom dalam Wilayah tempat operasi dipanggil. Penulisan transaksional tidak direplikasi sebagai unit di seluruh Wilayah, yang berarti hanya beberapa penulisan dalam transaksi yang dapat dikembalikan oleh operasi baca di replika lain pada titik waktu tertentu.
Misalnya, jika Anda memiliki tabel global dengan replika di Wilayah AS Timur (Ohio) dan AS Barat (Oregon) dan melakukan TransactWriteItems operasi di Wilayah AS Timur (Ohio), Anda dapat mengamati transaksi yang diselesaikan sebagian di Wilayah Barat AS (Oregon) saat perubahan direplikasi. Perubahan hanya akan direplikasi ke Wilayah lain setelah dilakukan di Wilayah sumber.
Tabel global yang dikonfigurasi untuk konsistensi kuat Multi-wilayah (MRSC) tidak mendukung operasi transaksi, dan akan mengembalikan kesalahan jika operasi tersebut dipanggil pada replika MRSC.
Throughput baca dan tulis
Mode yang disediakan
Replikasi mengkonsumsi kapasitas tulis. Replika yang dikonfigurasi untuk kapasitas yang disediakan dapat membatasi permintaan jika kombinasi throughput penulisan aplikasi dan throughput penulisan replikasi melebihi kapasitas penulisan yang disediakan. Untuk tabel global yang menggunakan mode yang disediakan, pengaturan penskalaan otomatis untuk kapasitas baca dan tulis disinkronkan antar replika.
Anda dapat secara independen mengonfigurasi pengaturan kapasitas baca untuk setiap replika dalam tabel global dengan menggunakan ProvisionedThroughputOverrideparameter di tingkat replika. Secara default, perubahan kapasitas baca yang disediakan diterapkan ke semua replika dalam tabel global. Saat menambahkan replika baru ke tabel global, kapasitas baca tabel sumber atau replika digunakan sebagai nilai awal kecuali penggantian tingkat replika ditentukan secara eksplisit.
Mode sesuai permintaan
Untuk tabel global yang dikonfigurasi untuk mode sesuai permintaan, kapasitas tulis secara otomatis disinkronkan di semua replika. DynamoDB secara otomatis menyesuaikan kapasitas berdasarkan lalu lintas, dan tidak ada pengaturan kapasitas baca atau tulis khusus replika untuk dikelola.
Memantau tabel global
Tabel global yang dikonfigurasi untuk konsistensi akhir Multi-wilayah (MREC) mempublikasikan metrik ke. ReplicationLatency CloudWatch Metrik ini melacak waktu yang telah berlalu antara saat item ditulis ke tabel replika, dan kapan item itu muncul di replika lain di tabel global. ReplicationLatencydinyatakan dalam milidetik dan dipancarkan untuk setiap pasangan Wilayah sumber dan tujuan dalam tabel global.
ReplicationLatencyNilai tipikal tergantung pada jarak antara AWS Wilayah yang Anda pilih, serta variabel lain seperti jenis beban kerja dan throughput. Misalnya, replika sumber di Wilayah AS Barat (California Utara) (us-west-1) memiliki lebih rendah ReplicationLatency ke Wilayah Barat AS (Oregon) (us-west-2) dibandingkan dengan Wilayah Afrika (Cape Town) (af-south-1).
Nilai yang meningkat untuk ReplicationLatency dapat menunjukkan bahwa pembaruan dari satu replika tidak menyebar ke tabel replika lain secara tepat waktu. Dalam hal ini, Anda dapat mengalihkan sementara aktivitas baca dan tulis aplikasi Anda ke AWS Wilayah yang berbeda.
Tabel global yang dikonfigurasi untuk konsistensi kuat Multi-wilayah (MRSC) tidak mempublikasikan metrik. ReplicationLatency
Pertimbangan untuk mengelola tabel global
Anda tidak dapat menghapus tabel yang digunakan untuk menambahkan replika tabel global baru hingga 24 jam berlalu sejak replika baru dibuat.
Jika Anda menonaktifkan AWS Wilayah yang berisi replika tabel global, replika tersebut akan dikonversi secara permanen ke tabel Wilayah tunggal 20 jam setelah Wilayah dinonaktifkan.