Proses evakuasi untuk tabel global

Mengevakuasi suatu Wilayah adalah proses migrasi aktivitas—biasanya aktivitas menulis, mungkin aktivitas membaca — jauh dari Wilayah itu.

Mengevakuasi Wilayah langsung

Anda dapat memutuskan untuk mengevakuasi Wilayah langsung karena sejumlah alasan: sebagai bagian dari aktivitas bisnis biasa (misalnya, jika Anda menggunakan, tulis ke satu mode Wilayah)follow-the-sun, karena keputusan bisnis untuk mengubah Wilayah yang saat ini aktif, sebagai respons terhadap kegagalan dalam tumpukan perangkat lunak di luar DynamoDB, atau karena Anda menghadapi masalah umum seperti latensi yang lebih tinggi dari biasanya di Wilayah.

Dengan menulis ke mode Wilayah apa pun, mengevakuasi Wilayah langsung sangatlah mudah. Anda dapat mengarahkan lalu lintas ke Wilayah alternatif dengan menggunakan sistem perutean apa pun, dan membiarkan operasi penulisan yang telah terjadi di Wilayah yang dievakuasi mereplikasi seperti biasa.

Dengan menulis ke satu Wilayah dan menulis ke mode Wilayah Anda, 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 yang baru, untuk memastikan bahwa operasi penulisan di future diproses terhadap versi data terbaru.

Katakanlah bahwa Wilayah A aktif dan Wilayah B pasif (baik untuk tabel penuh atau untuk item yang homed di Wilayah A). Mekanisme khas untuk melakukan evakuasi adalah dengan menghentikan operasi penulisan ke A, menunggu cukup lama hingga operasi tersebut disebarkan sepenuhnya ke B, memperbarui tumpukan arsitektur untuk mengenali B sebagai aktif, dan kemudian melanjutkan operasi tulis ke B. tidak ada metrik untuk menunjukkan dengan kepastian mutlak bahwa Wilayah A telah sepenuhnya mereplikasi datanya ke Wilayah B. jika Wilayah A sehat, menghentikan operasi tulis ke Wilayah A dan menunggu 10 kali nilai maksimum ReplicationLatency metrik baru-baru ini biasanya akan cukup untuk menentukan bahwa replikasi selesai. Jika Wilayah A tidak sehat dan menunjukkan area latensi lain yang meningkat, Anda akan memilih kelipatan yang lebih besar untuk waktu tunggu.

Mengevakuasi offline

Ada kasus khusus yang perlu dipertimbangkan: Bagaimana jika Wilayah A sepenuhnya offline tanpa pemberitahuan? Ini sangat tidak mungkin tetapi harus dipertimbangkan. Jika ini terjadi, setiap operasi penulisan di Wilayah A yang belum disebarkan akan diadakan dan disebarkan setelah Wilayah A kembali online. Operasi penulisan tidak hilang, tetapi propagasi mereka tertunda tanpa batas waktu.

Cara melanjutkan dalam acara ini adalah keputusan aplikasi. Untuk kelangsungan bisnis, operasi tulis mungkin perlu melanjutkan ke Wilayah B. primer baru Namun, jika item di Wilayah B menerima pembaruan sementara ada propagasi yang tertunda dari operasi tulis untuk item tersebut dari Wilayah A, propagasi ditekan di bawah model win penulis terakhir. Pembaruan apa pun di Wilayah B mungkin menekan permintaan penulisan yang masuk.

Dengan menulis ke mode Wilayah apa pun, operasi baca dan tulis dapat berlanjut 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. Bila memungkinkan, seperti dengan operasi tulis idempoten, Anda harus mempertimbangkan memutar ulang lalu lintas tulis baru-baru ini (misalnya, dengan menggunakan sumber peristiwa hulu) untuk mengisi celah dari setiap operasi tulis yang berpotensi hilang dan membiarkan penulis terakhir memenangkan resolusi konflik menekan propagasi akhirnya operasi tulis yang masuk.

