Mencapai ketersediaan tinggi dengan Azure Cosmos DB

  • Artikel

BERLAKU UNTUK: Nosql MongoDB Cassandra Gremlin Meja

Untuk membangun solusi dengan ketersediaan tinggi, Anda harus mengevaluasi karakteristik keandalan semua komponennya. Azure Cosmos DB menyediakan opsi fitur dan konfigurasi untuk membantu Anda mencapai ketersediaan tinggi untuk solusi Anda.

Artikel ini menggunakan istilah berikut:

  • Tujuan waktu pemulihan (RTO): Waktu antara awal pemadaman yang memengaruhi Azure Cosmos DB dan pemulihan ke ketersediaan penuh.
  • Tujuan titik pemulihan (RPO): Waktu antara penulisan terakhir yang dipulihkan dengan benar dan waktu awal pemadaman yang memengaruhi Azure Cosmos DB.

Catatan

RPO dan RTO yang diharapkan dan maksimum bergantung pada jenis pemadaman yang dialami Azure Cosmos DB. Misalnya, pemadaman satu node memiliki RTO dan RPO yang diharapkan berbeda dari pemadaman seluruh wilayah.

Artikel ini merinci peristiwa yang dapat memengaruhi ketersediaan Azure Cosmos DB dan opsi konfigurasi Azure Cosmos DB yang sesuai.

Pemeliharaan replika

Azure Cosmos DB adalah layanan multipenyewa yang mengelola semua detail simpul komputasi individual secara transparan. Pengguna tidak perlu khawatir tentang segala jenis patching atau pemeliharaan terencana. Azure Cosmos DB menjamin SLA untuk ketersediaan dan latensi P99 melalui semua operasi pemeliharaan otomatis yang dilakukan sistem.

Pemadaman replika

Pemadaman replika adalah pemadaman simpul individual dalam kluster Azure Cosmos DB yang disebarkan di wilayah Azure.

Azure Cosmos DB secara otomatis mengurangi pemadaman replika dengan menjamin setidaknya tiga replika data Anda di setiap wilayah Azure untuk akun Anda dalam kuorum empat replika. Jaminan ini menghasilkan RTO 0 dan RPO 0 untuk pemadaman simpul individu, tanpa memerlukan perubahan atau konfigurasi aplikasi.

Di banyak wilayah Azure, Dimungkinkan untuk mendistribusikan kluster Azure Cosmos DB Anda di seluruh zona ketersediaan. Zona ketersediaan dapat meningkatkan SLA karena secara fisik terpisah dan menyediakan sumber daya, jaringan, dan pendinginan yang berbeda. Saat Anda menyebarkan akun Azure Cosmos DB dengan menggunakan zona ketersediaan, Azure Cosmos DB menyediakan RTO 0 dan RPO 0, bahkan dalam pemadaman zona.

Saat Anda menyebarkan di satu wilayah Azure, tanpa input pengguna tambahan, Azure Cosmos DB tahan terhadap pemadaman simpul. Mengaktifkan redundansi di seluruh zona ketersediaan membuat Azure Cosmos DB tahan terhadap pemadaman zona dengan biaya peningkatan biaya.

Anda hanya dapat mengonfigurasi redundansi zona saat menambahkan wilayah baru ke akun Azure Cosmos DB. Untuk wilayah yang ada, Anda dapat mengaktifkan redundansi zona dengan menghapus wilayah lalu menambahkannya kembali dengan redundansi zona diaktifkan. Untuk akun wilayah tunggal, pendekatan ini mengharuskan Anda menambahkan wilayah untuk gagal sementara, lalu menghapus dan menambahkan wilayah yang diinginkan dengan redundansi zona diaktifkan.

Secara default, akun Azure Cosmos DB tidak menggunakan beberapa zona ketersediaan. Anda dapat mengaktifkan penyebaran di beberapa zona ketersediaan dengan cara berikut:

