Keandalan di Azure DocumentDB

Azure DocumentDB adalah layanan database NoSQL yang dikelola sepenuhnya untuk pengembangan aplikasi modern dengan kompatibilitas MongoDB. Azure DocumentDB mendukung konfigurasi ketersediaan tinggi (HA) dengan replika hot-standby yang direplikasi secara sinkron serta redundansi zona. Layanan ini juga menyediakan replika baca opsional di wilayah Azure lainnya serta pencadangan otomatis dengan retensi pemulihan ke titik waktu tertentu untuk melindungi dari kehilangan data yang tidak disengaja.

Saat Anda menggunakan Azure, keandalan adalah tanggung jawab bersama. Microsoft menyediakan berbagai kemampuan untuk mendukung ketahanan dan pemulihan. Anda bertanggung jawab untuk memahami cara kerja kemampuan tersebut dalam semua layanan yang Anda gunakan, dan memilih kemampuan yang Anda butuhkan untuk memenuhi tujuan bisnis dan tujuan waktu aktif Anda.

Artikel ini menjelaskan cara membuat Azure DocumentDB tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Ini juga menjelaskan perilaku pencadangan dan memberikan informasi utama tentang HA dan replikasi lintas wilayah.

Rekomendasi implementasi produksi untuk keandalan

Untuk daftar rekomendasi untuk meningkatkan keandalan kluster Anda, lihat Praktik terbaik untuk ketersediaan tinggi (HA) dan replikasi lintas wilayah di Azure DocumentDB.

Gambaran umum arsitektur keandalan

Bagian ini menjelaskan beberapa aspek penting tentang cara kerja layanan yang paling relevan dari perspektif keandalan. Bagian ini memperkenalkan arsitektur logis, yang mencakup beberapa sumber daya dan fitur yang Anda sebarkan dan gunakan. Ini juga membahas arsitektur fisik, yang memberikan detail tentang cara kerja layanan di bawah sampul.

Arsitektur logika

Sumber daya utama yang Anda sebarkan adalah kluster DocumentDB Azure. Untuk setiap kluster, Anda memilih tingkat komputasi dan mengonfigurasi penyimpanan. Tingkat yang Anda pilih menentukan kemampuan yang tersedia untuk fitur keandalan seperti ketersediaan tinggi (HA), dan juga memengaruhi cara Anda merencanakan kapasitas untuk skenario ketahanan.

Aplikasi terhubung ke kluster dengan menggunakan string koneksi dan titik akhir. Azure DocumentDB menyediakan titik akhir koneksi untuk operasi baca-tulis dan, saat dikonfigurasi, titik akhir untuk kluster replika baca. Titik akhir ini memungkinkan aplikasi Anda terus menggunakan pola koneksi yang stabil saat layanan mengelola perilaku failover di belakang layar.

Dalam setiap kluster, data Anda diatur sebagai database, koleksi, dan dokumen. Model data yang kompatibel dengan MongoDB ini adalah dasar untuk keputusan desain tingkat beban kerja seperti strategi sharding, pola baca dan tulis, serta cakupan pencadangan dan pemulihan.

Arsitektur fisik

Azure DocumentDB menjalankan kluster Anda di atas shards, yang merupakan simpul (komputer virtual) yang menjalankan layanan. Anda dapat menyebarkan satu shard atau meluaskan skala ke beberapa pecahan. Menyebarkan beberapa pecahan meningkatkan kapasitas skala, tetapi dengan sendirinya tidak menyediakan KETERSEDIAAN TINGGI.

Saat Anda mengaktifkan HA, Azure DocumentDB menyediakan sekumpulan shard siaga yang sesuai. Setiap pecahan utama memiliki pecahan siaga. Layanan mereplikasi data secara sinkron antara setiap pasangan primer-siaga dan menaikkan shard siaga jika shard primer gagal. Untuk informasi selengkapnya tentang HA, lihat Ketersediaan tinggi di Azure DocumentDB.

Azure DocumentDB menggunakan Azure Storage untuk durabilitas shard. Jika HA dinonaktifkan, setiap shard menggunakan penyimpanan redundan lokal (LRS). LRS mempertahankan tiga salinan data, tetapi tidak tahan terhadap hilangnya zona ketersediaan. Untuk detail durabilitas LRS, lihat Ringkasan opsi redundansi.

