Ketersediaan tinggi (Keandalan) di Azure Cosmos DB untuk NoSQL
Artikel ini menjelaskan dukungan ketersediaan tinggi (keandalan) di Azure CosmosDB for NoSQL dan mencakup zona ketersediaan, serta pemulihan bencana lintas wilayah dan kelangsungan bisnis.
Untuk rekomendasi ketahanan umum untuk Azure Cosmos DB untuk NoSQL, lihat Rekomendasi ketahanan untuk Azure Cosmos DB untuk NoSQL.
Dukungan zona ketersediaan
Zona ketersediaan Azure adalah setidaknya tiga grup pusat data yang terpisah secara fisik dalam setiap wilayah Azure. Pusat data dalam setiap zona dilengkapi dengan infrastruktur daya, pendinginan, dan jaringan independen. Dalam kasus kegagalan zona lokal, zona ketersediaan dirancang sehingga jika satu zona terpengaruh, layanan regional, kapasitas, dan ketersediaan tinggi didukung oleh dua zona yang tersisa.
Kegagalan dapat berkisar dari kegagalan perangkat lunak dan perangkat keras hingga peristiwa seperti gempa bumi, banjir, dan kebakaran. Toleransi terhadap kegagalan dicapai dengan redundansi dan isolasi logis layanan Azure. Untuk informasi selengkapnya tentang zona ketersediaan di Azure, lihat Wilayah dan zona ketersediaan.
Layanan berkemampuan zona ketersediaan Azure dirancang untuk memberikan tingkat keandalan dan fleksibilitas yang tepat. Mereka dapat dikonfigurasi dalam dua cara. Mereka dapat berupa zona redundan,dengan replikasi otomatis di seluruh zona, atau zonal, dengan instans yang disematkan ke zona tertentu. Anda juga dapat menggabungkan pendekatan ini. Untuk informasi selengkapnya tentang arsitektur zonal vs. zona-redundan, lihat Rekomendasi untuk menggunakan zona dan wilayah ketersediaan.
Azure Cosmos DB adalah layanan multipenyewa yang mengelola semua detail simpul komputasi individual secara transparan. Anda 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.
Azure Cosmos DB menawarkan:
Ketahanan pemadaman simpul individu. 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.
Ketahanan pemadaman zona. Saat Anda menyebarkan akun Azure Cosmos DB dengan menggunakan zona ketersediaan, Azure Cosmos DB menyediakan RTO 0 dan RPO 0, bahkan dalam pemadaman zona. Untuk informasi tentang RTO, lihat Tujuan pemulihan.
Dengan zona ketersediaan diaktifkan, Azure Cosmos DB for NoSQL mendukung konfigurasi zona-redundan .
Prasyarat
Replika Anda harus disebarkan di wilayah Azure yang mendukung zona ketersediaan. Untuk melihat apakah wilayah Anda mendukung zona ketersediaan, lihat daftar wilayah yang didukung.
Tentukan apakah zona ketersediaan menambahkan nilai yang cukup ke konfigurasi Anda saat ini dalam Dampak penggunaan zona ketersediaan.
Dampak penggunaan zona ketersediaan
Dampak zona ketersediaan pada ketersediaan tinggi database Cosmos DB for NoSQL Anda tergantung pada tingkat konsistensi akun dan wilayah mana yang mengaktifkan zona ketersediaan. Dalam banyak kasus, zona ketersediaan tidak menambahkan nilai atau menambahkan nilai minimal jika akun tersebut multi-wilayah (kecuali dikonfigurasi dengan konsistensi yang kuat).
Lihat tabel di bawah ini untuk memperkirakan dampak penggunaan zona ketersediaan dalam konfigurasi akun Anda saat ini:
| Tingkat konsistensi akun | Wilayah dengan zona ketersediaan diaktifkan | Dampak penggunaan zona ketersediaan |
|---|---|---|
| Asinkron (Keusangan Terikat atau lebih lemah) | Sejumlah wilayah baca sekunder. | Memberikan nilai minimal karena SDK sudah menyediakan pengalihan yang mulus untuk pembacaan saat wilayah baca gagal. |
| Sinkron (Kuat) | Dua atau beberapa wilayah baca sekunder | Memberikan nilai marginal karena sistem dapat memanfaatkan kuorum dinamis jika wilayah baca kehilangan ketersediaan yang memungkinkan penulisan berlanjut. |
| Sinkron (Kuat) | Satu wilayah baca sekunder | Memberikan nilai yang lebih besar karena hilangnya wilayah baca dalam skenario ini dapat memengaruhi ketersediaan tulis. |
| Semua | Menulis wilayah dan sejumlah wilayah sekunder | Memastikan ketersediaan yang lebih besar untuk operasi tulis untuk kegagalan zona. |
| Semua | Wilayah tunggal | Wilayah tunggal tidak dapat memperoleh manfaat dari kemampuan failover multi-wilayah. Menggunakan zona ketersediaan melindungi dari total kehilangan ketersediaan karena kegagalan zonal. |
Peningkatan SLA
Karena zona ketersediaan secara fisik terpisah dan menyediakan sumber daya, jaringan, dan pendinginan yang berbeda, SLA Ketersediaan (Perjanjian tingkat layanan) lebih tinggi (99,995%) daripada akun dengan satu wilayah (99,99%). Wilayah tempat zona ketersediaan diaktifkan dikenakan biaya premium 25%, sementara yang tanpa zona ketersediaan tidak dikenakan premi. Selain itu, harga premium untuk zona ketersediaan dilenyapkan untuk akun yang dikonfigurasi dengan penulisan multi-wilayah dan/atau untuk koleksi yang dikonfigurasi dengan mode skala otomatis.
Menambahkan wilayah tambahan ke akun Cosmos DB biasanya meningkatkan tagihan yang ada sebesar 100% (secara aditif tidak berlipat ganda) meskipun ada variasi kecil dalam biaya di seluruh wilayah. Untuk detail selengkapnya, lihat halaman harga.
Mengaktifkan AZ, menambahkan wilayah tambahan, atau mengaktifkan penulisan multi-wilayah dapat dianggap sebagai pendekatan lapisan yang meningkatkan ketahanan dan ketersediaan akun Cosmos DB tertentu di setiap langkah - dari ketersediaan 4 9 untuk konfigurasi no-AZ wilayah tunggal, hingga 4 dan setengah 9 untuk wilayah tunggal dengan AZ, hingga ketersediaan 5 9 untuk konfigurasi multi-wilayah dengan opsi tulis multi-wilayah diaktifkan. Silakan lihat tabel berikut untuk 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 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.
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:
Dukungan bermigrasi ke zona ketersediaan
Untuk mempelajari cara memigrasikan akun Cosmos DB Anda ke dukungan zona ketersediaan, lihat Memigrasikan Azure Cosmos DB untuk NoSQL ke dukungan zona ketersediaan).
Pemulihan bencana lintas wilayah dan kelangsungan bisnis
Pemulihan bencana (DR) adalah tentang pemulihan 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 berpikir tentang membuat rencana pemulihan bencana Anda, lihat Rekomendasi untuk merancang strategi pemulihan bencana.
Ketika datang ke DR, Microsoft menggunakan model tanggung jawab bersama. Dalam model tanggung jawab bersama, Microsoft memastikan bahwa infrastruktur dasar dan layanan platform tersedia. Pada saat yang sama, banyak layanan Azure tidak secara otomatis mereplikasi data atau mundur dari wilayah yang gagal untuk mereplikasi silang ke wilayah lain yang diaktifkan. Untuk layanan tersebut, Anda bertanggung jawab untuk menyiapkan rencana pemulihan bencana yang berfungsi untuk beban kerja Anda. Sebagian besar layanan yang berjalan pada penawaran platform as a service (PaaS) Azure menyediakan fitur dan panduan untuk mendukung DR dan Anda dapat menggunakan fitur khusus layanan untuk mendukung pemulihan cepat untuk membantu mengembangkan rencana DR Anda.
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. Jika wilayah mengaktifkan zona ketersediaan, maka cadangan disimpan di akun penyimpanan zona-redundan.
- 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.
Failover yang dikelola 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 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 kelangsungan bisnis 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.
Membaca dan menulis pemadaman
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](.. . /cosmos-db/how-to-manage-database-account.yml#perform-manual-failover-on-an-azure-cosmos-db-account. 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).
Deteksi, pemberitahuan, dan manajemen pemadaman
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. |
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), 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.