Jika akun Azure Cosmos DB Anda didistribusikan di seluruh wilayah N Azure, akan ada salinan N x 4 dari semua data Anda. Untuk informasi selengkapnya tentang cara Azure Cosmos DB mereplikasi data di setiap wilayah, lihat Distribusi global dengan Azure Cosmos DB. Memiliki akun Azure Cosmos DB di lebih dari dua wilayah meningkatkan ketersediaan aplikasi Anda dan memberikan latensi rendah di seluruh wilayah terkait.

Pemadaman wilayah

Pemadaman wilayah adalah pemadaman yang memengaruhi semua simpul Azure Cosmos DB di wilayah Azure, di semua zona ketersediaan. Untuk kasus pemadaman wilayah yang jarang terjadi, Anda dapat mengonfigurasi Azure Cosmos DB untuk mendukung berbagai hasil durabilitas dan ketersediaan.

Daya tahan

Saat akun Azure Cosmos DB disebarkan dalam satu wilayah, umumnya tidak ada kehilangan data yang terjadi. Akses data dipulihkan setelah layanan Azure Cosmos DB pulih di wilayah yang terpengaruh. Kehilangan data mungkin hanya terjadi dengan bencana yang tidak dapat dipulihkan di wilayah Azure Cosmos DB.

Untuk membantu Anda melindungi dari kehilangan data lengkap yang mungkin diakibatkan oleh bencana bencana di suatu wilayah, Azure Cosmos DB menyediakan dua mode pencadangan:

  • Pencadangan berkelanjutan mencadangkan setiap wilayah setiap 100 detik. Mereka memungkinkan Anda memulihkan data Anda ke titik waktu mana pun dengan granularitas 1 detik. Di setiap wilayah, pencadangan bergantung pada data yang diterapkan di wilayah tersebut.
  • Pencadangan berkala sepenuhnya mencadangkan semua partisi dari semua kontainer di bawah akun Anda, tanpa sinkronisasi di seluruh partisi. Interval pencadangan minimumnya adalah 1 jam.

Saat akun Azure Cosmos DB disebarkan di beberapa wilayah, durabilitas data bergantung pada tingkat konsistensi yang Anda konfigurasikan di akun. Detail tabel berikut, untuk semua tingkat konsistensi, RPO akun Azure Cosmos DB yang disebarkan di setidaknya dua wilayah.

Tingkat konsistensi RPO untuk pemadaman wilayah
Sesi, awalan yang konsisten, akhirnya Kurang dari 15 menit
Kedaluwarsa terikat K dan T
Kuat 0

K = Jumlah versi (yaitu, pembaruan) item.

T = Interval waktu sejak pembaruan terakhir.

Untuk akun beberapa wilayah, nilai minimum K dan T adalah 100.000 operasi tulis atau 300 detik. Nilai ini menentukan RPO minimum untuk data saat Anda menggunakan keusangan terikat.

Untuk informasi selengkapnya tentang perbedaan antara tingkat konsistensi, lihat Tingkat konsistensi di Azure Cosmos DB.

Ketersediaan

Jika solusi Anda memerlukan ketersediaan berkelanjutan selama pemadaman wilayah, Anda dapat mengonfigurasi Azure Cosmos DB untuk mereplikasi data Anda di beberapa wilayah dan melakukan failover secara transparan ke wilayah yang tersedia jika diperlukan.

Akun wilayah tunggal mungkin kehilangan ketersediaan setelah pemadaman regional. Untuk memastikan ketersediaan tinggi setiap saat, kami sarankan Anda menyiapkan akun Azure Cosmos DB Anda dengan satu wilayah tulis dan setidaknya satu detik (baca) wilayah dan mengaktifkan failover yang dikelola layanan.

Failover yang dikelola layanan memungkinkan Azure Cosmos DB gagal atas wilayah tulis akun beberapa wilayah untuk mempertahankan ketersediaan dengan biaya kehilangan data, seperti yang dijelaskan sebelumnya di bagian Durabilitas . Failover regional terdeteksi dan ditangani di klien Azure Cosmos DB. Failover tersebut tidak memerlukan perubahan apa pun dari aplikasi. Untuk petunjuk tentang cara mengaktifkan beberapa wilayah baca dan failover yang dikelola layanan, lihat Mengelola akun Azure Cosmos DB menggunakan portal Azure.