Untuk informasi selengkapnya, lihat Ketersediaan dan pemulihan bencana (DR) di Azure DocumentDB: Di balik layar.

Ketahanan terhadap kesalahan sementara

Kesalahan sementara adalah kegagalan yang bersifat sementara dan intermiten dalam komponen. Mereka sering terjadi di lingkungan terdistribusi seperti cloud, dan mereka adalah bagian normal dari operasi. Kesalahan sementara memperbaiki diri setelah waktu yang singkat. Penting bahwa aplikasi Anda dapat menangani kesalahan sementara, biasanya dengan mencoba kembali permintaan yang terpengaruh.

Semua aplikasi yang dihosting cloud harus mengikuti panduan penanganan kesalahan sementara Azure saat berkomunikasi dengan API, database, dan komponen lain yang dihosting cloud. Untuk informasi selengkapnya, lihat Rekomendasi untuk menangani kesalahan sementara.

Azure DocumentDB kompatibel dengan protokol MongoDB, sehingga aplikasi biasanya terhubung dengan menggunakan driver MongoDB. Anda bertanggung jawab untuk mengonfigurasi pengaturan coba lagi driver aplikasi Anda untuk menangani kegagalan sementara, terutama gangguan koneksi dan gangguan penulisan singkat selama peristiwa failover. Ikuti panduan berikut:

  • Gunakan driver MongoDB yang mendukung penanganan coba lagi otomatis untuk kegagalan konektivitas sementara.

  • Konfigurasikan percobaan ulang dengan backoff eksponensial, dan batasi jumlah upaya coba lagi.

  • Jika memungkinkan, rancang operasi penulisan agar bersifat idempoten sehingga aman untuk dicoba ulang. Untuk panduan implementasi umum tentang idempotensi, lihat pola Konsumen Idempotent.

Ketahanan terhadap kegagalan 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.

Untuk menggunakan dukungan zona ketersediaan di Azure DocumentDB, aktifkan ketersediaan tinggi (HA). Saat Anda mengaktifkan HA di wilayah yang mendukung zona ketersediaan, kluster Anda menjadi redundan lintas zona karena Azure DocumentDB menempatkan shard siaga di zona ketersediaan yang berbeda dari shard primernya. Shard siaga tidak menerima permintaan klien kecuali shard utamanya mengalami kegagalan.

Jika Anda menonaktifkan HA, Azure DocumentDB tidak menempatkan shard siaga di zona ketersediaan lain, sehingga kegagalan pada zona ketersediaan dapat membuat kluster Anda tidak tersedia.

Diagram kluster Azure DocumentDB yang tahan zona dengan shard primer dan siaga di zona ketersediaan yang berbeda.

Requirements

  • Dukungan wilayah: Untuk menggunakan zona ketersediaan dengan Azure DocumentDB, pilih wilayah yang mendukung Azure DocumentDB dan zona ketersediaan. Periksa Produk yang tersedia menurut wilayah dan bandingkan dengan wilayah yang mendukung zona ketersediaan.

  • Ketersediaan tinggi: Anda harus mengaktifkan HA pada kluster. HA mengharuskan kluster untuk menggunakan tingkat komputasi M30 (atau lebih besar).

Considerations

Meskipun beberapa AZURE DOCUMENTDB API menyertakan referensi ke mode penyebaran zona yang sama, Azure DocumentDB tidak mendukung penyebaran HA zona yang sama. Layanan ini mendukung penerapan HA redundan zona.

Distribusi instans di seluruh zona

Microsoft memilih dua zona ketersediaan untuk kluster. Dalam penerapan ketersediaan tinggi (HA) dengan redundansi zona, Azure DocumentDB menempatkan semua shard primer di satu zona dan semua shard siaga di zona lainnya.

Cost

