Bagikan melalui

Ketersediaan tinggi (keandalan) di Azure Cosmos DB untuk NoSQL

Artikel ini menjelaskan dukungan ketersediaan tinggi (keandalan) di Azure Cosmos DB untuk NoSQL dan mencakup zona ketersediaan, serta pemulihan bencana lintas wilayah dan kelangsungan bisnis.

Ketahanan simpul komputasi

Azure Cosmos DB secara transparan mengelola semua detail simpul komputasi individual. Anda tidak perlu khawatir tentang perbaikan patch atau pemeliharaan yang dijadwalkan. Azure Cosmos DB menjamin SLA untuk ketersediaan dan latensi P99 melalui semua operasi pemeliharaan otomatis yang dilakukan sistem.

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. Untuk informasi tentang RTO dan RPO, lihat Apa itu kelangsungan bisnis, ketersediaan tinggi, dan pemulihan bencana?.

Dukungan zona ketersediaan

Zona ketersediaan adalah grup pusat data yang terpisah secara fisik dalam wilayah Azure. Ketika satu zona gagal, layanan dapat melakukan failover ke salah satu zona yang tersisa.

Azure Cosmos DB mendukung redundansi zona. Saat Anda mengaktifkan redundansi zona, Azure mendistribusikan replika data Anda di beberapa zona ketersediaan, memberikan ketahanan terhadap masalah dan pemadaman pusat data. Anda dapat mengaktifkan redundansi zona di wilayah Azure yang mendukung zona ketersediaan. Untuk melihat apakah wilayah Anda mendukung zona ketersediaan, lihat daftar wilayah yang didukung.

Sebaiknya gunakan redundansi zona di wilayah yang didukungnya, terutama untuk akun wilayah tunggal.

Redundansi zona dan akun wilayah tunggal

Ketika Anda memiliki akun Cosmos DB satu wilayah, penting untuk tahan terhadap masalah di zona ketersediaan. Mengaktifkan redundansi zona melindungi dari kehilangan total ketersediaan akibat kegagalan sebuah zona ketersediaan.

Karena zona ketersediaan secara fisik terpisah dan menyediakan sumber daya, jaringan, dan pendinginan yang berbeda, ketersediaan SLA untuk Azure Cosmos DB lebih tinggi untuk akun zona redundan daripada akun yang tidak menggunakan zona ketersediaan.

Redundansi zona dan akun multi-region

Jika Anda memiliki akun multi-wilayah, Anda dapat mengaktifkan redundansi zona secara opsional pada salah satu atau semua wilayah akun yang mendukung zona ketersediaan. Akun lintas wilayah dapat mencapai SLA tingkat ketersediaan tinggi, dan mengaktifkan fitur redundansi zona dapat semakin meningkatkan SLA ketersediaan keseluruhan yang Anda capai di wilayah-wilayah tersebut.

Untuk akun multi-wilayah, dampak redundansi zona pada ketersediaan database Cosmos DB for NoSQL Anda tergantung pada tingkat konsistensi akun dan wilayah mana yang mengaktifkan redundansi zona. Lihat tabel di bawah ini untuk memperkirakan dampak penggunaan zona ketersediaan dalam konfigurasi akun multi-wilayah Anda:

Tingkat konsistensi akun Wilayah yang memiliki zona ketersediaan yang diaktifkan Dampak penggunaan zona ketersediaan
Sinkron (Kuat) Sebuah wilayah baca sekunder Manfaat tinggi dari redundansi zona. Memberikan nilai yang lebih besar karena hilangnya wilayah baca dalam skenario ini dapat memengaruhi ketersediaan penulisan.
Sinkron (Kuat) Dua atau beberapa wilayah baca sekunder Nilai redundansi zona yang lebih rendah. Memberikan nilai marginal karena sistem dapat memanfaatkan kuorum dinamis jika wilayah baca kehilangan ketersediaan yang memungkinkan penulisan berlanjut.
Asinkron (Keusangan Terikat atau lebih lemah) Satu atau beberapa wilayah baca sekunder Nilai redundansi zona yang lebih rendah. Memberikan nilai minimal karena SDK sudah menyediakan pengalihan yang mulus untuk pembacaan saat wilayah baca gagal.
Apa saja Semua wilayah tulis dan sejumlah wilayah sekunder Manfaat tinggi dari redundansi zona. Memastikan peningkatan ketersediaan untuk operasi tulis saat terjadi kegagalan zona ketersediaan.