Penting

Jika Anda telah memilih konfigurasi tulis wilayah tunggal dengan beberapa wilayah baca, kami sangat menyarankan Anda mengonfigurasi akun Azure Cosmos DB yang digunakan untuk beban kerja produksi untuk mengaktifkan failover yang dikelola layanan. Konfigurasi ini memungkinkan Azure Cosmos DB melakukan failover pada database akun ke wilayah yang tersedia. Dengan tidak adanya konfigurasi ini, akun akan mengalami hilangnya ketersediaan tulis selama seluruh durasi pemadaman wilayah tulis. Failover manual tidak akan berhasil karena kurangnya konektivitas wilayah.

Peringatan

Bahkan dengan failover yang dikelola layanan diaktifkan, pemadaman parsial mungkin memerlukan intervensi manual untuk tim layanan Azure Cosmos DB. Dalam skenario ini, mungkin perlu waktu hingga 1 jam (atau lebih) agar failover berlaku. Untuk ketersediaan tulis yang lebih baik selama pemadaman parsial, sebaiknya aktifkan zona ketersediaan selain failover yang dikelola layanan.

Beberapa wilayah tulis

Anda dapat mengonfigurasi Azure Cosmos DB untuk menerima tulisan di beberapa wilayah. Konfigurasi ini berguna untuk mengurangi latensi tulis dalam aplikasi yang didistribusikan secara geografis.

Saat Anda mengonfigurasi akun Azure Cosmos DB untuk beberapa wilayah tulis, konsistensi yang kuat tidak didukung dan konflik penulisan mungkin muncul. Untuk informasi selengkapnya tentang cara mengatasi konflik ini, lihat Jenis konflik dan kebijakan resolusi saat menggunakan beberapa wilayah tulis.

Penting

Sering memperbarui ID Dokumen yang sama (atau sering membuat ulang ID dokumen yang sama setelah TTL atau penghapusan) akan berpengaruh pada performa replikasi karena peningkatan jumlah konflik yang dihasilkan dalam sistem.  

Wilayah resolusi konflik

Ketika akun Azure Cosmos DB dikonfigurasi dengan penulisan beberapa wilayah, salah satu wilayah akan bertindak sebagai arbiter dalam konflik tulis.

Praktik terbaik untuk penulisan multi-wilayah

Berikut adalah beberapa praktik terbaik untuk dipertimbangkan saat Anda menulis ke beberapa wilayah.

Menjaga lalu lintas lokal tetap lokal

Ketika Anda menggunakan penulisan beberapa wilayah, aplikasi harus mengeluarkan lalu lintas baca dan tulis yang berasal dari wilayah lokal secara ketat ke wilayah Cosmos DB lokal. Untuk performa optimal, hindari panggilan lintas wilayah.

Penting bagi aplikasi untuk meminimalkan konflik dengan menghindari antipattern berikut:

  • Mengirim operasi tulis yang sama ke semua wilayah untuk meningkatkan peluang mendapatkan waktu respons yang cepat

  • Menentukan wilayah target secara acak untuk operasi baca atau tulis berdasarkan per permintaan

  • Menggunakan kebijakan round-robin untuk menentukan wilayah target untuk operasi baca atau tulis berdasarkan per permintaan

Hindari dependensi pada lag replikasi

Anda tidak dapat mengonfigurasi akun tulis beberapa wilayah untuk konsistensi yang kuat. Wilayah yang sedang ditulis untuk merespons segera setelah Azure Cosmos DB mereplikasi data secara lokal sambil mereplikasi data secara asinkron secara global.

Meskipun jarang terjadi, lag replikasi mungkin terjadi pada satu atau beberapa partisi saat Anda mereplikasi data secara geografis. Lag replikasi dapat terjadi karena blip langka dalam lalu lintas jaringan atau tingkat resolusi konflik yang lebih tinggi dari biasanya.