Saat HA diaktifkan, Azure DocumentDB menyiapkan shard siaga untuk setiap shard primer, sehingga meningkatkan biaya komputasi dan penyimpanan kluster Anda. Di wilayah yang mendukung zona ketersediaan, HA juga membuat kluster menjadi redundan lintas zona. Dalam beberapa mode penyebaran, Azure DocumentDB mengaktifkan HA secara default. Untuk beban kerja produksi, biarkan HA tetap diaktifkan. Untuk beban kerja pengembangan dan pengujian, Anda dapat menonaktifkan HA untuk mengurangi biaya. Untuk rincian harga, lihat harga Azure DocumentDB.

Mengonfigurasi dukungan zona ketersediaan

  • Buat kluster Azure DocumentDB redundan zona yang baru: Saat Anda membuat kluster di wilayah yang mendukung zona ketersediaan, aktifkan HA agar kluster menjadi redundan zona. Untuk langkah-langkah mendetail, lihat Mulai Cepat: Membuat kluster Azure DocumentDB dengan menggunakan portal Azure.

  • Aktifkan redundansi zona pada kluster Azure DocumentDB yang sudah ada: Anda dapat mengaktifkan HA pada kluster yang sudah ada. Tidak ada waktu henti database saat ketersediaan tinggi diaktifkan atau dinonaktifkan pada kluster Azure DocumentDB. Untuk langkah-langkah mendetail, lihat Menskalakan kluster DocumentDB Azure.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan hal-hal yang dapat Anda harapkan saat mengonfigurasi kluster Azure DocumentDB untuk ketersediaan tinggi (HA) di wilayah yang mendukung zona ketersediaan, dan seluruh zona beroperasi secara normal.

  • Operasi lintas zona: Pecahan utama melayani semua permintaan klien. Shard siaga di zona ketersediaan yang berbeda hanya menerima permintaan klien jika shard utama mengalami kegagalan.

  • Replikasi data lintas zona: Replikasi antara shard utama dan shard siaga berlangsung secara sinkron. Operasi penulisan disimpan secara persisten pada shard primer dan shard siaga sebelum layanan mengembalikan respons.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang dapat Anda harapkan saat mengonfigurasi kluster Azure DocumentDB untuk HA di wilayah yang mendukung zona ketersediaan, dan salah satu zonanya mengalami gangguan.

  • Deteksi dan respons: Microsoft memantau kesehatan pecahan dan menangani operasi deteksi dan failover untuk Anda. Jika shard utama menjadi tidak tersedia karena gangguan zona, Azure DocumentDB secara otomatis mempromosikan shard siaga, lalu memulihkan redundansi dengan membuat shard siaga baru.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Permintaan dalam penerbangan yang tidak diakui sebelum failover dapat gagal dan harus dicoba kembali oleh klien. Jika aplikasi Anda menangani kesalahan sementara, percobaan ulang ini biasanya selesai secara otomatis.

  • Kehilangan data yang diharapkan: Azure DocumentDB mereplikasi data secara sinkron antara pecahan utama dan siaga, sehingga tidak ada kehilangan data yang diharapkan.

  • Waktu henti yang diharapkan: Tidak ada waktu henti yang diharapkan untuk operasi baca. Untuk operasi tulis, gangguan singkat dapat terjadi saat failover selesai. Jika aplikasi Anda mencoba kembali kesalahan sementara dengan benar, ini biasanya muncul sebagai perlambatan singkat.

  • Redistribusi: String koneksi tidak berubah, sehingga klien tetap menggunakan endpoint yang sama. Layanan ini secara otomatis mengalihkan lalu lintas ke shard siaga yang telah dipromosikan dan membuat ulang shard siaga baru.

Pemulihan Zona

Saat zona ketersediaan pulih, Azure DocumentDB secara otomatis memulihkan operasi normal di semua zona yang digunakan oleh kluster.

Uji kegagalan zona

Platform Azure DocumentDB mengelola perutean lalu lintas, failover, dan pemulihan zona untuk kluster zona-redundan. Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

Ketahanan terhadap kegagalan di seluruh wilayah

Anda menyebarkan setiap Azure kluster DocumentDB dalam satu wilayah Azure. Untuk mendukung ketahanan terhadap kegagalan wilayah, konfigurasikan replikasi lintas wilayah dengan menambahkan satu kluster replika di wilayah lain.

