Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Menggunakan tabel global DynamoDB
Tabel global dibangun di atas jejak global Amazon DynamoDB untuk memberi Anda database multi-wilayah, Multi-wilayah, dan multi-aktif yang dapat memberikan kinerja cepat dan lokal, baca dan tulis untuk aplikasi global yang diskalakan secara besar-besaran. Tabel global mereplikasi tabel DynamoDB Anda secara otomatis di seluruh pilihan Anda. Wilayah AWS Tidak ada perubahan aplikasi yang diperlukan karena tabel global menggunakan DynamoDB APIs yang ada. Tidak ada biaya atau komitmen di muka untuk menggunakan tabel global, dan Anda hanya membayar untuk sumber daya yang Anda gunakan.
Panduan ini menjelaskan cara menggunakan tabel global DynamoDB secara efektif. Ini memberikan fakta kunci tentang tabel global, menjelaskan kasus penggunaan utama fitur, menjelaskan dua mode konsistensi, memperkenalkan taksonomi dari tiga model penulisan berbeda yang harus Anda pertimbangkan, berjalan melalui empat pilihan perutean permintaan utama yang mungkin Anda terapkan, membahas cara untuk mengevakuasi Wilayah yang hidup atau Wilayah yang offline, menjelaskan cara berpikir tentang perencanaan kapasitas throughput, dan memberikan daftar periksa hal-hal yang perlu dipertimbangkan ketika Anda menerapkan tabel global.
[Panduan ini cocok dengan konteks penyebaran AWS Multi-wilayah yang lebih besar, seperti yang tercakup dalam whitepaper [AWS Multi-Region Fundamentals](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html) dan pola desain ketahanan data dengan video. AWS](https://www.youtube.com/watch?v=7IA48SOX20c)
**Topics**
+ [Fakta kunci tentang desain tabel global DynamoDB](#bp-global-table-design.prescriptive-guidance.facts)
+ [Fakta Utama tentang MREC](#bp-global-table-design-MREC-facts)
+ [Fakta Utama tentang MRSC](#bp-global-table-design-MRSC-facts)
+ [Kasus penggunaan tabel global MREC DynamoDB](#bp-global-table-design.prescriptive-guidance.usecases)
+ [Tulis mode dengan tabel global DynamoDB](bp-global-table-design.prescriptive-guidance.writemodes.md)
+ [Strategi perutean di DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md)
+ [Proses evakuasi](bp-global-table-design.prescriptive-guidance.evacuation.md)
+ [Perencanaan kapasitas throughput untuk tabel global DynamoDB](bp-global-table-design.prescriptive-guidance.throughput.md)
+ [Daftar periksa persiapan untuk tabel global DynamoDB](bp-global-table-design.prescriptive-guidance.checklist-and-faq.md)
+ [Kesimpulan dan sumber daya](#bp-global-table-design.prescriptive-guidance-resources-conclusion)
## Fakta kunci tentang desain tabel global DynamoDB
+ Ada dua versi tabel global: versi saat ini [Tabel Global versi 2019.11.21 (Saat ini) (](GlobalTables.md)kadang-kadang disebut “V2"), dan [Versi tabel global 2017.11.29 (Legacy)](globaltables.V1.md) (kadang-kadang disebut “V1"). Panduan ini berfokus secara eksklusif pada versi saat ini.
+ DynamoDB (tanpa tabel global) adalah layanan Regional, yang berarti sangat tersedia dan secara intrinsik tahan terhadap kegagalan infrastruktur, termasuk kegagalan seluruh Availability Zone. Tabel DynamoDB wilayah tunggal dirancang untuk ketersediaan 99,99%. Untuk informasi selengkapnya, lihat [DynamoDB service-level agreement](https://aws.amazon.com/dynamodb/sla/) (SLA).
+ Tabel global DynamoDB mereplikasi datanya antara dua atau lebih Wilayah. Tabel DynamoDB Multi-region dirancang untuk ketersediaan 99,999%. Dengan perencanaan yang tepat, tabel global dapat membantu menciptakan arsitektur yang tahan terhadap kegagalan Regional.
+ DynamoDB tidak memiliki titik akhir global. Semua permintaan dibuat ke titik akhir Regional yang mengakses instance tabel global yang lokal ke Wilayah tersebut.
+ Panggilan ke DynamoDB tidak boleh melintasi Wilayah. Praktik terbaik adalah untuk aplikasi yang homed ke satu Region untuk langsung mengakses hanya endpoint DynamoDB lokal untuk Wilayahnya. Jika masalah terdeteksi dalam Wilayah (di lapisan DynamoDB atau di tumpukan sekitarnya), lalu lintas pengguna akhir harus diarahkan ke titik akhir aplikasi lain yang di-host di Wilayah berbeda. Tabel global memastikan bahwa aplikasi yang ditempatkan di setiap Wilayah memiliki akses ke data yang sama.
### Mode konsistensi
Saat Anda membuat tabel global, Anda mengonfigurasi mode konsistensinya. Tabel global mendukung dua mode konsistensi: Multi-region ending consistency (MREC) dan Multi-region strong consistency (MRSC) yang diperkenalkan pada Juni 2025.
Jika Anda tidak menentukan mode konsistensi saat membuat tabel global, tabel global default ke MREC. Tabel global tidak dapat berisi replika yang dikonfigurasi dengan mode konsistensi yang berbeda. Anda tidak dapat mengubah mode konsistensi tabel global setelah pembuatannya.
## Fakta Utama tentang MREC
+ Tabel global yang menggunakan MRSC juga menggunakan model replikasi aktif-aktif. Dari perspektif DynamoDB, tabel di setiap Wilayah memiliki kedudukan yang sama untuk menerima permintaan baca dan tulis. Setelah menerima permintaan tulis, tabel replika lokal mereplikasi operasi penulisan ke Wilayah terpencil lain yang berpartisipasi di latar belakang.
+ Item direplikasi satu per satu. Item yang diperbarui dalam satu transaksi mungkin tidak direplikasi bersama.
+ Setiap partisi tabel di Wilayah sumber mereplikasi operasi penulisannya secara paralel dengan setiap partisi lainnya. Urutan operasi tulis dalam Wilayah terpencil mungkin tidak cocok dengan urutan operasi tulis yang terjadi di dalam Wilayah sumber. Untuk informasi selengkapnya tentang partisi tabel, lihat postingan blog [Penskalaan DynamoDB: Dampak partisi, hot key, dan pemisahan panas terhadap performa](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/).
+ Item yang baru ditulis biasanya disebarkan ke semua tabel replika dalam hitungan detik. Wilayah terdekat cenderung menyebarkan lebih cepat.
+ Amazon CloudWatch menyediakan `ReplicationLatency` metrik untuk setiap pasangan Wilayah. Ini dihitung dengan melihat item yang tiba, membandingkan waktu kedatangan mereka dengan waktu tulis awal mereka, dan menghitung rata-rata. Pengaturan waktu disimpan CloudWatch di dalam Wilayah sumber. Melihat pengaturan waktu rata-rata dan maksimum dapat berguna untuk menentukan kelambatan replikasi rata-rata dan terburuk. Tidak ada SLA pada latensi ini.
+ Jika item individual diperbarui pada waktu yang hampir bersamaan (dalam `ReplicationLatency` jendela ini) di dua Wilayah yang berbeda, dan operasi penulisan kedua terjadi sebelum operasi penulisan pertama direplikasi, ada potensi konflik penulisan. Tabel global yang menggunakan MREC menyelesaikan konflik tersebut dengan menggunakan mekanisme kemenangan penulis terakhir, berdasarkan stempel waktu operasi penulisan. Operasi pertama “kalah” dengan operasi kedua. Konflik ini tidak dicatat dalam CloudWatch atau AWS CloudTrail.
+ Setiap item memiliki timestamp tulis terakhir yang disimpan sebagai properti sistem privat. Pendekatan pemenang penulis terakhir diimplementasikan dengan menggunakan operasi penulisan bersyarat yang mengharuskan stempel waktu item yang masuk lebih besar dari stempel waktu item yang ada.
+ Tabel global mereplikasi semua item ke semua Wilayah yang berpartisipasi. Jika Anda ingin memiliki cakupan replikasi yang berbeda, Anda dapat membuat beberapa tabel global dan menetapkan setiap tabel Wilayah berpartisipasi yang berbeda.
+ Wilayah lokal menerima operasi penulisan meskipun Region replika sedang offline atau `ReplicationLatency` tumbuh. Tabel lokal terus mencoba mereplikasi item ke tabel jarak jauh hingga setiap item berhasil.
+ Jika Wilayah tidak mungkin sepenuhnya offline, ketika kembali online nanti, semua replikasi keluar dan masuk yang tertunda akan dicoba lagi. Tidak ada tindakan khusus yang diperlukan untuk mengembalikan sinkronisasi tabel. Mekanisme *kemenangan penulis terakhir* memastikan bahwa data akhirnya menjadi konsisten.
+ Anda dapat menambahkan Region baru ke tabel DynamoDB MREC kapan saja. DynamoDB menangani sinkronisasi awal dan replikasi yang sedang berlangsung. Anda juga dapat menghapus Region (bahkan Region asli), dan ini akan menghapus tabel lokal di Region tersebut.
## Fakta Utama tentang MRSC
+ Tabel global yang menggunakan MRSC juga menggunakan model replikasi aktif-aktif. Dari perspektif DynamoDB, tabel di setiap Wilayah memiliki kedudukan yang sama untuk menerima permintaan baca dan tulis. Perubahan item dalam replika tabel global MRSC direplikasi **secara sinkron** ke setidaknya satu Wilayah lain sebelum operasi penulisan mengembalikan respons yang berhasil.
+ Operasi baca yang sangat konsisten pada replika MRSC apa pun selalu mengembalikan versi terbaru dari suatu item. Operasi penulisan bersyarat selalu mengevaluasi ekspresi kondisi terhadap versi terbaru dari suatu item. Pembaruan selalu beroperasi terhadap versi terbaru dari suatu item.
+ Akhirnya operasi pembacaan yang konsisten pada replika MRSC mungkin tidak menyertakan perubahan yang baru-baru ini terjadi di Wilayah lain, dan bahkan mungkin tidak menyertakan perubahan yang baru-baru ini terjadi di Wilayah yang sama.
+ Operasi tulis gagal dengan `ReplicatedWriteConflictException` pengecualian ketika mencoba memodifikasi item yang sudah dimodifikasi di Wilayah lain. Operasi tulis yang gagal dengan `ReplicatedWriteConflictException` pengecualian dapat dicoba ulang dan akan berhasil jika item tidak lagi dimodifikasi di Wilayah lain.
+ Dengan MRSC, latensi lebih tinggi untuk operasi tulis dan untuk operasi baca yang sangat konsisten. Operasi ini membutuhkan komunikasi lintas wilayah. Komunikasi ini dapat menambah latensi yang meningkat berdasarkan latensi pulang-pergi antara Wilayah yang diakses dan Wilayah terdekat yang berpartisipasi dalam tabel global. Untuk informasi lebih lanjut, lihat presentasi AWS re:Invent 2024, [konsistensi kuat Multi-Region dengan](https://www.youtube.com/watch?v=R-nTs8ZD8mA) tabel global DynamoDB. Akhirnya operasi baca yang konsisten tidak mengalami latensi tambahan. Ada [alat penguji](https://github.com/awslabs/amazon-dynamodb-tools/tree/main/tester) open source yang memungkinkan Anda menghitung latensi ini secara eksperimental dengan Wilayah Anda.
+ Item direplikasi satu per satu. Tabel global menggunakan MRSC tidak mendukung transaksi APIs.
+ Tabel global MRSC harus ditempatkan tepat di tiga Wilayah. Anda dapat mengonfigurasi tabel global MRSC dengan tiga replika, atau dengan dua replika dan satu saksi. Saksi adalah komponen dari tabel global MRSC yang berisi data terbaru yang ditulis ke replika tabel global. Seorang saksi memberikan alternatif opsional untuk replika lengkap sambil mendukung arsitektur ketersediaan MRSC. Anda tidak dapat melakukan operasi baca atau tulis pada saksi. Seorang saksi tidak dikenakan biaya penyimpanan atau menulis. Seorang saksi berada di dalam Wilayah yang berbeda dari dua replika.
+ Untuk membuat tabel global MRSC, Anda menambahkan satu replika dan saksi, atau menambahkan dua replika ke tabel DynamoDB yang ada yang tidak berisi data. Anda tidak dapat menambahkan replika tambahan ke tabel global MRSC yang ada. Anda tidak dapat menghapus satu replika atau saksi dari tabel global MRSC. Anda dapat menghapus dua replika, atau menghapus satu replika dan saksi, dari tabel global MRSC. Skenario kedua mengonversi replika yang tersisa ke tabel DynamoDB wilayah tunggal.
+ Anda dapat menentukan apakah tabel global MRSC memiliki saksi yang dikonfigurasi, dan Wilayah mana yang dikonfigurasi, dari output DescribeTable API. Saksi dimiliki dan dikelola oleh DynamoDB dan tidak muncul di Wilayah Akun AWS Anda di mana itu dikonfigurasi.
+ Tabel global MRSC tersedia dalam set Wilayah berikut:
+ Set Wilayah AS: AS Timur (Virginia N.), AS Timur (Ohio), AS Barat (Oregon)
+ Set Wilayah UE: Eropa (Irlandia), Eropa (London), Eropa (Paris), Eropa (Frankfurt)
+ Set Wilayah AP: Asia Pasifik (Tokyo), Asia Pasifik (Seoul), dan Asia Pasifik (Osaka)
+ Tabel global MRSC tidak dapat menjangkau set Wilayah. Misalnya, tabel global MRSC tidak dapat berisi replika dari set Wilayah AS dan UE.
+ Time to Live (TTL) tidak didukung untuk tabel global MRSC.
+ Indeks sekunder lokal (LSIs) tidak didukung untuk tabel global MRSC.
+ CloudWatch Informasi Wawasan Kontributor hanya dilaporkan untuk Wilayah tempat operasi terjadi.
+ Wilayah lokal menerima semua operasi baca dan tulis selama ada Wilayah kedua yang menampung replika atau saksi untuk menetapkan kuorum. Jika Wilayah kedua tidak tersedia, Wilayah lokal hanya dapat melayani pembacaan yang konsisten pada akhirnya.
+ Dalam hal yang tidak mungkin bahwa suatu Wilayah sepenuhnya offline, ketika kembali online nanti, ia akan secara otomatis mengejar ketinggalan. Sampai tertangkap, operasi tulis dan operasi baca yang sangat konsisten *hanya* untuk Wilayah yang mengejar akan mengembalikan kesalahan sementara permintaan ke Wilayah lain akan terus berkinerja normal. Akhirnya operasi pembacaan yang konsisten ke Wilayah pengejaran akan mengembalikan data yang sejauh ini telah disebarkan ke Wilayah, dengan perilaku konsistensi lokal yang biasa antara node pemimpin dan replika lokal. Tidak ada tindakan khusus yang diperlukan untuk mengembalikan sinkronisasi tabel.
## Kasus penggunaan tabel global MREC DynamoDB
Tabel global MREC memberikan manfaat ini:
+ **Operasi baca latensi lebih rendah.** Tempatkan salinan data lebih dekat ke pengguna akhir untuk mengurangi latensi jaringan selama operasi baca. Data disimpan sesegar `ReplicationLatency` nilainya.
+ **Operasi penulisan latensi lebih rendah.** Anda dapat menulis ke wilayah terdekat untuk mengurangi latensi jaringan dan waktu yang dibutuhkan untuk menghasilkan penulisan. Lalu lintas tulis harus dirutekan dengan hati-hati untuk memastikan tidak ada konflik. Teknik perutean dibahas lebih detail di [Strategi perutean di DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md).
+ **Migrasi Wilayah yang mulus.** Anda dapat menambahkan Region baru dan menghapus Region lama untuk memigrasikan penyebaran dari satu Region ke wilayah lain tanpa downtime pada lapisan data.
Tabel global MREC dan MRSC keduanya memberikan manfaat ini:
+ **Peningkatan ketahanan dan pemulihan bencana.** Jika suatu Wilayah mengalami penurunan kinerja atau pemadaman penuh, Anda dapat mengevakuasinya. Untuk mengevakuasi berarti memindahkan beberapa atau semua permintaan ke Wilayah itu. Menggunakan tabel global meningkatkan [DynamoDB SLA untuk persentase](https://aws.amazon.com/dynamodb/sla/) uptime bulanan dari 99,99% menjadi 99,999%. Menggunakan MREC mendukung tujuan titik pemulihan (RPO) dan tujuan waktu pemulihan (RTO) yang diukur dalam hitungan detik. Menggunakan MRSC mendukung RPO nol.
Misalnya, Fidelity Investments disajikan di re:Invent 2022 tentang bagaimana mereka menggunakan tabel global DynamoDB untuk sistem manajemen pesanan mereka. Tujuan mereka adalah untuk mencapai pemrosesan latensi rendah yang andal pada skala yang tidak dapat mereka capai dengan pemrosesan lokal sambil juga mempertahankan ketahanan terhadap Zona Ketersediaan dan kegagalan Regional.
Jika tujuan Anda adalah ketahanan dan pemulihan bencana, tabel MRSC memiliki latensi tulis yang lebih tinggi dan latensi baca yang sangat konsisten, tetapi mendukung RPO nol. Tabel global MREC mendukung RPO yang sama dengan penundaan replikasi antara replika, biasanya beberapa detik tergantung pada Wilayah replika.
# Tulis mode dengan tabel global DynamoDB
Tabel global selalu aktif-aktif di tingkat tabel. Namun, terutama untuk tabel MREC, Anda mungkin ingin memperlakukannya sebagai aktif-pasif dengan mengontrol cara Anda merutekan permintaan penulisan. Misalnya, Anda mungkin memutuskan untuk merutekan permintaan penulisan ke satu Wilayah untuk menghindari potensi konflik penulisan yang dapat terjadi dengan tabel MREC.
Ada tiga pola penulisan terkelola utama, seperti yang dijelaskan dalam tiga bagian berikutnya. Anda harus mempertimbangkan pola penulisan yang sesuai dengan kasus penggunaan Anda. Pilihan ini memengaruhi cara Anda merutekan permintaan, mengevakuasi suatu Wilayah, dan menangani pemulihan bencana. Panduan di bagian selanjutnya tergantung pada mode tulis aplikasi Anda.
## Mode tulis ke Wilayah mana pun (tidak ada primer)
*Tulis ke mode Wilayah mana pun*, diilustrasikan dalam diagram berikut, sepenuhnya aktif-aktif dan tidak memberlakukan batasan di mana penulisan dapat terjadi. Wilayah mana pun dapat menerima penulisan kapan saja. Ini adalah mode paling sederhana, tetapi hanya dapat digunakan dengan beberapa jenis aplikasi. Mode ini cocok untuk semua tabel MRSC. Ini juga cocok untuk tabel MREC ketika semua penulis idempoten, dan karena itu dapat diulang dengan aman sehingga operasi penulisan bersamaan atau berulang di seluruh Wilayah tidak bertentangan. Misalnya, saat pengguna memperbarui data kontak mereka. Mode ini juga berfungsi dengan baik untuk kasus khusus idempoten, set data khusus tambahan yang semua penulisannya merupakan sisipan unik dengan kunci primer deterministik. Terakhir, mode ini cocok untuk MREC di mana risiko penulisan yang bertentangan akan dapat diterima.
![\[Diagram cara kerja klien menulis ke wilayah mana pun.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-client-read-write-to-any-region2.png)
Mode *tulis ke Wilayah mana pun* adalah arsitektur yang paling mudah untuk diimplementasikan. Perutean lebih mudah karena Wilayah mana pun dapat menjadi target penulisan kapan saja. Failover lebih mudah, karena dengan tabel MRSC, item selalu disinkronkan, dan dengan tabel MRSC, penulisan terbaru apa pun dapat diputar ulang beberapa kali ke Wilayah sekunder mana pun. Jika memungkinkan, Anda harus merancang mode tulis ini.
Misalnya, beberapa layanan streaming video menggunakan tabel global untuk melacak bookmark, ulasan, menonton bendera status, dan sebagainya. Penerapan ini menggunakan tabel MREC karena membutuhkan replika yang tersebar di seluruh dunia, dengan setiap replika menyediakan operasi baca dan tulis latensi rendah. Penerapan ini dapat menggunakan mode *tulis ke Wilayah mana pun* selama mereka memastikan bahwa setiap operasi penulisan adalah idempoten. Ini akan terjadi jika setiap pembaruan―misalnya, menyetel kode waktu terbaru baru, menetapkan ulasan baru, atau menyetel status jam tangan baru―menetapkan status baru pengguna secara langsung, dan nilai berikutnya yang benar untuk item tidak bergantung pada nilainya saat ini. Jika, secara kebetulan, permintaan tulis pengguna dialihkan ke Wilayah yang berbeda, operasi penulisan terakhir akan bertahan dan status global akan diselesaikan sesuai dengan tugas terakhir. Operasi baca dalam mode ini pada akhirnya akan menjadi konsisten, tertunda oleh `ReplicationLatency` nilai terbaru.
Contoh lain, sebuah perusahaan jasa keuangan menggunakan tabel global sebagai bagian dari sistem untuk menyimpan penghitungan pembelian kartu debit untuk setiap pelanggan, untuk menghitung hadiah cash-back pelanggan tersebut. Mereka ingin menyimpan `RunningBalance` barang per pelanggan. Mode tulis ini tidak secara alami idempoten karena saat transaksi mengalir, mereka memodifikasi saldo dengan menggunakan `ADD` ekspresi di mana nilai baru yang benar bergantung pada nilai saat ini. Dengan menggunakan tabel MRSC mereka masih dapat *menulis ke Wilayah mana pun*, karena setiap `ADD` panggilan selalu beroperasi terhadap nilai item terbaru.
Contoh ketiga melibatkan perusahaan yang menyediakan layanan penempatan iklan online. Perusahaan ini memutuskan bahwa risiko kehilangan data yang rendah akan dapat diterima untuk mencapai penyederhanaan desain *penulisan ke mode Wilayah mana pun*. Ketika mereka menayangkan iklan, mereka hanya memiliki beberapa milidetik untuk mengambil metadata yang cukup untuk menentukan iklan mana yang akan ditampilkan, dan kemudian merekam tayangan iklan sehingga mereka tidak segera mengulangi iklan yang sama. Mereka menggunakan tabel global untuk mendapatkan operasi baca latensi rendah untuk pengguna akhir di seluruh dunia dan operasi penulisan latensi rendah. Mereka merekam semua tayangan iklan untuk pengguna dalam satu item, yang direpresentasikan sebagai daftar yang terus bertambah. Mereka menggunakan satu item alih-alih menambahkan ke koleksi item, sehingga mereka dapat menghapus tayangan iklan yang lebih lama sebagai bagian dari setiap operasi penulisan tanpa membayar operasi penghapusan. Operasi penulisan ini tidak idempoten; jika pengguna akhir yang sama melihat iklan yang ditayangkan dari beberapa Wilayah pada waktu yang hampir bersamaan, ada kemungkinan satu operasi penulisan untuk tayangan iklan dapat menimpa yang lain. Risikonya adalah pengguna mungkin melihat iklan diulang sesekali. Mereka memutuskan bahwa ini dapat diterima.
## Menulis ke satu Wilayah (primer tunggal)
Mode *tulis ke satu Wilayah*, diilustrasikan dalam diagram berikut, adalah aktif-pasif dan merutekan semua tabel menulis ke satu wilayah aktif. Perhatikan bahwa DynamoDB tidak memiliki gagasan tentang satu wilayah aktif; perutean aplikasi di luar DynamoDB mengatur ini. Mode *tulis ke satu Wilayah* berfungsi dengan baik untuk tabel MREC yang perlu menghindari konflik tulis dengan memastikan bahwa operasi tulis hanya mengalir ke satu Wilayah pada satu waktu. Mode tulis ini membantu ketika Anda ingin menggunakan ekspresi bersyarat dan tidak dapat menggunakan MRSC karena alasan tertentu, atau ketika Anda perlu melakukan transaksi. Ekspresi ini tidak dimungkinkan kecuali Anda tahu bahwa Anda bertindak terhadap data terbaru, sehingga mereka memerlukan pengiriman semua permintaan tulis ke satu Wilayah yang memiliki data terbaru.
Bila Anda menggunakan tabel MRSC, Anda mungkin memilih untuk menulis secara umum ke satu Wilayah untuk kenyamanan. Misalnya, ini dapat membantu meminimalkan pembangunan infrastruktur Anda di luar DynamoDB. Mode tulis masih akan ditulis ke Wilayah mana pun karena dengan MRSC Anda dapat dengan aman menulis ke Wilayah mana pun kapan saja tanpa memperhatikan resolusi konflik yang akan menyebabkan tabel MREC memilih untuk *menulis ke* satu Wilayah.
Bacaan akhir konsisten dapat dilakukan di Wilayah replika mana pun untuk mendapatkan latensi yang lebih rendah. Pembacaan yang sangat konsisten harus masuk ke Wilayah primer tunggal.
![\[Diagram cara kerja penulisan ke satu Wilayah.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-client-writes-one-region2.png)
Terkadang perlu untuk mengubah Wilayah aktif sebagai respons terhadap kegagalan Regional. Beberapa pengguna mengubah Wilayah yang saat ini aktif pada jadwal reguler, seperti menerapkan follow-the-sun penerapan. Ini menempatkan Wilayah aktif di dekat geografi yang memiliki aktivitas paling banyak (biasanya di siang hari, demikian namanya), yang menghasilkan operasi baca dan tulis latensi terendah. Ini juga memiliki manfaat sampingan untuk memanggil kode perubahan Wilayah setiap hari dan memastikan bahwa itu diuji dengan baik sebelum pemulihan bencana.
Wilayah pasif dapat menyimpan serangkaian infrastruktur yang diturunkan di sekitar DynamoDB yang dibangun hanya jika menjadi Wilayah aktif. Panduan ini tidak mencakup lampu pilot dan desain siaga yang hangat. Untuk informasi lebih lanjut, lihat [Arsitektur Pemulihan Bencana (DR) di AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/).
Menggunakan mode *tulis ke satu Wilayah* berfungsi dengan baik saat Anda menggunakan tabel global untuk operasi baca terdistribusi global latensi rendah. Contohnya adalah perusahaan media sosial besar yang perlu memiliki data referensi yang sama yang tersedia di setiap Wilayah di seluruh dunia. Mereka tidak sering memperbarui data, tetapi ketika mereka melakukannya, mereka menulis hanya ke satu Wilayah untuk menghindari potensi konflik penulisan. Operasi baca selalu diizinkan dari Wilayah mana pun.
Sebagai contoh lain, perhatikan perusahaan jasa keuangan yang dibahas sebelumnya yang menerapkan perhitungan cash-back harian. Mereka menggunakan *menulis ke mode Wilayah mana pun* untuk menghitung saldo tetapi *menulis ke satu mode Wilayah* untuk melacak pembayaran. Pekerjaan ini memerlukan transaksi, yang tidak didukung dalam tabel MRSC, sehingga berfungsi lebih baik dengan tabel MREC terpisah dan *menulis ke satu* mode Wilayah.
## Menulis ke Wilayah Anda (primer campuran)
*Tulis ke mode tulis Wilayah Anda*, diilustrasikan dalam diagram berikut, bekerja dengan tabel MREC. Ini menetapkan subset data yang berbeda ke Wilayah rumah yang berbeda dan memungkinkan operasi penulisan ke item hanya melalui Wilayah asalnya. Mode ini aktif-pasif tetapi menetapkan Wilayah aktif berdasarkan item. Setiap Wilayah adalah yang utama untuk dataset yang tidak tumpang tindih, dan operasi penulisan harus dijaga untuk memastikan lokalitas yang tepat.
Mode ini mirip dengan *menulis ke satu Wilayah* kecuali memungkinkan operasi tulis latensi rendah, karena data yang terkait dengan setiap pengguna dapat ditempatkan di kedekatan jaringan yang lebih dekat dengan pengguna tersebut. Ini juga menyebarkan infrastruktur di sekitarnya secara lebih merata antar Daerah dan membutuhkan lebih sedikit pekerjaan untuk membangun infrastruktur selama skenario failover, karena semua Wilayah memiliki sebagian infrastruktur mereka yang sudah aktif.
![\[Diagram tentang cara kerja klien menulis ke setiap item dalam satu Wilayah.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/get-client-writes-each-item-single-region2.png)
Anda dapat menentukan wilayah rumah untuk item dalam beberapa cara:
+ **Intrinsik:** Beberapa aspek data, seperti atribut khusus atau nilai yang tertanam dalam kunci partisi, membuat Wilayah asalnya jelas. Teknik ini dijelaskan dalam posting blog [Gunakan pin Wilayah untuk mengatur Wilayah rumah untuk item dalam tabel global Amazon DynamoDB](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/).
+ **Negosiasi:** Wilayah asal dari setiap dataset dinegosiasikan dalam beberapa cara eksternal, seperti dengan layanan global terpisah yang memelihara tugas. Penetapan tersebut mungkin memiliki jangka waktu terbatas dan setelah itu harus dinegosiasikan ulang.
+ **Berorientasi pada tabel:** Alih-alih membuat tabel global yang mereplikasi tunggal, Anda membuat jumlah tabel global yang sama dengan mereplikasi Wilayah. Nama setiap tabel menunjukkan Wilayah asalnya. Dalam operasi standar, semua data ditulis ke Wilayah asal sementara Wilayah lain menyimpan salinan hanya-baca. Selama failover, Wilayah lain untuk sementara mengadopsi tugas tulis untuk tabel itu.
Misalnya, bayangkan Anda bekerja untuk perusahaan game. Anda memerlukan operasi baca dan tulis latensi rendah untuk semua gamer di seluruh dunia. Anda menugaskan setiap pemain ke Wilayah yang paling dekat dengan mereka. Wilayah itu mengambil semua operasi baca dan tulis mereka, memastikan read-after-write konsistensi yang kuat. Namun, ketika seorang gamer bepergian atau jika wilayah asal mereka mengalami pemadaman, salinan lengkap data mereka tersedia di Wilayah lain, dan pemain dapat ditugaskan ke Wilayah asal yang berbeda.
Sebagai contoh lain, bayangkan Anda bekerja di perusahaan konferensi video. Setiap metadata panggilan konferensi ditetapkan ke Wilayah tertentu. Penelepon dapat menggunakan Wilayah yang paling dekat dengan mereka untuk latensi terendah. Jika ada pemadaman Wilayah, menggunakan tabel global memungkinkan pemulihan cepat karena sistem dapat memindahkan pemrosesan panggilan ke Wilayah lain di mana salinan data yang direplikasi sudah ada.
**Untuk meringkas**
+ Menulis ke mode Wilayah apa pun cocok untuk tabel MRSC dan panggilan idempoten ke tabel MREC.
+ Tulis ke satu mode Wilayah cocok untuk panggilan non-idempoten ke tabel MREC.
+ Tulis ke mode Wilayah Anda cocok untuk panggilan non-idempoten ke tabel MREC, di mana penting untuk meminta klien menulis ke Wilayah yang dekat dengan mereka.
# Strategi perutean di DynamoDB
Mungkin bagian paling rumit dari deployment tabel global adalah mengelola perutean permintaan. Permintaan harus dikirim dari pengguna akhir ke Wilayah yang dipilih terlebih dahulu, lalu dirutekan dengan cara tertentu. Permintaan menemukan beberapa tumpukan layanan di Wilayah tersebut, termasuk lapisan komputasi yang mungkin terdiri dari penyeimbang beban yang didukung oleh AWS Lambda fungsi, wadah, atau node Amazon Elastic Compute Cloud (Amazon EC2), dan mungkin layanan lain termasuk database lain. Lapisan komputasi tersebut berkomunikasi dengan DynamoDB yang dilakukan menggunakan titik akhir lokal untuk Wilayah tersebut. Data dalam tabel global direplikasi ke semua Wilayah lain yang berpartisipasi, dan setiap Wilayah memiliki tumpukan layanan serupa di sekitar tabel DynamoDB-nya.
Tabel global menyediakan salinan lokal dari data yang sama untuk setiap tumpukan di berbagai Wilayah. Sebaiknya Anda merancang tumpukan tunggal dalam satu Wilayah dan mengantisipasi melakukan panggilan jarak jauh ke titik akhir DynamoDB Wilayah sekunder jika tabel DynamoDB lokal mengalami masalah. Ini bukan praktik terbaik. Jika ada masalah di satu Wilayah yang disebabkan oleh DynamoDB (atau, kemungkinan besar, disebabkan oleh sesuatu yang lain di tumpukan atau oleh layanan lain yang bergantung pada DynamoDB), yang terbaik adalah merutekan pengguna akhir ke Wilayah lain untuk diproses dan menggunakan lapisan komputasi Wilayah lain, yang akan berbicara dengan titik akhir DynamoDB lokalnya. Pendekatan ini merutekan rute di sekitar Wilayah yang bermasalah sepenuhnya. Untuk memastikan ketahanan, Anda memerlukan replikasi di beberapa Wilayah: replikasi lapisan komputasi serta lapisan data.
Ada banyak teknik alternatif untuk merutekan permintaan pengguna akhir ke suatu Wilayah untuk diproses. Pilihan optimal bergantung pada mode tulis dan pertimbangan failover Anda. Bagian ini membahas empat opsi: berbasis klien, lapisan komputasi, Route 53, dan Global Accelerator.
## Perutean permintaan berbasis klien
Dengan routing permintaan berbasis klien, yang diilustrasikan dalam diagram berikut, klien pengguna akhir (aplikasi, halaman web dengan JavaScript, atau klien lain) melacak titik akhir aplikasi yang valid (misalnya, titik akhir Amazon API Gateway daripada titik akhir DynamoDB literal) dan menggunakan logika tertanam sendiri untuk memilih Wilayah untuk berkomunikasi. Ini mungkin memilih berdasarkan seleksi acak, latensi terendah yang diamati, pengukuran bandwidth tertinggi yang diamati, atau pemeriksaan kesehatan yang dilakukan secara lokal.
![\[Diagram cara kerja penulisan ke target pilihan klien.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-routing-is-clients-choice2_v2.png)
Sebagai keuntungan, routing permintaan berbasis klien dapat beradaptasi dengan hal-hal seperti kondisi lalu lintas internet publik dunia nyata untuk beralih Wilayah jika melihat kinerja yang menurun. Klien harus mengetahui semua titik akhir potensial, tetapi peluncuran titik akhir Regional baru bukanlah hal yang sering terjadi.
Dengan *menulis ke mode Wilayah mana pun*, klien dapat secara sepihak memilih titik akhir yang disukai. Jika aksesnya ke satu Wilayah terganggu, klien dapat merutekan ke titik akhir lain.
Dengan mode *tulis ke satu Wilayah*, klien memerlukan mekanisme untuk merutekan penulisannya ke wilayah yang sedang aktif. Ini bisa menjadi dasar seperti menguji secara empiris wilayah mana yang saat ini menerima penulisan (mencatat penolakan penulisan dan kembali ke alternatif) atau serumit memanggil koordinator global untuk menanyakan status aplikasi saat ini (mungkin dibangun di atas Amazon Application Recovery Controller (ARC) (ARC) kontrol perutean yang menyediakan sistem berbasis kuorum 5 wilayah untuk mempertahankan status global untuk kebutuhan seperti ini). Klien dapat memutuskan apakah pembacaan dapat dikirim ke Wilayah mana pun untuk konsistensi akhir atau harus dirutekan ke wilayah aktif untuk konsistensi yang kuat. Untuk informasi selengkapnya, lihat [Cara kerja Route 53](https://docs.aws.amazon.com/r53recovery/latest/dg/introduction-how-it-works.html).
Dengan mode *tulis ke Wilayah Anda*, klien perlu menentukan wilayah asal kumpulan data yang digunakannya. Misalnya, jika klien berhubungan dengan akun pengguna dan setiap akun pengguna ditempatkan di suatu Wilayah, klien dapat meminta titik akhir yang sesuai dari sistem login global.
Misalnya, perusahaan jasa keuangan yang membantu pengguna mengelola keuangan bisnisnya melalui web dapat menggunakan tabel global dengan mode *tulis ke Wilayah Anda*. Setiap pengguna harus masuk ke layanan pusat. Layanan tersebut mengembalikan kredensial dan titik akhir untuk Wilayah tempat kredensial tersebut akan berfungsi. Kredensialnya valid untuk waktu yang singkat. Setelah itu, halaman web otomatis menegosiasikan aktivitas masuk baru, yang memberikan peluang untuk mengalihkan aktivitas pengguna ke Wilayah baru.
## Perutean permintaan lapisan komputasi
Dengan routing permintaan compute-layer, diilustrasikan dalam diagram berikut, kode yang berjalan di lapisan komputasi menentukan apakah akan memproses permintaan secara lokal atau meneruskannya ke salinan dirinya sendiri yang berjalan di Wilayah lain. Saat Anda menggunakan mode *tulis ke satu Wilayah*, lapisan komputasi mungkin mendeteksi bahwa itu bukan Region aktif dan mengizinkan operasi baca lokal sambil meneruskan semua operasi tulis ke Wilayah lain. Kode lapisan komputasi ini harus mengetahui topologi data dan aturan perutean, dan menegakkannya dengan andal, berdasarkan pengaturan terbaru yang menentukan Wilayah mana yang aktif untuk data mana. Tumpukan perangkat lunak luar di Wilayah tidak harus mengetahui bagaimana permintaan baca dan tulis dirutekan oleh layanan mikro. Dalam desain yang kuat, Wilayah penerima memvalidasi apakah Wilayah tersebut merupakan wilayah primer saat ini untuk operasi tulis. Jika tidak, maka akan muncul kesalahan yang menunjukkan bahwa status global perlu diperbaiki. Wilayah penerima mungkin juga melakukan buffering pada operasi tulis untuk sementara waktu jika Wilayah utama sedang dalam proses perubahan. Dalam semua kasus, tumpukan komputasi di suatu Wilayah hanya menulis ke titik akhir DynamoDB lokalnya, tetapi tumpukan komputasi tersebut mungkin berkomunikasi satu sama lain.
![\[Diagram perutean permintaan lapisan komputasi.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-compute-layer-routing2.png)
[Vanguard Group menggunakan sistem yang disebut Global Orchestration and Status Tool (GOaST) dan perpustakaan bernama Global Multi-Region library (GMRlib) untuk proses routing ini, seperti yang disajikan di re:Invent 2022.](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) Mereka menggunakan model primer follow-the-sun tunggal. GOaST mempertahankan keadaan global, mirip dengan kontrol routing ARC yang dibahas di bagian sebelumnya. Ini menggunakan tabel global untuk melacak Wilayah mana yang merupakan Wilayah utama dan kapan sakelar utama berikutnya dijadwalkan. Semua operasi baca dan tulis dilalui GMRlib, yang berkoordinasi dengan GOa ST. GMRlib memungkinkan operasi baca dilakukan secara lokal, pada latensi rendah. Untuk operasi tulis, GMRlib periksa apakah Wilayah lokal adalah Wilayah utama saat ini. Jika ya, operasi tulis selesai secara langsung. Jika tidak, GMRlib teruskan tugas menulis ke GMRlib Wilayah utama. Pustaka penerima tersebut mengonfirmasi bahwa ia juga menganggap dirinya sebagai Wilayah utama dan menimbulkan kesalahan jika bukan, yang menunjukkan penundaan penyebaran dengan keadaan global. Pendekatan ini memberikan manfaat validasi dengan tidak menulis langsung ke titik akhir DynamoDB jarak jauh.
## Perutean permintaan Route 53
Amazon Application Recovery Controller (ARC) adalah teknologi Domain Name Service (DNS). Dengan Route 53, klien meminta titik akhir dengan mencari nama domain DNS yang dikenal, dan Route 53 mengembalikan alamat IP yang sesuai dengan titik akhir regional yang dianggap paling tepat. Ini diilustrasikan dalam diagram berikut. Route 53 memiliki daftar panjang kebijakan perutean yang digunakan untuk menentukan Wilayah yang sesuai. Itu juga dapat melakukan routing failover untuk merutekan lalu lintas dari Wilayah yang gagal pemeriksaan kesehatan.
![\[Diagram perutean permintaan lapisan komputasi.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-rt-53-anycast2_v2.png)
Dengan mode *tulis ke Wilayah mana pun*, atau jika digabungkan dengan perutean permintaan lapisan komputasi di backend, Route 53 dapat diberi akses penuh untuk mengembalikan Wilayah berdasarkan aturan internal kompleks seperti Wilayah dalam kedekatan jaringan terdekat, atau kedekatan geografis terdekat, atau pilihan lainnya.
Dengan *menulis ke satu mode Wilayah*, Anda dapat mengonfigurasi Route 53 untuk mengembalikan Wilayah yang saat ini aktif (menggunakan Route 53 ARC). Jika klien ingin terhubung ke Region pasif (misalnya, untuk operasi baca), itu bisa mencari nama DNS yang berbeda.
**catatan**
Klien menyimpan alamat IP dalam respons dari Route 53 selama waktu yang ditunjukkan oleh pengaturan waktu untuk tayang (TTL) pada nama domain. TTL yang lebih panjang memperpanjang sasaran waktu pemulihan (RTO) bagi semua klien untuk mengenali titik akhir baru. Nilai 60 detik adalah tipikal untuk penggunaan failover. Tidak semua perangkat lunak dengan sempurna mematuhi kedaluwarsa DNS TTL, dan mungkin ada beberapa tingkat cache DNS, seperti pada sistem operasi, mesin virtual, dan aplikasi.
Dengan mode *tulis ke Wilayah Anda*, sebaiknya hindari Route 53 kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.
## Perutean permintaan Global Accelerator
Dengan [AWS Global Accelerator](https://aws.amazon.com/global-accelerator/), diilustrasikan dalam diagram berikut, klien mencari nama domain terkenal di Route 53. Namun, alih-alih mendapatkan kembali alamat IP yang sesuai dengan titik akhir Regional, klien menerima alamat IP statis anycast yang merutekan ke lokasi AWS tepi terdekat. Mulai dari lokasi edge tersebut, semua lalu lintas dirutekan di jaringan AWS privat dan ke beberapa titik akhir (seperti penyeimbang beban atau API Gateway) di Wilayah yang dipilih berdasarkan aturan perutean yang dikelola dalam Global Accelerator. Dibandingkan dengan perutean berdasarkan aturan Route 53, perutean permintaan Global Accelerator memiliki latensi yang lebih rendah karena mengurangi jumlah lalu lintas di internet publik. Selain itu, karena Global Accelerator tidak bergantung pada kedaluwarsa DNS TTL untuk mengubah aturan perutean, ia dapat menyesuaikan perutean lebih cepat.
![\[Diagram cara kerja penulisan klien dengan Global Accelerator.\]](http://docs.aws.amazon.com/id_id/amazondynamodb/latest/developerguide/images/gt-routing-gax-excerpt2_v2.png)
Dengan mode *tulis ke Wilayah mana pun*, atau jika dikombinasikan dengan perutean permintaan lapisan komputasi di back-end, Global Accelerator dapat bekerja dengan lancar. Klien terhubung ke lokasi edge terdekat dan tidak perlu khawatir dengan Wilayah mana yang menerima permintaan.
Dengan *tulis ke satu Wilayah*, aturan perutean Global Accelerator harus mengirimkan permintaan ke Wilayah yang sedang aktif. Anda dapat menggunakan pemeriksaan kondisi yang secara artifisial melaporkan kegagalan pada Wilayah yang tidak diperhitungkan sebagai Wilayah aktif oleh sistem global Anda. Seperti halnya DNS, nama domain DNS alternatif dapat digunakan untuk merutekan permintaan baca jika permintaan tersebut dapat berasal dari Wilayah mana pun.
Dengan mode *tulis ke Wilayah Anda*, sebaiknya hindari Global Accelerator kecuali Anda juga menggunakan perutean permintaan lapisan komputasi.
# Proses evakuasi
Evakuasi suatu Daerah adalah proses migrasi aktivitas, biasanya aktivitas membaca dan menulis atau aktivitas membaca, jauh dari Wilayah tersebut.
## Mengevakuasi Wilayah aktif
Anda mungkin memutuskan untuk mengevakuasi Wilayah hidup karena sejumlah alasan: sebagai bagian dari aktivitas bisnis biasa (misalnya, jika Anda menggunakan mode, tulis ke satu Wilayah) follow-the-sun, karena keputusan bisnis untuk mengubah Wilayah yang saat ini aktif, sebagai tanggapan atas kegagalan dalam tumpukan perangkat lunak di luar DynamoDB, atau karena Anda menghadapi masalah umum seperti latensi yang lebih tinggi dari biasanya di dalam Wilayah.
Dengan mode *tulis ke Wilayah mana pun*, mengevakuasi Wilayah aktif sangatlah mudah. Anda dapat merutekan lalu lintas ke Wilayah alternatif dengan menggunakan sistem perutean apa pun dan membiarkan operasi penulisan di Wilayah yang dievakuasi mereplikasi seperti biasa.
Tulis ke satu Wilayah dan tulis ke mode Wilayah Anda biasanya digunakan dengan tabel MREC. Oleh karena itu, Anda harus memastikan bahwa semua operasi penulisan ke Wilayah aktif telah direkam sepenuhnya, diproses streaming, dan disebarkan secara global sebelum memulai operasi penulisan di Wilayah aktif baru, untuk memastikan bahwa operasi penulisan di masa depan diproses terhadap versi terbaru data.
Katakanlah Wilayah A aktif dan Wilayah B pasif (baik untuk tabel lengkap atau untuk item yang ditempatkan di Wilayah A). Mekanisme umum untuk melakukan evakuasi adalah dengan menjeda operasi tulis ke A, menunggu cukup lama hingga operasi tersebut disebarkan sepenuhnya ke B, memperbarui tumpukan arsitektur untuk mengenali B sebagai aktif, lalu melanjutkan operasi tulis ke B. Tidak ada metrik yang menunjukkan kepastian mutlak bahwa Wilayah A telah sepenuhnya mereplikasi datanya ke Wilayah B. Jika Wilayah A sehat, menjeda operasi tulis ke Wilayah A dan menunggu 10 kali nilai maksimum terbaru metrik `ReplicationLatency` biasanya sudah cukup untuk menentukan bahwa replikasi tersebut selesai. Jika Wilayah A tidak sehat dan menunjukkan area lain mengalami peningkatan latensi, Anda dapat memilih kelipatan waktu tunggu yang lebih besar.
## Mengevakuasi Wilayah offline
Ada kasus khusus yang perlu dipertimbangkan: Bagaimana jika Wilayah A sepenuhnya offline tanpa pemberitahuan? Ini sangat tidak mungkin tetapi harus dipertimbangkan.
Mengevakuasi meja MRSC offline
Jika ini terjadi dengan tabel MRSC, tidak ada yang istimewa yang perlu Anda lakukan. Tabel MRSC mendukung tujuan titik pemulihan (RPO) nol. Semua operasi penulisan yang berhasil dibuat ke tabel MRSC di Wilayah offline akan tersedia di semua tabel Wilayah lainnya, jadi tidak ada potensi kesenjangan dalam data bahkan jika Wilayah sepenuhnya offline tanpa pemberitahuan. Bisnis dapat terus menggunakan replika yang terletak di Wilayah lain.
Mengevakuasi meja MREC offline
Jika ini terjadi dengan tabel MREC, setiap operasi penulisan di Wilayah A yang belum disebarkan akan diadakan dan disebarkan setelah Wilayah A kembali online. Operasi tulis tidak hilang, tetapi penyebarannya tertunda tanpa batas waktu.
Cara melanjutkan peristiwa ini merupakan keputusan aplikasi. Untuk kelangsungan bisnis, operasi tulis mungkin perlu diteruskan ke Wilayah B utama yang baru. Namun, jika item di Wilayah B menerima pembaruan sementara ada penyebaran operasi tulis yang tertunda untuk item tersebut dari Wilayah A, penyebaran tersebut akan disembunyikan di model *penulis terakhir menang*. Pembaruan apa pun di Wilayah B mungkin menyembunyikan permintaan tulis yang masuk.
Dengan mode *tulis ke Wilayah mana pun*, operasi baca dan tulis dapat dilanjutkan di Wilayah B, percaya bahwa item di Wilayah A akan menyebar ke Wilayah B pada akhirnya dan mengenali potensi item yang hilang hingga Wilayah A kembali online. Jika memungkinkan, seperti dengan operasi penulisan idempoten, Anda harus mempertimbangkan untuk memutar ulang lalu lintas tulis terbaru (misalnya, dengan menggunakan sumber peristiwa hulu) untuk mengisi celah operasi penulisan yang berpotensi hilang dan membiarkan penulis terakhir memenangkan resolusi konflik menekan propagasi akhirnya dari operasi penulisan yang masuk.
Dengan mode tulis lainnya, Anda harus mempertimbangkan sejauh mana pekerjaan dapat dilanjutkan dengan sedikit out-of-date pandangan dunia. Beberapa operasi tulis berdurasi pendek, seperti yang dilacak oleh `ReplicationLatency`, akan hilang hingga Wilayah A kembali online. Apakah bisnis bisa maju? Dalam beberapa kasus penggunaan, bisa, tetapi pada kasus lainnya mungkin tidak bisa, tanpa mekanisme mitigasi tambahan.
Misalnya, bayangkan Anda harus mempertahankan saldo kredit yang tersedia tanpa gangguan bahkan setelah pemadaman penuh suatu Wilayah. Anda dapat membagi saldo menjadi dua item yang berbeda, satu homed di Wilayah A dan satu di Wilayah B, dan mulai masing-masing dengan setengah saldo yang tersedia. Ini akan menggunakan mode *tulis ke Wilayah Anda*. Pembaruan transaksional yang diproses di setiap Wilayah akan dituliskan pada salinan lokal saldo. Jika Wilayah A sepenuhnya offline, pekerjaan masih dapat dilanjutkan dengan pemrosesan transaksi di Wilayah B, dan operasi tulis akan terbatas pada bagian saldo yang disimpan di Wilayah B. Memisahkan saldo seperti ini menimbulkan kerumitan ketika saldo hampir habis atau kredit harus diseimbangkan kembali, tetapi hal ini memberikan satu contoh pemulihan bisnis yang aman bahkan dengan operasi tulis tertunda yang tidak pasti.
Sebagai contoh lain, bayangkan Anda menangkap data formulir web. Anda dapat menggunakan [Optimistic Concurrency Control (OCC)](DynamoDBMapper.OptimisticLocking.md) (OCC) untuk menetapkan versi ke item data dan menyematkan versi terbaru ke formulir web sebagai bidang tersembunyi. Pada setiap pengiriman, operasi tulis berhasil hanya jika versi dalam basis data masih cocok dengan versi yang digunakan untuk membuat formulir. Jika versinya tidak cocok, formulir web bisa disegarkan (atau digabungkan secara hati-hati) berdasarkan versi saat ini dalam basis data, dan pengguna bisa melanjutkan lagi. Model OCC biasanya melindungi terhadap penimpaan klien lain dan pembuatan versi data yang baru, tetapi model ini juga dapat membantu selama failover ketika klien mungkin menemukan versi data yang lebih lama. Misalkan Anda menggunakan timestamp sebagai versinya. Formulir ini pertama kali dibangun terhadap Wilayah A pada pukul 12:00 tetapi (setelah failover) mencoba menulis ke Wilayah B dan pemberitahuan bahwa versi terbaru dalam database adalah 11:59. Dalam skenario ini, klien dapat menunggu versi 12.00 untuk disebarkan ke Wilayah B lalu menulis di atas versi tersebut, atau membangun pada 11.59 dan membuat versi 12.01 baru (yang, setelah ditulis, akan menyembunyikan versi yang masuk setelah Wilayah A pulih).
Sebagai contoh ketiga, perusahaan jasa keuangan menyimpan data tentang akun pelanggan dan transaksi keuangan mereka dalam database DynamoDB. Jika terjadi pemadaman Wilayah A yang lengkap, mereka ingin memastikan bahwa aktivitas menulis apa pun yang terkait dengan akun mereka sepenuhnya tersedia di Wilayah B, atau mereka ingin mengkarantina akun mereka sebagaimana diketahui sebagian sampai Wilayah A kembali online. Alih-alih menghentikan semua bisnis, mereka memutuskan untuk menghentikan bisnis untuk sementara waktu, hanya pada sebagian kecil akun yang mereka anggap memiliki transaksi yang tidak disebarkan. Untuk mencapai hal ini, mereka menggunakan Wilayah ketiga, yang akan kita sebut Wilayah C. Sebelum memproses operasi tulis apa pun di Wilayah A, mereka menempatkan ringkasan singkat operasi yang tertunda tersebut (misalnya, jumlah transaksi baru untuk sebuah akun) di Wilayah C. Ringkasan ini cukup bagi Wilayah B untuk menentukan apakah pandangannya benar-benar mutakhir. Tindakan ini mengunci akun secara efektif sejak penulisan di Wilayah C hingga Wilayah A menerima operasi tulis dan Wilayah B menerimanya. Data di Wilayah C tidak digunakan kecuali sebagai bagian dari proses failover, setelah itu Wilayah B dapat memeriksa datanya dengan Wilayah C untuk mengetahui apakah ada akun yang kedaluwarsa. Akun-akun tersebut akan ditandai sebagai karantina sampai pemulihan Wilayah A menyebarkan sebagian data ke Wilayah B. Jika Wilayah C gagal, Wilayah D baru dapat diputar untuk digunakan sebagai gantinya. Data di Wilayah C sangat sementara, dan setelah beberapa menit Wilayah D akan memiliki up-to-date catatan yang cukup tentang operasi penulisan dalam penerbangan untuk sepenuhnya berguna. Jika Wilayah B gagal, Wilayah A dapat terus menerima permintaan tulis yang bekerja sama dengan Wilayah C. Perusahaan ini bersedia menerima penulisan dengan latensi yang lebih tinggi (ke dua Wilayah: C dan kemudian A) dan beruntung memiliki model data yang status akunnya dapat dirangkum secara ringkas.
# Perencanaan kapasitas throughput untuk tabel global DynamoDB
Migrasi lalu lintas dari satu Wilayah ke Wilayah lain memerlukan pertimbangan cermat terhadap pengaturan tabel DynamoDB terkait kapasitas.
Berikut adalah beberapa pertimbangan untuk mengelola kapasitas menulis:
+ Tabel global harus berada dalam mode sesuai permintaan atau disediakan dengan penskalaan otomatis yang diaktifkan.
+ Jika disediakan dengan penskalaan otomatis, pengaturan tulis (pemanfaatan minimum, maksimum, dan target) direplikasi di seluruh Wilayah. Meskipun pengaturan penskalaan otomatis disinkronkan, kapasitas tulis yang disediakan sebenarnya dapat mengambang secara independen antar Wilayah.
+ Salah satu alasan Anda dapat melihat kapasitas penulisan yang disediakan berbeda adalah karena fitur TTL. Saat mengaktifkan TTL di DynamoDB, Anda dapat menentukan nama atribut yang nilainya menunjukkan waktu kedaluwarsa item, dalam format waktu Unix dalam hitungan detik. Setelah itu, DynamoDB dapat menghapus item tanpa menimbulkan biaya tulis. Dengan tabel global, Anda dapat mengonfigurasi TTL di Wilayah mana pun, dan pengaturannya otomatis direplikasi ke Wilayah lain yang terkait dengan tabel global. Ketika suatu item memenuhi syarat untuk penghapusan melalui aturan TTL, pekerjaan tersebut dapat dilakukan di Wilayah mana pun. Operasi penghapusan dilakukan tanpa menggunakan unit tulis pada tabel sumber, tetapi tabel replika akan mendapatkan penulisan yang direplikasi untuk operasi penghapusan tersebut dan akan dikenakan biaya unit tulis yang direplikasi. TTL tidak didukung dalam tabel MRSC.
+ Jika Anda menggunakan penskalaan otomatis, pastikan pengaturan kapasitas tulis maksimum yang disediakan cukup tinggi untuk menangani semua operasi tulis serta semua potensi operasi penghapusan TTL. Penskalaan otomatis menyesuaikan setiap Wilayah sesuai dengan konsumsi tulisnya. Tabel sesuai permintaan tidak memiliki pengaturan kapasitas tulis maksimum yang disediakan, tetapi *batas throughput tulis maksimum tingkat tabel* menentukan kapasitas tulis berkelanjutan maksimum yang diperbolehkan oleh tabel sesuai permintaan. Batas defaultnya adalah 40.000, tetapi dapat disesuaikan. Sebaiknya Anda mengaturnya cukup tinggi untuk menangani semua operasi tulis (termasuk operasi tulis TTL) yang mungkin diperlukan tabel sesuai permintaan. Nilai ini harus sama di seluruh Wilayah yang berpartisipasi saat Anda menyiapkan tabel global.
Berikut adalah beberapa pertimbangan untuk mengelola kapasitas baca:
+ Pengaturan manajemen kapasitas baca boleh berbeda di antara Wilayah karena diasumsikan bahwa Wilayah yang berbeda mungkin memiliki pola baca yang independen. Saat Anda pertama kali menambahkan replika global ke tabel, kapasitas Wilayah sumber disebarkan. Setelah pembuatan, Anda dapat menyesuaikan pengaturan kapasitas baca, yang tidak ditransfer ke sisi lain.
+ Saat Anda menggunakan penskalaan otomatis DynamoDB, pastikan pengaturan kapasitas baca maksimum yang disediakan cukup tinggi untuk menangani semua operasi baca di seluruh Wilayah. Selama operasi standar, kapasitas baca mungkin akan disebarkan di seluruh Wilayah, tetapi tabel selama failover harus mampu beradaptasi secara otomatis dengan peningkatan beban kerja baca. Tabel sesuai permintaan tidak memiliki pengaturan kapasitas baca maksimum yang disediakan, tetapi *batas throughput baca maksimum tingkat tabel* menentukan kapasitas baca berkelanjutan maksimum yang diperbolehkan oleh tabel sesuai permintaan. Batas defaultnya adalah 40.000, tetapi dapat disesuaikan. Sebaiknya Anda mengaturnya cukup tinggi untuk menangani semua operasi baca yang mungkin diperlukan tabel jika semua operasi baca dirutekan ke Wilayah tunggal ini.
+ Jika tabel di satu Wilayah biasanya tidak menerima lalu lintas baca tetapi mungkin harus menyerap sejumlah besar lalu lintas baca setelah kegagalan, Anda dapat memanaskan kapasitas untuk menerima tingkat lalu lintas baca yang lebih tinggi.
ARC memiliki [pemeriksaan kesiapan](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.rules-resources.html) yang dapat berguna untuk mengonfirmasi bahwa DynamoDB Regions memiliki pengaturan tabel dan kuota akun yang serupa, apakah Anda menggunakan Route 53 untuk merutekan permintaan atau tidak. Pemeriksaan kesiapan ini juga dapat membantu menyesuaikan kuota tingkat akun untuk memastikannya cocok.
# Daftar periksa persiapan untuk tabel global DynamoDB
Gunakan daftar periksa berikut untuk keputusan dan tugas saat Anda men-deploy tabel global.
+ 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](bp-global-table-design.prescriptive-guidance.writemodes.md).
+ Rencanakan strategi [Strategi perutean di DynamoDB](bp-global-table-design.prescriptive-guidance.request-routing.md), berdasarkan mode tulis Anda.
+ Tentukan [ Proses evakuasi Mengevakuasi Wilayah dengan tabel global Evakuasi suatu Daerah adalah proses migrasi aktivitas, biasanya aktivitas membaca dan menulis atau aktivitas membaca, jauh dari Wilayah tersebut. Mengevakuasi Wilayah aktifWilayah aktif Mengevakuasi Wilayah aktif Anda mungkin memutuskan untuk mengevakuasi Wilayah hidup karena sejumlah alasan: sebagai bagian dari aktivitas bisnis biasa (misalnya, jika Anda menggunakan mode, tulis ke satu Wilayah) follow-the-sun, karena keputusan bisnis untuk mengubah Wilayah yang saat ini aktif, sebagai tanggapan atas kegagalan dalam tumpukan perangkat lunak di luar DynamoDB, atau karena Anda menghadapi masalah umum seperti latensi yang lebih tinggi dari biasanya di dalam Wilayah. Dengan mode *tulis ke Wilayah mana pun*, mengevakuasi Wilayah aktif sangatlah mudah. Anda dapat merutekan lalu lintas ke Wilayah alternatif dengan menggunakan sistem perutean apa pun dan membiarkan operasi penulisan di Wilayah yang dievakuasi mereplikasi seperti biasa. Tulis ke satu Wilayah dan tulis ke mode Wilayah Anda biasanya digunakan dengan tabel MREC. Oleh karena itu, Anda harus memastikan bahwa semua operasi penulisan ke Wilayah aktif telah direkam sepenuhnya, diproses streaming, dan disebarkan secara global sebelum memulai operasi penulisan di Wilayah aktif baru, untuk memastikan bahwa operasi penulisan di masa depan diproses terhadap versi terbaru data. Katakanlah Wilayah A aktif dan Wilayah B pasif (baik untuk tabel lengkap atau untuk item yang ditempatkan di Wilayah A). Mekanisme umum untuk melakukan evakuasi adalah dengan menjeda operasi tulis ke A, menunggu cukup lama hingga operasi tersebut disebarkan sepenuhnya ke B, memperbarui tumpukan arsitektur untuk mengenali B sebagai aktif, lalu melanjutkan operasi tulis ke B. Tidak ada metrik yang menunjukkan kepastian mutlak bahwa Wilayah A telah sepenuhnya mereplikasi datanya ke Wilayah B. Jika Wilayah A sehat, menjeda operasi tulis ke Wilayah A dan menunggu 10 kali nilai maksimum terbaru metrik `ReplicationLatency` biasanya sudah cukup untuk menentukan bahwa replikasi tersebut selesai. Jika Wilayah A tidak sehat dan menunjukkan area lain mengalami peningkatan latensi, Anda dapat memilih kelipatan waktu tunggu yang lebih besar. Mengevakuasi Wilayah offlineWilayah offline Mengevakuasi Wilayah offline Ada kasus khusus yang perlu dipertimbangkan: Bagaimana jika Wilayah A sepenuhnya offline tanpa pemberitahuan? Ini sangat tidak mungkin tetapi harus dipertimbangkan.
Mengevakuasi meja MRSC offline
Jika ini terjadi dengan tabel MRSC, tidak ada yang istimewa yang perlu Anda lakukan. Tabel MRSC mendukung tujuan titik pemulihan (RPO) nol. Semua operasi penulisan yang berhasil dibuat ke tabel MRSC di Wilayah offline akan tersedia di semua tabel Wilayah lainnya, jadi tidak ada potensi kesenjangan dalam data bahkan jika Wilayah sepenuhnya offline tanpa pemberitahuan. Bisnis dapat terus menggunakan replika yang terletak di Wilayah lain.
Mengevakuasi meja MREC offline
Jika ini terjadi dengan tabel MREC, setiap operasi penulisan di Wilayah A yang belum disebarkan akan diadakan dan disebarkan setelah Wilayah A kembali online. Operasi tulis tidak hilang, tetapi penyebarannya tertunda tanpa batas waktu.
Cara melanjutkan peristiwa ini merupakan keputusan aplikasi. Untuk kelangsungan bisnis, operasi tulis mungkin perlu diteruskan ke Wilayah B utama yang baru. Namun, jika item di Wilayah B menerima pembaruan sementara ada penyebaran operasi tulis yang tertunda untuk item tersebut dari Wilayah A, penyebaran tersebut akan disembunyikan di model *penulis terakhir menang*. Pembaruan apa pun di Wilayah B mungkin menyembunyikan permintaan tulis yang masuk.
Dengan mode *tulis ke Wilayah mana pun*, operasi baca dan tulis dapat dilanjutkan di Wilayah B, percaya bahwa item di Wilayah A akan menyebar ke Wilayah B pada akhirnya dan mengenali potensi item yang hilang hingga Wilayah A kembali online. Jika memungkinkan, seperti dengan operasi penulisan idempoten, Anda harus mempertimbangkan untuk memutar ulang lalu lintas tulis terbaru (misalnya, dengan menggunakan sumber peristiwa hulu) untuk mengisi celah operasi penulisan yang berpotensi hilang dan membiarkan penulis terakhir memenangkan resolusi konflik menekan propagasi akhirnya dari operasi penulisan yang masuk.
Dengan mode tulis lainnya, Anda harus mempertimbangkan sejauh mana pekerjaan dapat dilanjutkan dengan sedikit out-of-date pandangan dunia. Beberapa operasi tulis berdurasi pendek, seperti yang dilacak oleh `ReplicationLatency`, akan hilang hingga Wilayah A kembali online. Apakah bisnis bisa maju? Dalam beberapa kasus penggunaan, bisa, tetapi pada kasus lainnya mungkin tidak bisa, tanpa mekanisme mitigasi tambahan.
Misalnya, bayangkan Anda harus mempertahankan saldo kredit yang tersedia tanpa gangguan bahkan setelah pemadaman penuh suatu Wilayah. Anda dapat membagi saldo menjadi dua item yang berbeda, satu homed di Wilayah A dan satu di Wilayah B, dan mulai masing-masing dengan setengah saldo yang tersedia. Ini akan menggunakan mode *tulis ke Wilayah Anda*. Pembaruan transaksional yang diproses di setiap Wilayah akan dituliskan pada salinan lokal saldo. Jika Wilayah A sepenuhnya offline, pekerjaan masih dapat dilanjutkan dengan pemrosesan transaksi di Wilayah B, dan operasi tulis akan terbatas pada bagian saldo yang disimpan di Wilayah B. Memisahkan saldo seperti ini menimbulkan kerumitan ketika saldo hampir habis atau kredit harus diseimbangkan kembali, tetapi hal ini memberikan satu contoh pemulihan bisnis yang aman bahkan dengan operasi tulis tertunda yang tidak pasti.
Sebagai contoh lain, bayangkan Anda menangkap data formulir web. Anda dapat menggunakan [Optimistic Concurrency Control (OCC)](DynamoDBMapper.OptimisticLocking.md) (OCC) untuk menetapkan versi ke item data dan menyematkan versi terbaru ke formulir web sebagai bidang tersembunyi. Pada setiap pengiriman, operasi tulis berhasil hanya jika versi dalam basis data masih cocok dengan versi yang digunakan untuk membuat formulir. Jika versinya tidak cocok, formulir web bisa disegarkan (atau digabungkan secara hati-hati) berdasarkan versi saat ini dalam basis data, dan pengguna bisa melanjutkan lagi. Model OCC biasanya melindungi terhadap penimpaan klien lain dan pembuatan versi data yang baru, tetapi model ini juga dapat membantu selama failover ketika klien mungkin menemukan versi data yang lebih lama. Misalkan Anda menggunakan timestamp sebagai versinya. Formulir ini pertama kali dibangun terhadap Wilayah A pada pukul 12:00 tetapi (setelah failover) mencoba menulis ke Wilayah B dan pemberitahuan bahwa versi terbaru dalam database adalah 11:59. Dalam skenario ini, klien dapat menunggu versi 12.00 untuk disebarkan ke Wilayah B lalu menulis di atas versi tersebut, atau membangun pada 11.59 dan membuat versi 12.01 baru (yang, setelah ditulis, akan menyembunyikan versi yang masuk setelah Wilayah A pulih).
Sebagai contoh ketiga, perusahaan jasa keuangan menyimpan data tentang akun pelanggan dan transaksi keuangan mereka dalam database DynamoDB. Jika terjadi pemadaman Wilayah A yang lengkap, mereka ingin memastikan bahwa aktivitas menulis apa pun yang terkait dengan akun mereka sepenuhnya tersedia di Wilayah B, atau mereka ingin mengkarantina akun mereka sebagaimana diketahui sebagian sampai Wilayah A kembali online. Alih-alih menghentikan semua bisnis, mereka memutuskan untuk menghentikan bisnis untuk sementara waktu, hanya pada sebagian kecil akun yang mereka anggap memiliki transaksi yang tidak disebarkan. Untuk mencapai hal ini, mereka menggunakan Wilayah ketiga, yang akan kita sebut Wilayah C. Sebelum memproses operasi tulis apa pun di Wilayah A, mereka menempatkan ringkasan singkat operasi yang tertunda tersebut (misalnya, jumlah transaksi baru untuk sebuah akun) di Wilayah C. Ringkasan ini cukup bagi Wilayah B untuk menentukan apakah pandangannya benar-benar mutakhir. Tindakan ini mengunci akun secara efektif sejak penulisan di Wilayah C hingga Wilayah A menerima operasi tulis dan Wilayah B menerimanya. Data di Wilayah C tidak digunakan kecuali sebagai bagian dari proses failover, setelah itu Wilayah B dapat memeriksa datanya dengan Wilayah C untuk mengetahui apakah ada akun yang kedaluwarsa. Akun-akun tersebut akan ditandai sebagai karantina sampai pemulihan Wilayah A menyebarkan sebagian data ke Wilayah B. Jika Wilayah C gagal, Wilayah D baru dapat diputar untuk digunakan sebagai gantinya. Data di Wilayah C sangat sementara, dan setelah beberapa menit Wilayah D akan memiliki up-to-date catatan yang cukup tentang operasi penulisan dalam penerbangan untuk sepenuhnya berguna. Jika Wilayah B gagal, Wilayah A dapat terus menerima permintaan tulis yang bekerja sama dengan Wilayah C. Perusahaan ini bersedia menerima penulisan dengan latensi yang lebih tinggi (ke dua Wilayah: C dan kemudian A) dan beruntung memiliki model data yang status akunnya dapat dirangkum secara ringkas. ](bp-global-table-design.prescriptive-guidance.evacuation.md#bp-global-table-design.prescriptive-guidance.evacuation.title)[Proses evakuasi](bp-global-table-design.prescriptive-guidance.evacuation.md), 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](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) daftar metrik yang harus diamati. Anda juga harus menggunakan [synthetic canary](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html) (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](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) 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**
Dengan prosedur failover, praktik terbaik adalah hanya mengandalkan operasi pesawat data dan bukan pada operasi pesawat kontrol, karena beberapa operasi pesawat kontrol dapat terdegradasi selama kegagalan Wilayah.
Untuk informasi selengkapnya, lihat posting AWS blog [Membangun aplikasi tangguh dengan tabel global Amazon DynamoDB](https://aws.amazon.com/blogs/database/part-4-build-resilient-applications-with-amazon-dynamodb-global-tables/): 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](https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html)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 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.
## Pertanyaan yang Sering Diajukan (FAQ) untuk men-deploy tabel global
**Berapa harga untuk tabel global?**
+ 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.
**Wilayah mana yang didukung tabel global?**
[Tabel Global versi 2019.11.21 (Saat ini)](GlobalTables.md) mendukung semua Wilayah AWS untuk tabel MREC dan set Wilayah berikut untuk tabel MRSC:
+ 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)
**Bagaimana GSIs ditangani dengan tabel global?**
Di [Tabel Global versi 2019.11.21 (Saat Ini), saat](GlobalTables.md) Anda membuat GSI di satu Wilayah, GSI 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, 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.
**Bagaimana DynamoDB Streams berinteraksi dengan tabel global?**
+ 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.
**Bagaimana tabel global menangani transaksi?**
+ 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.
**Bagaimana tabel global berinteraksi dengan cache DynamoDB Accelerator (DAX)?**
Tabel global melewati DAX dengan memperbarui DynamoDB secara langsung, sehingga DAX tidak mengetahui jika menyimpan data yang sudah usang. Cache DAX disegarkan hanya ketika TTL cache 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 (PITR](PointInTimeRecovery_Howitworks.md)) di satu Wilayah.
**Bagaimana cara saya menyebarkan tabel global menggunakan? 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 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](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-globaltable.html) 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 ke`Retain`, 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](https://github.com/aws-samples/amazon-dynamodb-table-to-global-table-cdk).
+ Replikasi lintas akun tidak didukung saat ini.
## Kesimpulan dan sumber daya
Tabel global DynamoDB memiliki kontrol yang sangat sedikit tetapi masih memerlukan pertimbangan yang cermat. 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. Hadiahnya adalah memiliki kumpulan data yang didistribusikan secara global dengan operasi baca dan tulis latensi rendah yang dirancang untuk ketersediaan 99,999%.
Untuk informasi selengkapnya tentang tabel global DynamoDB, lihat sumber daya berikut:
+ [Dokumentasi DynamoDB](https://docs.aws.amazon.com/dynamodb/)
+ [Pengontrol Pemulihan Aplikasi Amazon](https://aws.amazon.com/application-recovery-controller/)
+ [Pemeriksaan kesiapan di ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/recovery-readiness.html) (AWS dokumentasi)
+ [Kebijakan perutean Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)
+ [AWS Akselerator Global](https://aws.amazon.com/global-accelerator/)
+ [Perjanjian tingkat layanan DynamoDB](https://aws.amazon.com/dynamodb/sla/)
+ [AWS Dasar-dasar Multi-Wilayah (whitepaper](https://docs.aws.amazon.com/prescriptive-guidance/latest/aws-multi-region-fundamentals/introduction.html))AWS
+ [Pola desain ketahanan data dengan AWS](https://www.youtube.com/watch?v=7IA48SOX20c) (AWS re:Invent 2022 presentasi)
+ [Bagaimana Fidelity Investments dan Reltio dimodernisasi dengan Amazon DynamoDB](https://www.youtube.com/watch?v=QUpV5MDu4Ys&t=706s) (presentasi Re:invent 2022)AWS
+ [Pola desain Multi-Wilayah dan praktik terbaik](https://www.youtube.com/watch?v=ilgpzlE7Hds&t=1882s) (AWS re:Invent 2022 presentasi)
+ [Arsitektur Pemulihan Bencana (DR) pada AWS, Bagian III: Pilot Light and Warm Standby](https://aws.amazon.com/blogs/architecture/disaster-recovery-dr-architecture-on-aws-part-iii-pilot-light-and-warm-standby/) (posting AWS blog)
+ [Gunakan pin Wilayah untuk mengatur Wilayah beranda untuk item dalam tabel global AWS Amazon DynamoDB](https://aws.amazon.com/blogs/database/use-region-pinning-to-set-a-home-region-for-items-in-an-amazon-dynamodb-global-table/) (posting blog)
+ [Memantau Amazon DynamoDB untuk kesadaran AWS operasional](https://aws.amazon.com/blogs/database/monitoring-amazon-dynamodb-for-operational-awareness/) (posting blog)
+ [Penskalaan DynamoDB: Bagaimana partisi, tombol pintas, dan split untuk kinerja dampak panas](https://aws.amazon.com/blogs/database/part-3-scaling-dynamodb-how-partitions-hot-keys-and-split-for-heat-impact-performance/) (posting blog)AWS
+ [Konsistensi kuat Multi-Region dengan tabel AWS global DynamoDB (presentasi Re:invent](https://www.youtube.com/watch?v=R-nTs8ZD8mA) 2024)