Misalnya, arsitektur tempat aplikasi menulis ke Wilayah A tetapi berbunyi dari Wilayah B memperkenalkan dependensi pada lag replikasi antara kedua wilayah. Namun, jika aplikasi membaca dan menulis ke wilayah yang sama, performa tetap konstan bahkan di hadapan jeda replikasi.

Mengevaluasi penggunaan konsistensi sesi untuk operasi tulis

Dalam konsistensi sesi, Anda menggunakan token sesi untuk operasi baca dan tulis.

Untuk operasi baca, Azure Cosmos DB mengirimkan token sesi yang di-cache ke server dengan jaminan menerima data yang sesuai dengan token sesi yang ditentukan (atau yang lebih baru).

Untuk operasi tulis, Azure Cosmos DB mengirimkan token sesi ke database dengan jaminan mempertahankan data hanya jika server telah menangkap token sesi yang disediakan. Di akun tulis wilayah tunggal, wilayah tulis selalu dijamin telah terjebak ke token sesi. Namun, di akun tulis beberapa wilayah, wilayah yang Anda tulis mungkin belum terjebak untuk menulis yang dikeluarkan ke wilayah lain. Jika klien menulis ke Wilayah A dengan token sesi dari Wilayah B, Wilayah A tidak akan dapat mempertahankan data hingga mencapai perubahan yang dilakukan di Wilayah B.

Yang terbaik adalah menggunakan token sesi hanya untuk operasi baca dan bukan untuk operasi tulis saat Anda melewati token sesi antar instans klien.

Mengurangi pembaruan cepat ke dokumen yang sama

Pembaruan server untuk mengatasi atau mengonfirmasi tidak adanya konflik dapat bertabrakan dengan tulisan yang dipicu oleh aplikasi ketika dokumen yang sama berulang kali diperbarui. Pembaruan berulang berturut-turut cepat ke dokumen yang sama mengalami latensi yang lebih tinggi selama penyelesaian konflik.

Meskipun sesekali burst dalam pembaruan berulang ke dokumen yang sama tidak dapat dihindari, Anda mungkin mempertimbangkan untuk menjelajahi arsitektur tempat dokumen baru dibuat sebagai gantinya jika lalu lintas status stabil melihat pembaruan cepat ke dokumen yang sama selama periode yang lama.

Apa yang diharapkan selama pemadaman wilayah

Klien akun wilayah tunggal akan mengalami hilangnya ketersediaan baca dan tulis hingga layanan dipulihkan.

Akun beberapa wilayah mengalami perilaku yang berbeda tergantung pada konfigurasi dan jenis pemadaman berikut.

Konfigurasi Penghentian Dampak ketersediaan Dampak durabilitas Apa yang harus dilakukan
Wilayah tulis tunggal Pemadaman wilayah baca Semua klien secara otomatis mengalihkan bacaan ke wilayah lain. Tidak ada kehilangan ketersediaan baca atau tulis untuk semua konfigurasi. Pengecualian adalah konfigurasi dua wilayah dengan konsistensi yang kuat, yang kehilangan ketersediaan tulis hingga pemulihan layanan. Atau, jika Anda mengaktifkan failover yang dikelola layanan, layanan menandai wilayah sebagai gagal dan failover terjadi. Tidak ada kehilangan data. Selama pemadaman, pastikan bahwa ada cukup Unit Permintaan (RU) yang disediakan di wilayah yang tersisa untuk mendukung lalu lintas baca.

Ketika pemadaman berakhir, RUs yang diprovisikan sebagaimana mewajibkan readjust.
Wilayah tulis tunggal Pemadaman wilayah penulisan Klien mengalihkan bacaan ke wilayah lain.

Tanpa failover yang dikelola layanan, klien mengalami kehilangan ketersediaan tulis. Pemulihan ketersediaan tulis terjadi secara otomatis ketika pemadaman berakhir.