Replikasi lintas wilayah

Azure DocumentDB mendukung replikasi lintas wilayah melalui kluster replika. Kluster replika muncul sebagai kluster terpisah di grup sumber daya Anda. Anda dapat menggunakan kluster replika ini untuk pemulihan bencana dan membaca penskalaan. Azure DocumentDB secara otomatis dan asinkron mereplikasi perubahan data dari kluster utama ke kluster replika.

Diagram replikasi asinkron dari kluster Azure DocumentDB utama ke kluster replika baca di wilayah lain.

Jika wilayah utama Anda gagal, kluster replika dapat dipromosikan untuk menjadi kluster baca-tulis. String koneksi baca-tulis global akan diperbarui secara otomatis agar mengarah ke kluster yang dipromosikan.

Diagram replika Azure DocumentDB yang telah dipromosikan untuk menangani lalu lintas setelah region utama mengalami kegagalan.

Bagian ini meringkas pertimbangan keandalan untuk replikasi lintas wilayah. Untuk informasi selengkapnya, lihat Mengelola replikasi lintas wilayah dan wilayah yang sama pada kluster Azure DocumentDB DanPraktik terbaik replikasi lintas wilayah dan wilayah yang sama di Azure DocumentDB.

Failover antar wilayah

Azure DocumentDB mendukung tiga mode promosi:

  • Promosi paksa: Segera mempromosikan kluster replika agar menerima operasi tulis dan mengalihkan lalu lintas tulis masuk melalui string koneksi global baca-tulis. Mode ini meminimalkan waktu henti, tetapi dapat mengakibatkan kehilangan data karena setiap operasi tulis yang belum direplikasi dapat hilang.

  • Failover yang dikelola layanan: Anda dapat mengonfigurasi kluster untuk menggunakan failover yang dikelola layanan. Microsoft memantau kluster utama Anda dan secara otomatis memicu promosi paksa jika kluster utama tidak sehat.

  • Promosi yang anggun: Mencegah kehilangan data tetapi memerlukan beberapa waktu henti saat penulisan yang tidak direplikasi direplikasi. Promosi yang anggun mengharuskan kedua kluster menjadi sehat, sehingga Anda tidak dapat melakukannya selama pemadaman wilayah.

Untuk informasi selengkapnya, lihat Mode failover lintas wilayah di Azure DocumentDB.

Requirements

  • Dukungan wilayah: Anda dapat menggunakan replikasi lintas wilayah di semua wilayah Azure yang mendukung Azure DocumentDB.

  • Tingkat komputasi: Replikasi lintas wilayah memerlukan tingkat komputasi M30 atau yang lebih tinggi.

Considerations

  • Akses jaringan: Kluster replika tidak mewarisi pengaturan jaringan dari kluster utama. Konfigurasikan aturan firewall atau titik akhir privat secara terpisah pada kluster replika, dan uji konektivitas sebelum failover. Untuk informasi selengkapnya, lihat Penulisan berkelanjutan, operasi baca pada replika kluster, dan string koneksi.

  • Dukungan fitur: Kluster replika tidak mendukung pemulihan ke titik waktu tertentu (PITR) atau HA dalam wilayah yang sama.

    Jika HA diaktifkan pada kluster utama, Anda bertanggung jawab untuk mengaktifkan kembali HA pada kluster yang dipromosikan.

    Untuk informasi selengkapnya, lihat Azure batas dan kuota layanan DocumentDB.

Cost

Replikasi lintas wilayah menambahkan biaya untuk sumber daya komputasi dan penyimpanan kluster replika. Biaya transfer data lintas wilayah juga berlaku. Untuk rincian harga, lihat harga Azure DocumentDB dan harga bandwidth.