Biaya mengaktifkan redundansi zona

Wilayah di mana redundansi zona diaktifkan dibebankan pada premium 25%. Namun, harga premium untuk zona ketersediaan dibebaskan untuk akun yang dikonfigurasi untuk penulisan multi-wilayah atau koleksi yang dikonfigurasi dalam mode pengaturan skala otomatis.

Menambahkan wilayah tambahan ke akun Cosmos DB biasanya meningkatkan tagihan yang ada sebesar 100% untuk setiap wilayah. Namun, ada variasi kecil dalam biaya di seluruh wilayah.

Untuk detail selengkapnya, lihat halaman harga.

Peningkatan SLA

Untuk meningkatkan ketahanan dan ketersediaan akun Azure Cosmos DB, Anda dapat menerapkan pendekatan lapisan, yang meliputi:

  • Mengaktifkan redundansi zona.
  • Menambahkan satu atau beberapa wilayah tambahan.
  • Mengaktifkan penulisan data multi-wilayah.

Pendekatan lapisan melindungi akun di setiap langkah - dari ketersediaan 4 9 untuk konfigurasi wilayah tunggal tanpa redundansi zona, melalui 4 dan setengah 9 untuk wilayah tunggal dengan redundansi zona, hingga ketersediaan 5 9 untuk konfigurasi multi-wilayah dengan opsi tulis multi-wilayah diaktifkan.

Tabel berikut berisi ringkasan SLA untuk setiap konfigurasi:

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 di beberapa wilayah dan penulisan multi-wilayah dengan atau tanpa zona ketersediaan
Menyusun SLA ketersediaan 99,99% 99.995% 99,99% 99.995% 99,999%
Baca SLA ketersediaan 99,99% 99.995% 99,999% 99,999% 99,999%
Kegagalan zona: kerugian 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 kompromi performa. Tergantung pada tingkat konsistensi. Untuk informasi selengkapnya, lihat Konsistensi, ketersediaan, dan kompromi performa. Tergantung pada tingkat konsistensi. Untuk informasi selengkapnya, lihat Konsistensi, ketersediaan, dan kompromi performa.
Pemadaman regional: ketersediaan Kehilangan ketersediaan Kehilangan ketersediaan Tidak ada kehilangan ketersediaan untuk kegagalan wilayah baca, tetapi hanya sementara untuk kegagalan wilayah tulis. Tidak ada kehilangan ketersediaan untuk kegagalan wilayah baca, tetapi hanya sementara untuk kegagalan wilayah tulis. Tidak ada kehilangan akses baca, kehilangan akses tulis sementara di wilayah yang terpengaruh
Harga (1) Tidak berlaku Tarif yang disediakan RU/s x 1.25 Wilayah RU/s x N yang disediakan RU/s yang disediakan x tarif 1.25 x N wilayah (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.

Mengonfigurasi zona ketersediaan

Membuat sumber daya dengan zona ketersediaan diaktifkan

Anda hanya dapat mengonfigurasi zona ketersediaan saat menambahkan wilayah baru ke akun Azure Cosmos DB NoSQL.

Untuk mengaktifkan dukungan zona ketersediaan, Anda dapat menggunakan:

Mengaktifkan dukungan zona ketersediaan

Untuk mempelajari cara mengaktifkan redundansi zona di akun Azure Cosmos DB Anda, lihat Memigrasikan Azure Cosmos DB untuk NoSQL ke dukungan zona ketersediaan).