Dengan failover yang dikelola layanan, klien mengalami kehilangan ketersediaan tulis hingga layanan mengelola failover ke wilayah tulis baru yang Anda pilih.		 Jika Anda tidak memilih tingkat konsistensi yang kuat, layanan mungkin tidak mereplikasi beberapa data ke wilayah aktif yang tersisa. Replikasi ini tergantung pada tingkat konsistensi yang Anda pilih. Jika wilayah yang terpengaruh mengalami kehilangan data permanen, Anda dapat kehilangan data yang tidak direplikasi. Selama pemadaman, pastikan bahwa ada cukup RUs yang disediakan di wilayah yang tersisa untuk mendukung lalu lintas baca.

Jangan memicu failover manual selama pemadaman, karena tidak dapat berhasil.

Ketika pemadaman berakhir, RUs yang diprovisikan sebagaimana mewajibkan readjust. Akun yang menggunakan API untuk NoSQL mungkin juga memulihkan data yang tidak direplikasi di wilayah yang gagal dari umpan konflik Anda.
Beberapa wilayah tulis Semua pemadaman regional Ada kemungkinan hilangnya ketersediaan tulis sementara, yang dianalogikan dengan satu wilayah tulis dengan failover yang dikelola layanan. Kegagalan wilayah resolusi konflik juga dapat menyebabkan hilangnya ketersediaan tulis jika sejumlah besar penulisan yang bertentangan terjadi pada saat pemadaman. Data yang baru diperbarui di wilayah yang gagal mungkin tidak tersedia di wilayah aktif yang tersisa, tergantung pada tingkat konsistensi yang dipilih. Jika wilayah yang terpengaruh mengalami kehilangan data permanen, Anda mungkin kehilangan data yang tidak direplikasi. Selama pemadaman, pastikan bahwa ada cukup RU yang disediakan di wilayah yang tersisa untuk mendukung lebih banyak lalu lintas.

Ketika pemadaman berakhir, Anda dapat membaca RU yang disediakan sebagaimana mewajibkan. Jika memungkinkan, Azure Cosmos DB secara otomatis memulihkan data yang tidak direplikasi di wilayah yang gagal. Pemulihan otomatis ini menggunakan metode resolusi konflik yang Anda konfigurasi untuk akun yang menggunakan API untuk NoSQL. Untuk akun yang menggunakan API lain, pemulihan otomatis ini menggunakan kemenangan tulis terakhir.

Informasi tambahan tentang pemadaman wilayah baca

  • Wilayah yang terpengaruh terputus dan ditandai offline. Azure Cosmos DB SDK mengalihkan panggilan baca ke wilayah berikutnya yang tersedia di daftar wilayah pilihan.

  • Jika tidak ada wilayah di daftar wilayah pilihan yang tersedia, panggilan secara otomatis kembali ke wilayah tulis saat ini.

  • Tidak ada perubahan yang diperlukan dalam kode aplikasi Anda untuk menangani pemadaman wilayah baca. Ketika wilayah baca yang terpengaruh kembali online, wilayah tersebut disinkronkan dengan wilayah tulis saat ini dan tersedia lagi untuk melayani permintaan baca setelah sepenuhnya terperangkap.

  • Bacaan berikutnya dialihkan ke wilayah yang dipulihkan tanpa memerlukan perubahan apa pun pada kode aplikasi Anda. Selama failover dan bergabung kembali dengan wilayah yang sebelumnya gagal, Azure Cosmos DB terus mematuhi jaminan konsistensi baca.

  • Bahkan dalam peristiwa langka dan tidak menguntungkan di mana wilayah tulis Azure secara permanen tidak dapat dipulihkan, tidak ada kehilangan data jika akun Azure Cosmos DB beberapa wilayah Anda dikonfigurasi dengan konsistensi yang kuat. Akun Azure Cosmos DB beberapa wilayah memiliki karakteristik durabilitas yang ditentukan sebelumnya di bagian Durabilitas .