Dengan mode tulis lainnya, Anda harus mempertimbangkan sejauh mana pekerjaan dapat dilanjutkan dengan sedikit out-of-date pandangan dunia. Beberapa durasi operasi tulis yang kecil, seperti yang dilacak olehReplicationLatency, akan hilang sampai Wilayah A kembali online. Bisakah bisnis bergerak maju? Dalam beberapa kasus penggunaan itu bisa, tetapi dalam kasus lain mungkin tidak tanpa mekanisme mitigasi tambahan.

Misalnya, bayangkan Anda harus menjaga 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 write ke mode Region Anda. Pembaruan transaksional yang diproses di setiap Wilayah akan menuliskan salinan saldo lokal. Jika Wilayah A berjalan 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 memperkenalkan kompleksitas ketika saldo menjadi rendah atau kredit harus diseimbangkan kembali, tetapi itu memberikan satu contoh pemulihan bisnis yang aman bahkan dengan operasi penulisan tertunda yang tidak pasti.

Sebagai contoh lain, bayangkan bahwa Anda menangkap data formulir web. Anda dapat menggunakan kontrol konkurensi optimis (OCC) untuk menetapkan versi ke item data dan menyematkan versi terbaru ke dalam formulir web sebagai bidang tersembunyi. Pada setiap kirimkan, operasi tulis hanya berhasil jika versi dalam database masih cocok dengan versi yang dibuat oleh formulir. Jika versi tidak cocok, formulir web dapat di-refresh (atau digabungkan dengan hati-hati) berdasarkan versi saat ini dalam database, dan pengguna dapat melanjutkan lagi. Model OCC biasanya melindungi terhadap klien lain menimpa dan menghasilkan versi baru dari data, tetapi juga dapat membantu selama failover di mana klien mungkin menemukan versi data yang lebih lama. Mari kita bayangkan bahwa Anda menggunakan stempel waktu sebagai versi. 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 menyebarkan ke Wilayah B dan kemudian menulis di atas versi itu, atau membangun pada 11:59 dan membuat versi 12:01 baru (yang, setelah menulis, akan menekan versi masuk setelah Region 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 penulisan apa pun yang terkait dengan akun mereka sepenuhnya tersedia di Wilayah B, atau mereka ingin mengkarantina akun mereka sebagai sebagian yang diketahui sampai Wilayah A kembali online. Alih-alih menghentikan semua bisnis, mereka memutuskan untuk menghentikan bisnis hanya untuk sebagian kecil dari akun yang mereka tentukan memiliki transaksi yang tidak disebarkan. Untuk mencapai hal ini, mereka menggunakan Wilayah ketiga, yang akan kita sebut Wilayah C. Sebelum mereka memproses operasi tulis apa pun di Wilayah A, mereka menempatkan ringkasan singkat dari operasi yang tertunda (misalnya, jumlah transaksi baru untuk akun) di Wilayah C. ringkasan ini cukup untuk Wilayah B untuk menentukan apakah pandangannya sepenuhnya mutakhir. Tindakan ini secara efektif mengunci akun sejak penulisan di Wilayah C hingga Wilayah A menerima operasi penulisan dan Wilayah B menerimanya. Data di Wilayah C tidak digunakan kecuali sebagai bagian dari proses failover, setelah itu Wilayah B dapat memeriksa ulang datanya dengan Wilayah C untuk memeriksa apakah ada akunnya yang kedaluwarsa. Akun-akun tersebut akan ditandai sebagai karantina sampai pemulihan Wilayah A menyebarkan data sebagian ke Wilayah B. Jika Wilayah C gagal, Wilayah D baru dapat dipintal 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 agar sepenuhnya berguna. Jika Wilayah B gagal, Wilayah A dapat terus menerima permintaan tulis bekerjasama dengan Wilayah C. perusahaan ini bersedia menerima penulisan latensi yang lebih tinggi (ke dua Wilayah: C dan kemudian A) dan beruntung memiliki model data di mana keadaan akun dapat diringkas secara ringkas.