Konfigurasikan dukungan multiregion

  • Buat kluster replika: Untuk mengaktifkan replikasi lintas wilayah, buat kluster replika dari kluster utama Anda. Anda dapat membuat kluster replika saat membuat kluster utama atau setelahnya. Untuk langkah-langkahnya, lihat Mengelola replikasi lintas wilayah dan wilayah yang sama pada kluster DocumentDB Azure Anda.

  • Mengonfigurasi failover otomatis: Jika Anda ingin Azure secara otomatis mempromosikan replika selama pemadaman wilayah utama, aktifkan failover yang dikelola layanan. Untuk informasi selengkapnya, lihat Mengaktifkan failover yang dikelola layanan.

    Note

    Microsoft biasanya memicu failover yang dikelola layanan hanya dalam peristiwa ekstrem, seperti pemadaman seluruh wilayah atau sejumlah besar pelanggan yang terpengaruh. Mungkin ada penundaan sebelum failover dipicu. Jika Anda perlu memulihkan ketersediaan dengan cepat, kami sarankan Anda mengelola proses failover dengan menggunakan promosi paksa yang dimulai pelanggan.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi kluster Azure DocumentDB untuk replikasi lintas wilayah dan semua wilayah beroperasi.

  • Operasi lintas wilayah: Kluster utama melayani semua lalu lintas baca-tulis. Kluster replika melayani lalu lintas baca-saja, yang dapat Anda gunakan untuk meluaskan skala beban kerja baca atau untuk menjaga lalu lintas baca tetap lokal ke wilayah tertentu. String koneksi baca-tulis global selalu mengarah ke kluster yang saat ini dapat ditulisi, sehingga klien tidak perlu melacak region mana yang utama.

  • Replikasi data lintas wilayah: Replikasi antara kluster utama dan kluster replika tidak sinkron. Penulisan dilakukan pada kluster utama dan diakui kepada klien sebelum direplikasi ke kluster replika. Pendekatan ini mencegah latensi jaringan lintas wilayah memengaruhi performa tulis. Karena replikasi bersifat asinkron, diperkirakan akan terjadi jeda replikasi antara kluster primer dan kluster replika, dan setiap data yang ditulis tetapi belum direplikasi dapat hilang saat failover paksa.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi kluster Azure DocumentDB untuk replikasi lintas wilayah dan ada pemadaman di wilayah kluster utama.

  • Deteksi dan respons: Tanggung jawab untuk mendeteksi pemadaman dan merespons tergantung pada jenis failover yang digunakan kluster Anda.

    • Jika failover yang dikelola layanan diaktifkan, Azure DocumentDB mendeteksi pemadaman dan secara otomatis melakukan promosi paksa kluster replika.
    • Jika failover yang dikelola oleh layanan tidak diaktifkan, Anda bertanggung jawab untuk mendeteksi gangguan dan memicu promosi paksa.

    Untuk informasi selengkapnya, lihat Mode failover lintas wilayah di Azure DocumentDB.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun, Anda dapat menggunakan Azure Service Health untuk memahami kesehatan layanan secara keseluruhan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Setiap permintaan aktif ke wilayah utama yang gagal mungkin gagal. Setelah failover selesai, aplikasi harus terhubung kembali dan mencoba kembali terhadap kluster yang dipromosikan.

  • Perkiraan kehilangan data: Failover selama kegagalan regional terjadi tanpa direncanakan, sehingga operasi tulis yang belum direplikasi dapat hilang karena replikasi bersifat asinkron.

  • Waktu henti yang diharapkan: Waktu henti keseluruhan tergantung pada waktu deteksi, mode failover, dan perilaku koneksi ulang klien.

    Untuk promosi paksa yang dipicu oleh pelanggan, total waktu henti mencakup waktu yang diperlukan untuk mendeteksi gangguan dan memulai proses respons Anda, serta waktu untuk menyelesaikan promosi.

    Setelah promosi dimulai, biasanya selesai dalam beberapa menit.

  • Pendistribusian ulang: String koneksi baca-tulis global secara otomatis mengarah ke kluster yang dipromosikan setelah proses promosi. Aplikasi yang menggunakan string koneksi khusus kluster mungkin memerlukan pembaruan konfigurasi sehingga mengarahkan lalu lintas ke kluster yang sehat.

Pemulihan wilayah