Informasi tambahan tentang pemadaman wilayah penulisan

  • Selama pemadaman wilayah tulis, akun Azure Cosmos DB mempromosikan wilayah sekunder menjadi wilayah tulis utama baru ketika failover yang dikelola layanan dikonfigurasi pada akun Azure Cosmos DB. Failover terjadi ke wilayah lain dalam urutan prioritas wilayah yang Anda tentukan.

  • Failover manual tidak boleh dipicu dan tidak akan berhasil jika terjadi pemadaman wilayah sumber atau tujuan. Alasannya adalah bahwa prosedur failover mencakup pemeriksaan konsistensi yang memerlukan konektivitas antar wilayah.

  • Ketika wilayah yang sebelumnya terpengaruh kembali online, data tulis apa pun yang tidak direplikasi ketika wilayah gagal tersedia melalui umpan konflik. Aplikasi dapat membaca umpan konflik, mengatasi konflik berdasarkan logika khusus aplikasi, dan menulis data yang diperbarui kembali ke kontainer Azure Cosmos DB yang sesuai.

  • Setelah wilayah tulis yang terkena dampak sebelumnya pulih, wilayah tersebut akan ditampilkan sebagai "online" di portal Azure, dan tersedia sebagai wilayah baca. Pada titik ini, aman untuk beralih kembali ke wilayah yang dipulihkan sebagai wilayah tulis dengan menggunakan PowerShell, Azure CLI, atau portal Azure. Tidak ada data atau kehilangan ketersediaan sebelum, sementara, atau setelah Anda mengalihkan wilayah tulis. Aplikasi Anda terus sangat tersedia.

Peringatan

Jika terjadi pemadaman wilayah tulis, di mana akun Azure Cosmos DB mempromosikan wilayah sekunder menjadi wilayah tulis utama baru melalui failover yang dikelola layanan, wilayah tulis asli tidak akan dipromosikan kembali karena wilayah tulis secara otomatis setelah dipulihkan. Anda bertanggung jawab untuk beralih kembali ke wilayah yang dipulihkan sebagai wilayah tulis menggunakan PowerShell, Azure CLI, atau portal Azure (setelah aman untuk melakukannya, seperti yang dijelaskan di atas).

SLA

Tabel berikut ini meringkas kemampuan ketersediaan tinggi dari berbagai konfigurasi akun.

KPI Penulisan wilayah tunggal tanpa zona ketersediaan Penulisan wilayah tunggal dengan zona ketersediaan Penulisan multi-wilayah dan wilayah tunggal tanpa zona ketersediaan Penulisan multi-wilayah dan wilayah tunggal dengan zona ketersediaan Penulisan multi-wilayah beberapa wilayah dengan atau tanpa zona ketersediaan
SLA ketersediaan tulis 99,99% 99.995% 99,99% 99.995% 99,999%
SLA ketersediaan baca 99,99% 99.995% 99,999% 99,999% 99,999%
Kegagalan zona: kehilangan data Kehilangan data Tidak ada kehilangan data Tidak ada kehilangan data Tidak ada kehilangan data Tidak ada kehilangan data
Kegagalan zona: ketersediaan Kehilangan ketersediaan Tidak ada kehilangan ketersediaan Tidak ada kehilangan ketersediaan Tidak ada kehilangan ketersediaan Tidak ada kehilangan ketersediaan
Pemadaman regional: kehilangan data Kehilangan data Kehilangan data Tergantung pada tingkat konsistensi. Untuk informasi selengkapnya, lihat Konsistensi, ketersediaan, dan tradeoff performa. Tergantung pada tingkat konsistensi. Untuk informasi selengkapnya, lihat Konsistensi, ketersediaan, dan tradeoff performa. Tergantung pada tingkat konsistensi. Untuk informasi selengkapnya, lihat Konsistensi, ketersediaan, dan tradeoff performa.
Pemadaman regional: ketersediaan Kehilangan ketersediaan Kehilangan ketersediaan Tidak ada kerugian ketersediaan untuk kegagalan wilayah baca, sementara untuk kegagalan wilayah tulis Tidak ada kerugian ketersediaan untuk kegagalan wilayah baca, sementara untuk kegagalan wilayah tulis Tidak ada kehilangan ketersediaan baca, kehilangan ketersediaan tulis sementara di wilayah yang terpengaruh
Harga (1) Tidak berlaku Tarif RU/s x 1.25 yang disediakan Wilayah RU/s x N yang disediakan RU/s x 1.25 tarif x wilayah N yang tersedia (2) Tingkat tulis beberapa wilayah x wilayah N