Pemulihan bencana lintas wilayah dan kelangsungan bisnis

Pemulihan bencana (DR) mengacu pada praktik yang digunakan organisasi untuk pulih dari peristiwa berdampak tinggi, seperti bencana alam atau penyebaran gagal yang mengakibatkan waktu henti dan kehilangan data. Terlepas dari penyebabnya, obat terbaik untuk bencana adalah rencana DR yang terdefinisi dan teruji dengan baik dan desain aplikasi yang secara aktif mendukung DR. Sebelum Anda mulai membuat rencana pemulihan bencana, lihat rekomendasi untuk merancang strategi pemulihan bencana.

Untuk DR, Microsoft menggunakan model tanggung jawab bersama . Dalam model ini, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Namun, banyak layanan Azure tidak secara otomatis mereplikasi data atau beralih dari wilayah yang gagal untuk mereplikasi ke wilayah lain yang tersedia. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan di penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR. Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat dan membantu mengembangkan rencana DR Anda.

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

Durability

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 dikomit di wilayah tersebut. Jika wilayah memiliki zona ketersediaan yang diaktifkan, maka cadangan disimpan di akun penyimpanan dengan redundansi zona.
  • Pencadangan berkala sepenuhnya mencadangkan semua partisi dari semua wadah pada 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. Tabel berikut merinci, untuk semua level konsistensi, RPO dari akun Azure Cosmos DB yang disebarkan di setidaknya dua wilayah.

Tingkat konsistensi RPO untuk pemadaman wilayah
Sesi, prefiks yang konsisten, akhirnya Kurang dari 15 menit
Konsistensi terbatas 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.

Failover yang dikelola oleh layanan

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

Akun wilayah tunggal mungkin kehilangan aksesibilitas setelah pemadaman regional. Untuk memastikan kelangsungan bisnis setiap saat, kami sarankan Anda menyiapkan akun Azure Cosmos DB Anda dengan satu wilayah penulisan dan setidaknya wilayah kedua (pembacaan) dan mengaktifkan failover yang dikelola oleh layanan.

Failover yang dikelola oleh layanan memungkinkan Azure Cosmos DB untuk beralih ke wilayah tulis dari akun dengan beberapa wilayah, guna mempertahankan kelangsungan bisnis meskipun berisiko kehilangan data, seperti yang dijelaskan sebelumnya di bagian Durabilitas. Failover regional terdeteksi dan ditangani di klien Azure Cosmos DB. Mereka 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 penulisan dengan wilayah tunggal dan beberapa wilayah pembacaan, kami sangat menyarankan Anda mengonfigurasi akun Azure Cosmos DB yang digunakan untuk beban kerja produksi agar mengaktifkan alih-gagal 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 meningkatkan ketersediaan penulisan selama pemadaman parsial, sebaiknya mengaktifkan zona ketersediaan, selain failover yang dikelola oleh 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 penulisan.

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 di beberapa wilayah, salah satu wilayah akan bertindak sebagai arbiter dalam konflik penulisan.

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 di beberapa wilayah, aplikasi harus mengarahkan lalu lintas baca dan tulis yang berasal dari wilayah lokal, secara ketat langsung ke wilayah Cosmos DB lokal saja. 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 pembacaan atau penulisan per permintaan.

Hindari dependensi pada lag replikasi

Anda tidak dapat mengonfigurasi akun penulisan multi-wilayah untuk konsistensi kuat. Wilayah yang sedang ditulis merespons segera setelah Azure Cosmos DB mereplikasi data secara lokal sambil mereplikasi data secara asinkron ke seluruh dunia.

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