Azure DocumentDB tidak secara otomatis beralih kembali ke wilayah awal setelah pulih. Untuk mengembalikan operasi tulis ke wilayah asal, lakukan promosi lagi setelah Anda menetapkan kembali topologi pilihan Anda. Gunakan promosi bertahap untuk mencegah kehilangan data selama failback. Proses promosi yang mulus memerlukan sedikit waktu henti, dan Anda dapat melakukannya pada waktu yang Anda tentukan, misalnya saat jendela pemeliharaan. Untuk informasi selengkapnya, lihat Memicu promosi yang anggun.

Pengujian untuk mendeteksi kegagalan wilayah

Uji proses pemulihan bencana Anda secara teratur dengan mempromosikan kluster replika di lingkungan yang terkontrol.

  • Gunakan promosi paksa untuk mensimulasikan perilaku saat terjadi gangguan. Pengujian ini dapat mengakibatkan kehilangan data, jadi pertimbangkan untuk menjalankan pengujian ini di lingkungan nonproduksi. Untuk informasi selengkapnya, lihat Menjalankan promosi secara paksa.

  • Gunakan graceful promotion untuk simulasi switchover terencana saat Anda ingin menghindari kehilangan data. Untuk informasi selengkapnya, lihat Memicu promosi yang anggun.

Pencadangan dan pemulihan

Replikasi dan dukungan untuk zona ketersediaan membantu menjaga kluster tetap tersedia selama kegagalan infrastruktur. Azure DocumentDB secara otomatis mengambil cadangan berkelanjutan, yang mengatasi risiko yang berbeda dengan mengaktifkan pemulihan titik waktu (PITR) setelah Anda secara tidak sengaja menghapus atau memodifikasi data. Azure DocumentDB mengambil cadangan tanpa memengaruhi performa atau ketersediaan operasi database. Untuk informasi selengkapnya tentang bagaimana replikasi dan pencadangan mengatasi risiko yang berbeda, lihat Redundansi, replikasi, dan pencadangan.

Azure DocumentDB menyimpan cadangan secara terpisah dari data sumber. Di wilayah yang mendukung zona ketersediaan, layanan menyimpan rekam jepret cadangan di tiga zona ketersediaan. Azure DocumentDB mengelola cadangan ini, dan Anda tidak dapat mengekspornya. Layanan ini mempertahankan cadangan selama 35 hari untuk kluster aktif, 7 hari untuk kluster tingkat aktif burstable (M10, M20, M25), dan 7 hari untuk kluster yang dihapus.

Anda dapat memulihkan cadangan ke kluster baru. Setelah melakukannya, Anda perlu melakukan serangkaian tugas pasca-pemulihan.

Untuk informasi selengkapnya, lihat Memulihkan kluster di Azure DocumentDB.

Ketahanan terhadap pemeliharaan layanan

Microsoft secara teratur menerapkan pembaruan layanan dan melakukan pemeliharaan lainnya. Platform Azure menangani aktivitas ini secara otomatis, memastikan bahwa pemeliharaan mulus dan transparan bagi Anda. Tidak ada downtime yang diharapkan selama peristiwa pemeliharaan kecuali Anda menerima pemberitahuan tentang pemeliharaan terencana melalui Azure Service Health.

Peristiwa pemeliharaan terencana masih dapat menyebabkan kegagalan sementara singkat untuk operasi klien. Aplikasi Anda harus menangani peristiwa ini dengan menggunakan panduan coba lagi dalam Ketahanan terhadap kesalahan sementara.

Perjanjian tingkat layanan

Perjanjian tingkat layanan (SLA) untuk layanan Azure menjelaskan ketersediaan yang diharapkan dari setiap layanan dan kondisi yang harus dipenuhi solusi Anda untuk mencapai harapan ketersediaan tersebut. Untuk informasi selengkapnya, lihat SLA untuk layanan online.

Untuk Azure DocumentDB, ketersediaan SLA hanya berlaku saat kluster Anda mengaktifkan ketersediaan tinggi (HA). SLA ketersediaan yang berbeda berlaku untuk konfigurasi berikut:

  • Kluster berkemampuan HA yang mencakup beberapa wilayah Azure dengan menggunakan replikasi lintas wilayah.

  • Kluster yang diaktifkan HA dalam satu wilayah.

Konten terkait

  • Terakhir diperbarui pada