1 Untuk akun tanpa server, RU dikalikan dengan faktor 1,25.

2 Tarif 1.25 hanya berlaku untuk wilayah tempat Anda mengaktifkan zona ketersediaan.

Tips untuk membangun aplikasi yang sangat tersedia

  • Tinjau perilaku SDK Azure Cosmos DB yang diharapkan selama peristiwa dan konfigurasi mana yang memengaruhinya.

  • Untuk memastikan ketersediaan tulis dan baca yang tinggi, konfigurasikan akun Azure Cosmos DB Anda untuk menjangkau setidaknya dua wilayah (atau tiga, jika Anda menggunakan konsistensi yang kuat). Untuk mempelajari selengkapnya, lihat Tutorial: Menyiapkan distribusi global Azure Cosmos DB menggunakan API untuk NoSQL.

  • Untuk akun Azure Cosmos DB beberapa wilayah yang dikonfigurasi dengan satu wilayah tulis, aktifkan failover yang dikelola layanan dengan menggunakan Azure CLI atau portal Azure. Setelah Anda mengaktifkan failover yang dikelola layanan, setiap kali ada bencana regional, Azure Cosmos DB akan gagal atas akun Anda tanpa input pengguna.

  • Bahkan jika akun Azure Cosmos DB Anda sangat tersedia, aplikasi Anda mungkin tidak dirancang dengan benar untuk tetap sangat tersedia. Untuk menguji ketersediaan tinggi end-to-end aplikasi Anda sebagai bagian dari pengujian aplikasi atau latihan pemulihan bencana (DR), nonaktifkan failover yang dikelola layanan untuk akun untuk sementara waktu. Panggil failover manual dengan menggunakan PowerShell, Azure CLI, atau portal Azure, lalu pantau aplikasi Anda. Setelah menyelesaikan pengujian, Anda dapat melakukan failover kembali ke wilayah utama dan memulihkan failover yang dikelola layanan untuk akun tersebut.

    Penting

    Jangan panggil failover manual selama pemadaman Azure Cosmos DB di wilayah sumber atau tujuan. Failover manual memerlukan konektivitas wilayah untuk mempertahankan konsistensi data, sehingga tidak akan berhasil.

  • Dalam lingkungan database yang didistribusikan secara global ada hubungan langsung antara tingkat konsistensi dan ketahanan data di hadapan pemadaman di seluruh wilayah. Saat Anda mengembangkan rencana kelangsungan bisnis, Anda perlu memahami waktu maksimum yang dapat diterima sebelum aplikasi sepenuhnya pulih setelah peristiwa yang mengganggu (yaitu, RTO). Anda juga perlu memahami periode maksimum pembaruan data terbaru yang dapat ditoleransi aplikasi untuk kehilangan ketika pulih setelah peristiwa yang mengganggu (yaitu, RPO). Untuk informasi selengkapnya tentang RTO dan RPO, lihat Tingkat konsistensi di Azure Cosmos DB.

Apa yang diharapkan selama pemadaman wilayah Azure Cosmos DB

Untuk akun wilayah tunggal, klien mengalami hilangnya ketersediaan baca dan tulis selama pemadaman wilayah Azure Cosmos DB. Akun beberapa wilayah mengalami perilaku yang berbeda, seperti yang dijelaskan dalam tabel berikut.

Menulis wilayah Failover yang dikelola layanan Ekspektasi yang diinginkan Apa yang harus dilakukan
Wilayah tulis tunggal Tidak diaktifkan Jika ada pemadaman di wilayah baca saat Anda tidak menggunakan konsistensi yang kuat, semua klien akan dialihkan ke wilayah lain. Tidak ada kehilangan ketersediaan baca atau tulis, dan tidak ada kehilangan data. Saat Anda menggunakan konsistensi yang kuat, pemadaman di wilayah baca dapat memengaruhi ketersediaan tulis jika kurang dari dua wilayah baca tetap ada.