Misalnya, arsitektur tempat aplikasi menulis ke Wilayah A tetapi membaca dari Wilayah B bergantung pada lag replikasi antara kedua wilayah. Namun, jika aplikasi membaca dan menulis ke wilayah yang sama, performa tetap konstan meskipun terjadi keterlambatan 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 dengan penulisan wilayah tunggal, region penulisan selalu dijamin telah menyusul token sesi. Namun, di akun dengan kemampuan menulis di beberapa wilayah, wilayah tempat Anda menulis mungkin belum terkait dengan penulisan yang dilakukan di wilayah lain. Jika klien menulis ke Wilayah A dengan token sesi dari Wilayah B, Wilayah A tidak akan dapat menyimpan data sampai menyinkronkan dengan 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 yang dilakukan secara berurutan dan cepat pada dokumen yang sama mengalami latensi 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.

Gangguan membaca dan menulis

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 Outage Dampak ketersediaan Dampak durabilitas Apa yang harus dilakukan
Wilayah tulis tunggal Gangguan wilayah 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 oleh layanan, layanan menandai region tersebut 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.

Setelah pemadaman berakhir, sesuaikan kembali jumlah RUs yang telah diprovisikan sesuai kebutuhan.
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 oleh layanan, klien mengalami kehilangan ketersediaan tulis hingga layanan tersebut 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 pembacaan.

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

Setelah pemadaman berakhir, sesuaikan kembali jumlah RUs yang telah diprovisikan sesuai kebutuhan. Akun yang menggunakan API untuk NoSQL mungkin juga dapat memulihkan data yang tidak direplikasi dari wilayah yang gagal melalui umpan konflik Anda.
Beberapa wilayah tulis Setiap pemadaman regional Ada kemungkinan hilangnya ketersediaan tulis sementara, yang serupa dengan satu wilayah tulis dengan failover yang dikelola oleh layanan. Pengalihan fungsi wilayah resolusi konflik mungkin juga menyebabkan kehilangan akses untuk menulis jika terjadi jumlah besar penulisan yang saling bertentangan 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 menyesuaikan kembali RU yang telah disediakan sesuai kebutuhan. 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 tulisan terakhir menang.

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 akan disinkronkan dengan wilayah tulis yang saat ini aktif dan akan kembali tersedia untuk melayani permintaan baca setelah sepenuhnya menyusul.

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

  • 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 gangguan wilayah penulisan

  • Selama gangguan pada wilayah penulisan, akun Azure Cosmos DB menetapkan wilayah sekunder sebagai wilayah penulisan utama yang 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](/azure/cosmos-db/how-to-manage-database-account#perform-manual-failover-on-an-azure-cosmos-db-account. Tidak ada kehilangan data atau ketersediaan sebelum, selama, atau setelah Anda mengalihkan wilayah tulis. Aplikasi Anda terus tersedia dengan baik.

Peringatan

Jika terjadi pemadaman di wilayah tulis, di mana akun Azure Cosmos DB mempromosikan wilayah sekunder untuk menjadi wilayah tulis utama baru melalui failover yang dikelola oleh layanan, wilayah tulis asli tidak akan secara otomatis dipromosikan kembali sebagai wilayah tulis 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).

Deteksi, pemberitahuan, dan manajemen gangguan

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 dikelola oleh layanan Apa yang bisa diharapkan 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 tersisa kurang dari dua wilayah baca.

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 pembacaan.

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

Setelah pemadaman berakhir, sesuaikan kembali jumlah RUs yang telah diprovisikan sesuai kebutuhan.
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 ketika kurang dari dua wilayah baca yang tersisa.

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 pembacaan.

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

Ketika pemadaman berakhir, Anda dapat memindahkan kembali wilayah tulis ke wilayah asli dan menyesuaikan kembali RUs yang telah disediakan sesuai kebutuhan. 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 menyesuaikan kembali RU yang telah disediakan sesuai kebutuhan. 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 pemenang penulisan terakhir.

Pengujian untuk ketersediaan tinggi

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), sementara waktu nonaktifkan failover yang dikelola oleh layanan untuk akun tersebut. 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.

Konten terkait

  • Last updated on