Jika ada pemadaman di wilayah tulis, klien mengalami kehilangan ketersediaan tulis. Jika Anda tidak memilih konsistensi yang kuat, layanan mungkin tidak mereplikasi beberapa data ke wilayah aktif yang tersisa. Replikasi ini tergantung pada tingkat konsistensi yang dipilih. Jika wilayah yang terpengaruh mengalami kehilangan data permanen, Anda mungkin kehilangan data yang tidak direplikasi.

Azure Cosmos DB memulihkan ketersediaan tulis saat pemadaman berakhir.		 Selama pemadaman, pastikan bahwa ada cukup RUs yang disediakan di wilayah yang tersisa untuk mendukung lalu lintas baca.

Jangan memicu failover manual selama pemadaman, karena tidak dapat berhasil.

Ketika pemadaman berakhir, RUs yang diprovisikan sebagaimana mewajibkan readjust.
Wilayah tulis tunggal Diaktifkan Jika ada pemadaman di wilayah baca saat Anda tidak menggunakan konsistensi yang kuat, semua klien akan dialihkan ke wilayah lain. Tidak ada kehilangan ketersediaan baca atau tulis, dan tidak ada kehilangan data. Saat Anda menggunakan konsistensi yang kuat, pemadaman wilayah baca dapat memengaruhi ketersediaan tulis jika kurang dari dua wilayah baca tetap ada.

Jika ada pemadaman di wilayah tulis, klien mengalami kehilangan ketersediaan tulis hingga Azure Cosmos DB memilih wilayah baru sebagai wilayah tulis baru sesuai dengan preferensi Anda. Jika Anda tidak memilih konsistensi yang kuat, layanan mungkin tidak mereplikasi beberapa data ke wilayah aktif yang tersisa. Replikasi ini tergantung pada tingkat konsistensi yang dipilih. Jika wilayah yang terpengaruh mengalami kehilangan data permanen, Anda mungkin kehilangan data yang tidak direplikasi.		 Selama pemadaman, pastikan bahwa ada cukup RUs yang disediakan di wilayah yang tersisa untuk mendukung lalu lintas baca.

Jangan memicu failover manual selama pemadaman, karena tidak dapat berhasil.

Ketika pemadaman berakhir, Anda dapat memindahkan wilayah tulis kembali ke wilayah asli dan membaca RU yang disediakan sebagaimana mewajibkan. Akun yang menggunakan API untuk NoSQL juga dapat memulihkan data yang tidak direplikasi di wilayah yang gagal dari umpan konflik Anda.
Beberapa wilayah tulis Tidak berlaku Data yang baru diperbarui di wilayah yang gagal mungkin tidak tersedia di wilayah aktif yang tersisa. Awalan akhir, konsisten, dan tingkat konsistensi sesi menjamin keusangan kurang dari 15 menit. Keusangan terikat menjamin kurang dari pembaruan K atau detik T , tergantung pada konfigurasinya. Jika wilayah yang terpengaruh mengalami kehilangan data permanen, Anda mungkin kehilangan data yang tidak direplikasi. Selama pemadaman, pastikan bahwa ada cukup RU yang disediakan di wilayah yang tersisa untuk mendukung lebih banyak lalu lintas.

Ketika pemadaman berakhir, Anda dapat membaca RU yang disediakan sebagaimana mewajibkan. Jika memungkinkan, Azure Cosmos DB memulihkan data yang tidak direplikasi di wilayah yang gagal. Pemulihan ini menggunakan metode resolusi konflik yang Anda konfigurasi untuk akun yang menggunakan API untuk NoSQL. Untuk akun yang menggunakan API lain, pemulihan ini menggunakan kemenangan tulis terakhir.

Langkah berikutnya

Selanjutnya, Anda dapat membaca artikel berikut: