Keandalan dalam Azure Cosmos DB

Azure Cosmos DB untuk NoSQL adalah layanan database multi-model yang didistribusikan secara global yang mendukung model data dokumen dengan skema fleksibel. Azure Cosmos DB menawarkan fitur keandalan komprehensif termasuk beberapa tingkat konsistensi yang memungkinkan Anda menyeimbangkan performa dan ketersediaan, penyebaran zona redundan yang melindungi dari kegagalan zona ketersediaan, replikasi multi-wilayah dengan failover yang dikelola layanan atau dikelola pelanggan, dan opsi pencadangan berkelanjutan dan berkala untuk perlindungan data.

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 Cosmos DB tahan terhadap berbagai potensi pemadaman dan masalah, termasuk kesalahan sementara, pemadaman zona ketersediaan, pemadaman wilayah, dan pemeliharaan layanan. Ini juga menjelaskan cara menggunakan cadangan untuk memulihkan dari jenis masalah lain dan menyoroti informasi utama tentang perjanjian tingkat layanan (SLA) Azure Cosmos DB.

Rekomendasi penyebaran produksi

Azure Well-Architected Framework memberikan rekomendasi dalam hal reliabilitas, keamanan, biaya, operasi, dan performa. Untuk memahami bagaimana area ini saling memengaruhi dan berkontribusi pada solusi Azure Cosmos DB yang andal, lihat praktik terbaik Arsitektur untuk Azure Cosmos DB.

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 Azure Cosmos DB account. Setiap akun dapat memiliki beberapa database dengan beberapa kontainer. Kontainer berfungsi sebagai unit logis distribusi dan skalabilitas. Anda dapat membuat kontainer seperti koleksi, tabel, dan grafik, tergantung pada API yang Anda gunakan untuk berinteraksi dengan Azure Cosmos DB. Untuk informasi selengkapnya tentang model sumber daya, lihat Databases, kontainer, dan item di Azure Cosmos DB. Setiap kontainer menggunakan partisi, yang mendukung skala tinggi dan performa tinggi.

Anda mengonfigurasi throughput, yang mewakili jumlah sumber daya sistem yang bisa Anda gunakan untuk mengkueri dan bekerja dengan data Anda. Anda dapat memprovisikan throughput secara manual, menggunakan skala otomatis untuk menyesuaikan kapasitas secara dinamis berdasarkan persyaratan beban kerja Anda, atau menggunakan jenis akun tanpa server yang akan dikenakan biaya untuk penggunaan aktual Anda.

Satu akun dapat mencakup beberapa wilayah Azure, yang meningkatkan ketahanan terhadap kegagalan wilayah. Anda dapat mengonfigurasi beberapa wilayah untuk membaca, dan jika Anda menggunakan tingkat Bisnis Penting, Anda dapat menggunakan beberapa wilayah untuk menulis. Azure Cosmos DB mereplikasi data Anda secara geografis secara otomatis. Perilaku replikasi geografis dipengaruhi oleh konfigurasi yang Anda gunakan, seperti tingkat konsistensi, yang menunjukkan bagaimana Anda ingin melakukan tradeoff antara konsistensi data, ketersediaan, latensi, dan throughput. Tingkat konsistensi yang berbeda mengoptimalkan kekhawatiran yang berbeda, mendukung jaminan yang berbeda, dan memberikan berbagai jenis replikasi lintas wilayah.

Arsitektur fisik

Azure Cosmos DB menyimpan beberapa replika data Anda untuk redundansi. Layanan ini secara otomatis mengurangi pemadaman replika dengan mempertahankan kuorum di seluruh replika di setiap wilayah. Pendekatan ini menjamin ketersediaan tinggi dan melindungi dari kehilangan data selama kegagalan node individual, tanpa memerlukan perubahan atau konfigurasi aplikasi.

Secara internal, Azure Cosmos DB mengelola data Anda melalui berbagai konstruksi termasuk partisi fisik, set partisi, dan set replika. Untuk informasi selengkapnya tentang cara kerja Azure Cosmos DB, lihat Distribusi Data Global dengan Azure Cosmos DB - secara mendalam.

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.

Kami sarankan Anda menggunakan SDK Azure Cosmos DB. SDK secara otomatis menerapkan dukungan untuk berbagai pertimbangan ketahanan, termasuk penanganan kesalahan sementara melalui percobaan ulang otomatis, dan menghormati respons batas tarif yang dikirim oleh layanan. Untuk informasi selengkapnya, lihat Design resilient applications with Azure Cosmos DB SDKs.

Saat bekerja dengan akun multiregion, SDK juga mendukung strategi ketersediaan berbasis ambang batas, juga disebut hedging, di mana SDK mengirimkan permintaan baca paralel ke beberapa wilayah dan menerima respons tercepat. Pendekatan ini dapat meningkatkan performa aplikasi ketika suatu wilayah untuk sementara mengalami latensi yang lebih tinggi dari biasanya.

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.

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. Microsoft memilih zona ketersediaan yang akan digunakan.

Diagram memperlihatkan akun Azure Cosmos DB dengan set replika yang berisi tiga replika, yang didistribusikan di tiga zona ketersediaan terpisah.

Akun Azure Cosmos DB mungkin menggunakan beberapa wilayah (lokasi) untuk distribusi, skala, dan failover global. Anda mengonfigurasi redundansi zona secara terpisah untuk setiap wilayah di akun Anda.

Menggunakan redundansi zona di Azure Cosmos DB tidak memiliki dampak yang jelas pada performa atau latensi. Ini tidak memerlukan penyesuaian apa pun pada mode konsistensi yang dipilih, dan tidak memerlukan modifikasi apa pun pada kode aplikasi.

Sebaiknya gunakan redundansi zona di wilayah yang didukungnya, terutama untuk akun wilayah tunggal. 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.

Tip

Mengaktifkan redundansi zona adalah cara yang bagus untuk meningkatkan ketahanan database Azure Cosmos DB Anda tanpa memperkenalkan kompleksitas aplikasi tambahan atau memengaruhi performa. Bergantung pada konfigurasi akun Anda, konfigurasi tersebut bahkan mungkin tidak dikenakan biaya tambahan.

Jika Anda tidak mengaktifkan redundansi zona, akun tersebut nonzonal di wilayah tersebut. Akun nonzonal dapat menempatkan replika dalam satu zona ketersediaan, yang dapat mengarah pada potensi pemadaman jika zona tertentu mengalami masalah.

Requirements

  • Region support: 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.

    Redundansi zona bukan pengaturan di seluruh akun. Azure Cosmos DB akun dapat mencakup beberapa wilayah, dan setiap wilayah dapat dikonfigurasi secara independen untuk menggunakan zona ketersediaan. Wilayah yang tidak mendukung zona ketersediaan tidak mencegah Anda mengaktifkan redundansi zona di wilayah lain dalam akun yang sama.

  • Akun tanpa server: Anda hanya dapat mengonfigurasi akun tanpa server zona redundan saat membuatnya. Anda tidak dapat mengonversi akun serverless yang ada tanpa zona ketersediaan ke konfigurasi zona ketersediaan. Untuk beban kerja misi penting, kami sarankan Anda menggunakan throughput yang disediakan.

Considerations

  • Beberapa pemadaman zona simultan: Akun wilayah tunggal dengan redundansi zona dapat mempertahankan ketersediaan baca-tulis saat pemadaman memengaruhi satu zona ketersediaan. Namun, jika pemadaman memengaruhi beberapa zona ketersediaan atau seluruh wilayah, akun satu wilayah kehilangan akses baca dan tulis hingga layanan dipulihkan. Pertimbangkan untuk menggunakan akun multi-wilayah jika Anda perlu tahan terhadap beberapa zona yang gagal secara bersamaan.

  • Akun multi-wilayah: Jika Anda memiliki akun multi-wilayah, Anda dapat mengaktifkan redundansi zona secara opsional pada salah satu atau semua wilayah akun yang mendukung zona ketersediaan. Sebaiknya aktifkan redundansi zona saat akun Anda dikonfigurasi untuk menggunakan satu wilayah, atau jika dikonfigurasi untuk menggunakan satu wilayah tulis dengan beberapa wilayah baca.

Biaya

Wilayah yang redundansi zonanya diaktifkan dikenakan biaya lebih tinggi. Namun, harga premium untuk zona ketersediaan dikecualikan untuk akun yang dikonfigurasi dengan penulisan multi-wilayah, dan untuk koleksi yang dikonfigurasi untuk menggunakan mode throughput skala otomatis. Untuk informasi selengkapnya, lihat Harga Azure Cosmos DB.

Mengonfigurasi dukungan zona ketersediaan

Untuk sebagian besar akun, Anda hanya mengaktifkan redundansi zona saat menambahkan wilayah baru ke akun Azure Cosmos DB. Untuk mengaktifkan dukungan zona ketersediaan pada akun yang ada, tambahkan wilayah dan aktifkan redundansi zona di atasnya. Anda dapat mengikuti proses untuk menambahkan wilayah sementara sehingga Anda dapat mengonfigurasi redundansi zona di wilayah asli Anda. Untuk langkah-langkah terperinci, lihat Aktifkan redundansi zona pada akun Azure Cosmos DB.

Untuk akun tanpa server, Anda harus mengaktifkan redundansi zona saat membuat akun.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi akun Azure Cosmos DB untuk redundansi zona, dan semua zona beroperasi.

  • Cross-zone operation: Azure Cosmos DB secara otomatis merutekan permintaan ke replika di seluruh zona ketersediaan, sehingga replika apa pun dapat melayani permintaan.

  • Replikasi data lintas zona: Ketika klien membuat perubahan pada data apa pun, perubahan tersebut diterapkan ke beberapa replika di zona yang berbeda untuk mencapai kuorum. Pendekatan ini disebut sebagai replikasi sinkron. Replikasi sinkron memastikan tingkat konsistensi data yang tinggi, yang mengurangi kemungkinan kehilangan data selama kegagalan zona. Zona ketersediaan terletak relatif berdekatan, yang berarti ada efek minimal pada latensi atau throughput.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika Anda mengonfigurasi akun Azure Cosmos DB untuk redundansi zona, dan ada pemadaman di salah satu zona.

  • Deteksi dan Respon: Platform Azure Cosmos DB bertanggung jawab atas deteksi kegagalan di zona ketersediaan. Anda tidak perlu melakukan apa pun untuk memulai failover zona.
  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat zona tidak berfungsi. Namun, Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah. Anda juga 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.

  • Aktivasi permintaan: Ketika zona ketersediaan menjadi tidak tersedia, Azure Cosmos DB mengakhiri permintaan yang sedang berlangsung yang terhubung ke replika di zona yang terpengaruh, dan aplikasi harus mencoba kembali permintaan tersebut. Pastikan aplikasi Anda disiapkan dengan mengikuti panduan penanganan kesalahan sementara.

  • Kehilangan data yang diharapkan: Tidak ada kehilangan data yang diharapkan dari kegagalan zona.

  • Waktu henti yang diharapkan: Selama pemadaman zona, koneksi mungkin mengalami gangguan singkat yang biasanya berlangsung beberapa detik saat lalu lintas didistribusikan ulang. Pastikan aplikasi Anda disiapkan dengan mengikuti panduan penanganan kesalahan sementara.

  • Redistribution: Azure Cosmos DB secara otomatis mengalihkan permintaan masuk ke replika yang sehat di zona ketersediaan lainnya. Ketika zona ketersediaan mengalami pemadaman, platform secara otomatis merealokasi throughput yang disediakan ke replika lain.

Pemulihan Zona

Saat zona ketersediaan pulih, Azure Cosmos DB secara otomatis memulihkan replika di zona ketersediaan, dan mengalihkan lalu lintas antar replika seperti biasa.

Uji kegagalan zona

Failover dan pemulihan zona ketersediaan untuk Azure Cosmos DB dikelola sepenuhnya oleh Microsoft. Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan.

Ketahanan terhadap kegagalan di seluruh wilayah

Saat Anda menyebarkan akun Azure Cosmos DB di satu wilayah, pemadaman di seluruh wilayah yang memengaruhi semua simpul Azure Cosmos DB biasanya tidak menyebabkan kehilangan data, tetapi mencegah aplikasi Anda mengakses data. Azure Cosmos DB memulihkan akses data setelah layanan pulih di wilayah yang terpengaruh. Kehilangan data hanya terjadi jika wilayah mengalami bencana yang tidak dapat dipulihkan.

Untuk mempersiapkan kasus pemadaman wilayah yang jarang terjadi, Anda dapat mengonfigurasi Azure Cosmos DB untuk mendukung berbagai tingkat durabilitas dan ketersediaan dengan menggunakan salah satu pendekatan ini:

Tabel berikut ini meringkas opsi pemulihan yang tersedia berdasarkan konfigurasi akun dan jenis pemadaman. Bagian selanjutnya dari artikel ini memberikan detail ekstensif tentang opsi ini dan perilaku terkait.

Configuration Jenis pemadaman Dampak ketersediaan Dampak durabilitas Apa yang harus dilakukan
Akun wilayah tunggal Gangguan Wilayah Akses baca dan tulis hilang hingga layanan dipulihkan. Tidak ada kehilangan data kecuali wilayah mengalami bencana yang tidak dapat dipulihkan. Tunggu pemulihan layanan atau minta pemulihan akun dari cadangan ke wilayah lain.
Wilayah penulisan tunggal, akun multi-wilayah Gangguan wilayah SDK mengalihkan rute ke wilayah yang tersedia berdasarkan konfigurasi wilayah pilihan.

Untuk akun yang menggunakan konsistensi kuat hanya di dua wilayah, atau batas keusangan yang melebihi jendela waktu keusangan, ketersediaan tulis juga akan hilang kecuali Anda mematikan wilayah yang terpengaruh.		 Tidak ada kehilangan data. Menjamin throughput yang memadai di daerah-daerah yang tersisa. Pertimbangkan untuk menonaktifkan wilayah yang terkena dampak untuk mencapai konsistensi kekuatan atau keterbatasan keusangan.
Wilayah penulisan tunggal, akun multi-wilayah Pemadaman wilayah tulis (dengan PPAF diaktifkan) Failover partisi otomatis; tidak diperlukan intervensi manual. Jika akun menggunakan konsistensi yang kuat, tidak ada kehilangan data. Jika akun tidak menggunakan konsistensi yang kuat, data yang belum direplikasi dapat hilang jika wilayah tersebut mengalami kehilangan data secara permanen. Tidak perlu tindakan. PPAF mengelola failover secara otomatis.
Wilayah penulisan tunggal, akun multi-wilayah Gangguan Write region (tanpa PPAF) Ketersediaan penulisan hilang hingga operasi offline di wilayah tersebut atau failover yang dikelola oleh layanan selesai. Pembacaan berlanjut dari daerah yang sehat. Jika akun menggunakan konsistensi yang kuat, tidak ada kehilangan data. Jika akun tidak menggunakan konsistensi yang kuat, data yang tidak direplikasi dapat hilang jika wilayah pusat data mengalami kehilangan data permanen, yang kemungkinan kecil terjadi. Melakukan operasi offline wilayah. Jika failover yang dikelola layanan diaktifkan, Azure Cosmos DB memulai failover secara otomatis, tetapi ini mungkin memakan waktu satu jam atau lebih. Jangan ubah wilayah tulis selama pemadaman.
Akun wilayah multi-penulisan Pemadaman di setiap wilayah Perutean otomatis ke wilayah yang sehat melalui konfigurasi SDK; tidak diperlukan intervensi manual. Data yang baru diperbarui di wilayah yang gagal mungkin tidak tersedia di wilayah yang tersisa. Jika wilayah tersebut mengalami kehilangan data permanen, data yang tidak direplikasi dapat hilang. Pastikan throughput yang memadai di wilayah yang tersisa. Setelah pemulihan, Azure Cosmos DB secara otomatis memulihkan data yang tidak direplikasi menggunakan metode resolusi konflik yang dikonfigurasi.
Konfigurasi akun apa pun Kerusakan data atau penghapusan yang tidak disengaja Tidak ada dampak ketersediaan. Potensi kehilangan data tergantung pada kapan kerusakan atau penghapusan terdeteksi. Pemulihan titik waktu (pencadangan berkelanjutan) atau pemulihan dari cadangan berkala.

Nota

Artikel ini berfokus pada aspek keandalan fitur multi-wilayah Azure Cosmos DB. Ada manfaat lain untuk beberapa wilayah baca dan tulis, seperti performa dan skala yang lebih tinggi untuk aplikasi yang didistribusikan secara global. Anda harus mengevaluasi seluruh arsitektur solusi Anda dan mempertimbangkan semua manfaat menggunakan kemampuan ini.

SDK dan ketahanan

SDK Azure Cosmos DB adalah bagian penting dari strategi ketahanan aplikasi Anda. Saat Anda memiliki akun multi-wilayah, konfigurasi SDK memengaruhi bagaimana permintaan dirutekan antar wilayah, termasuk wilayah pilihan untuk disambungkan, dan wilayah yang harus dikecualikan. SDK memantau ketersediaan wilayah dan partisi, dan dapat secara dinamis mengonfigurasi ulang diri untuk menggunakan wilayah dan partisi yang sehat, seperti melalui pemutus sirkuit tingkat partisi.

Untuk informasi selengkapnya tentang bagaimana SDK mendukung ketersediaan tinggi, lihat dokumentasi ketersediaan tinggi untuk SDK yang Anda gunakan:

Potensi kehilangan data selama pemadaman wilayah

Saat Anda menyebarkan akun Azure Cosmos DB di beberapa wilayah, durabilitas data bergantung pada tingkat konsistensi yang Anda konfigurasikan di akun. Tabel berikut merinci tujuan titik pemulihan (RPO) untuk semua tingkat konsistensi, dari sebuah akun Azure Cosmos DB yang telah diterapkan di setidaknya dua wilayah. RPO mewakili potensi kehilangan data selama pemadaman 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.

Beberapa wilayah baca dengan satu wilayah tulis

Jika solusi Anda memerlukan waktu aktif berkelanjutan selama pemadaman wilayah, Anda dapat mengonfigurasi Azure Cosmos DB untuk mereplikasi data Anda di beberapa wilayah, dengan penulisan yang ditangani oleh wilayah utama Anda. Anda dapat secara opsional mengonfigurasi aplikasi Anda untuk terhubung ke wilayah baca tertentu, yang dapat membantu meningkatkan performanya. Jika suatu wilayah mengalami pemadaman, akun dapat terus beroperasi dari wilayah yang sehat.

Diagram memperlihatkan akun Azure Cosmos DB. Wilayah A adalah wilayah tulis dan baca, dan wilayah B adalah wilayah baca. Aplikasi di wilayah A melakukan baca dan tulis terhadap akun Azure Cosmos DB di wilayah A. Aplikasi di wilayah B melakukan pembacaan terhadap akun di wilayah B, tetapi menulis terhadap wilayah A. Secara internal, Azure Cosmos DB mereplikasi perubahan antara regions.

Failover antar wilayah

Anda dapat mengonfigurasi SDK Azure Cosmos DB dengan daftar wilayah baca yang diprioritaskan. SDK menghubungkan aplikasi Anda ke wilayah pertama yang tersedia dalam daftar. Selama pemadaman wilayah baca, SDK mendeteksi pemadaman wilayah melalui kode respons backend, menandainya sebagai tidak tersedia, dan merutekan operasi di masa mendatang ke wilayah berikutnya yang tersedia dalam daftar preferensi. Pastikan bahwa daftar wilayah pilihan diatur dengan benar dan selaras dengan persyaratan bisnis dan latensi Anda. Untuk panduan mendetail, lihat Memecahkan masalah ketersediaan Azure Cosmos DB SDK.

Failover adalah proses membuat salah satu wilayah akun Anda tidak tersedia, baik sepenuhnya atau sebagian. Efek failover tergantung pada apakah wilayah tersebut adalah wilayah tulis atau wilayah baca:

  • Jika suatu wilayah tulis menjadi tidak tersedia, wilayah lain akan berfungsi sebagai wilayah tulis.
  • Jika wilayah baca menjadi tidak tersedia, wilayah tersebut tidak dapat melayani permintaan baca dan wilayah lain digunakan untuk operasi baca sebagai gantinya.

Azure Cosmos DB menyediakan beberapa jenis failover:

  • Per-partisi failover otomatis (PPAF): Secara internal, Azure Cosmos DB mendistribusikan data Anda ke berbagai partisi fisik. Jika masalah terjadi pada infrastruktur yang mendukung partisi, partisi lain mungkin tidak terpengaruh. PPAF memungkinkan akun dengan wilayah penulisan tunggal untuk menjalankan failover otomatis pada partisi individual ke wilayah sekunder, dengan tetap menjaga partisi yang sehat di wilayah utama. PPAF dapat membantu meminimalkan waktu henti dan memungkinkan pemulihan yang lebih cepat selama kegagalan wilayah parsial. Untuk informasi selengkapnya, lihat Cara melakukan onboarding dan mengadopsi Per-Partition Automatic Failover (PPAF) untuk Azure Cosmos DB.

    Nota

    Per Failover Otomatis Partisi ada di pratinjau publik. Fitur ini disediakan tanpa perjanjian tingkat layanan. Untuk informasi lebih lanjut, lihat Supplemental Terms of Use for Microsoft Azure Previews.

  • Failover paksa: Anda dapat membuat salah satu wilayah akun Anda menjadi tidak aktif. Ini juga disebut sebagai failover yang diatur oleh pelanggan, atau operasi wilayah offline. Ini adalah pendekatan yang direkomendasikan untuk memulihkan ketersediaan dengan cepat selama pemadaman. Anda bertanggung jawab untuk mendeteksi pemadaman dan memicu failover. Anda juga dapat menggunakan failover paksa untuk mensimulasikan skenario penurunan wilayah untuk pengujian, seperti selama latihan pemulihan bencana.

    Jika Anda menjadikan wilayah penulisan secara offline, wilayah pembacaan dengan prioritas tertinggi berikutnya menjadi wilayah penulisan baru. Jika Anda mengambil wilayah baca secara offline, aplikasi Anda dapat terhubung ke wilayah baca lainnya di akun.

    Failover paksa wilayah tulis Anda membawa kemungkinan kehilangan data untuk setiap penulisan yang tidak direplikasi.

    Setelah failover paksa, Microsoft harus membuat wilayah kembali online. Untuk wilayah yang sehat, proses ini otomatis tetapi dapat memakan waktu hingga beberapa hari. Jika wilayah tidak kembali online dalam satu atau dua hari, buka kasus dukungan untuk meminta bantuan.

  • Ubah wilayah tulis: Saat wilayah sehat, Anda dapat mengubah wilayah tulis akun Anda. Perubahan ini secara efektif merupakan failover wilayah tulis yang direncanakan untuk akun Anda.

    Mengubah wilayah tulis tidak menyebabkan kehilangan data, karena replikasi data mengejar ketinggalan sebelum wilayah tulis baru dipromosikan. Mungkin ada gangguan singkat, tetapi klien yang menggunakan logika coba lagi dan teknik penanganan kesalahan sementara lainnya biasanya tidak mengalami dampak yang signifikan.

    Operasi ini mengharuskan wilayah sehat, sehingga tidak dapat digunakan selama pemadaman wilayah.

  • Service-managed failover: Saat akun Anda menggunakan failover yang dikelola layanan, Microsoft bertanggung jawab untuk memutuskan kapan harus melakukan failover antar wilayah. Untuk mengaktifkan failover yang dikelola layanan, Anda menentukan prioritas untuk setiap wilayah. Namun, proses mendeklarasikan pemadaman dan memicu failover yang dikelola layanan dapat memakan waktu yang signifikan - berpotensi satu jam atau lebih. Untuk pemulihan yang lebih cepat, lakukan failover paksa alih-alih menunggu failover yang diinisiasi oleh layanan.

    Jika Microsoft memicu failover yang dikelola oleh layanan untuk wilayah penulisan akun, penulisan yang tidak direplikasi dapat hilang.

    Setelah failover yang dikelola layanan, Microsoft perlu memulihkan wilayah kembali online. Microsoft secara otomatis membawa wilayah online tetapi proses ini dapat memakan waktu beberapa hari.

Requirements

Region support: Anda dapat mengonfigurasi wilayah Azure apa pun sebagai wilayah baca untuk akun Azure Cosmos DB Anda.

Biaya

Menambahkan wilayah baca tambahan ke akun Azure Cosmos DB meningkatkan biaya yang ada untuk setiap wilayah. Untuk informasi selengkapnya, lihat Harga Azure Cosmos DB.

Mengonfigurasi beberapa wilayah baca

Perencanaan dan manajemen kapasitas

Jika aplikasi Anda menyebarkan permintaan di seluruh wilayah dan satu wilayah offline, wilayah yang tersisa mengalami volume permintaan yang lebih tinggi. Gunakan throughput skala otomatis untuk menyesuaikan kapasitas secara dinamis berdasarkan permintaan. Jika Anda menggunakan throughput yang disediakan, rencanakan kapasitas yang memadai untuk menangani hilangnya wilayah tanpa degradasi layanan, dan pertimbangkan untuk melakukan overprovisioning. Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan penyediaan berlebih.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi akun Azure Cosmos DB dengan beberapa wilayah baca, dan semua wilayah beroperasi.

  • Operasi lintas wilayah: Aplikasi Anda mengonfigurasi wilayah yang harus menerima operasi baca. Anda dapat mengonfigurasi aplikasi anda dengan daftar wilayah yang diprioritaskan, atau untuk mengecualikan beberapa wilayah. Untuk informasi selengkapnya tentang cara kerja pemilihan wilayah, lihat Diagnose dan memecahkan masalah ketersediaan SDK Azure Cosmos DB di lingkungan multiregional.

    Semua operasi penulisan diarahkan ke daerah penulisan akun Anda.

  • Replikasi data lintas wilayah: Semua operasi tulis terjadi di wilayah utama akun Anda. Penulisan direplikasi ke wilayah baca lainnya berdasarkan tingkat konsistensi akun yang dikonfigurasi. Untuk informasi tentang jeda replikasi maksimum, lihat Potensi kehilangan data selama pemadaman wilayah.

Perilaku selama kegagalan wilayah baca

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi akun Azure Cosmos DB dengan beberapa wilayah baca, dan ada pemadaman di salah satu wilayah baca akun.

Important

Idealnya, pemadaman wilayah baca harus ditangani di tingkat klien dengan mengonfigurasi daftar wilayah pilihan dengan benar dalam konfigurasi SDK. Saat dikonfigurasi dengan benar, SDK secara otomatis mendeteksi pemadaman dan mengalihkan operasi baca ke wilayah berikutnya yang tersedia tanpa memerlukan failover sisi layanan.

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

    • PPAF: PPAF biasanya tidak berlaku untuk pemadaman wilayah baca. Namun, untuk akun dengan konsistensi yang kuat dan hanya dua wilayah, kehilangan wilayah baca mengurangi akun ke satu wilayah, yang tidak dapat mempertahankan kuorum dinamis. Dalam skenario ini, PPAF dapat mengaktifkan untuk mempertahankan ketersediaan dengan mengalihkan partisi yang terpengaruh ke wilayah yang sehat.

    • Failover paksa: Anda bertanggung jawab untuk melakukan failover paksa. Untuk langkah-langkah terperinci, lihat Lakukan failover paksa untuk Akun Azure Cosmos DB Anda.

      Jika Anda tidak melakukan failover, perilaku akun Anda bergantung pada tingkat konsistensinya:

      • Konsistensi yang kuat: Konsistensi yang kuat membutuhkan dua wilayah atau lebih untuk mempertahankan kuorum dinamis. Jika ada kurang dari dua wilayah yang tersedia dan Anda tidak melakukan failover, akun kehilangan akses tulis hingga pemulihan layanan.

      • Konsistensi keusangan terikat: Konsistensi keusangan terikat bergantung pada mempertahankan ambang batas keusangan tertentu antar wilayah. Jika panjang pemadaman wilayah melebihi ambang batas, sistem tidak dapat mempertahankan konsistensi antara penulisan. Jika Anda tidak melakukan failover, akun akan kehilangan kemampuan menulis hingga layanan dipulihkan.

    • Service-managed failover: Jika failover yang dikelola layanan diaktifkan, Microsoft akhirnya mendeteksi pemadaman dan memulai failover akun Anda. Namun, proses ini dapat memakan waktu yang signifikan, berpotensi satu jam atau lebih. Untuk pemulihan yang lebih cepat, lakukan failover paksa alih-alih menunggu failover yang dikelola oleh layanan untuk dipicu.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah.

    • Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Setiap permintaan aktif mungkin dihentikan dan perlu dicoba kembali oleh klien setelah failover selesai. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Kehilangan data yang diharapkan: Pemadaman di wilayah baca tidak menyebabkan kehilangan data. Azure Cosmos DB tetap memenuhi jaminan konsistensi baca.

  • Waktu henti yang diharapkan: Jumlah waktu henti yang dialami akun Anda tergantung pada jenis failover yang digunakan akun Anda.

    • PPAF: Ketika PPAF diaktifkan, sistem secara otomatis mendeteksi dan memulihkan dari kegagalan, biasanya dalam waktu 3 menit, tanpa intervensi manual.

    • Failover paksa: Waktu henti tergantung pada:

      • Berapa lama waktu yang dibutuhkan Anda untuk menemukan pemadaman dan memulai failover.

      • Berapa lama waktu yang dibutuhkan failover, yang biasanya beberapa detik.

        Warning

        Jangan melakukan operasi konfigurasi (sarana kontrol) apa pun di wilayah yang terpengaruh selama skenario pemadaman, karena mengakibatkan ketidakkonsistensian akun dan pemulihan penundaan. Beberapa contoh operasi sarana kontrol untuk menghindari meliputi:

        • Mengubah wilayah tulis atau mengubah prioritas failover
        • Memperbarui akun ke konfigurasi multi-tulis
        • Memperbarui tingkat konsistensi atau pengaturan akun lainnya
        • Memperbarui konfigurasi titik akhir privat atau pengaturan jaringan
        • Memperbarui kapasitas akun atau operasi penskalaan
        • Operasi lain yang memodifikasi konfigurasi akun atau pengaturan wilayah

    • Service-managed failover: Microsoft bertanggung jawab untuk memulai failover yang dikelola layanan, dan waktu henti pengalaman akun Anda didasarkan pada waktu yang diperlukan Microsoft untuk menyatakan pemadaman dan memulai failover. Dalam beberapa situasi, mungkin perlu waktu satu jam atau lebih. Jika akun Anda mengalami gangguan pada penulisan dan Anda perlu memulihkan ketersediaan penulisan dengan cepat, lakukan failover secara paksa.

  • Redistribusi: Untuk failover paksa atau failover yang dikelola layanan, wilayah yang terpengaruh terputus dan ditandai sebagai offline.

    Tidak ada perubahan yang diperlukan dalam kode aplikasi Anda untuk menangani pemadaman wilayah baca. SDK Azure Cosmos DB mengalihkan operasi baca ke wilayah berikutnya yang tersedia di daftar wilayah pilihan. Jika tidak ada wilayah dalam daftar wilayah pilihan yang tersedia, operasi baca secara otomatis kembali ke wilayah tulis akun saat ini seperti yang dikonfigurasi dalam layanan.

    Nota

    Jika Anda menggunakan titik akhir privat dengan akun Azure Cosmos DB, pastikan DNS privat merutekan dengan benar setelah operasi wilayah dilakukan secara offline. Untuk panduan terperinci, lihat Pertimbangan failover untuk titik akhir privat.

Perilaku selama kegagalan wilayah tulis

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi akun Azure Cosmos DB dengan beberapa wilayah baca, dan ada pemadaman di wilayah tulis akun.

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

    • PPAF: Microsoft secara otomatis mendeteksi pemadaman dan memulai failover beberapa partisi, jika sesuai. Aplikasi Anda tidak perlu mengambil tindakan apa pun.

    • Failover paksa: Anda berkewajiban untuk melakukan failover paksa. Untuk langkah-langkah terperinci, lihat Melakukan failover paksa untuk Akun Azure Cosmos DB Anda.

      Jika Anda tidak melakukan failover, akun akan kehilangan kemampuan menulis hingga pemulihan layanan.

      Jika ada pemadaman pada wilayah tulis akun Anda, hindari melakukan operasi ubah wilayah tulis. Perubahan wilayah tulis tidak berhasil jika ada pemadaman wilayah sumber atau tujuan. Alasannya adalah bahwa prosedur perubahan wilayah mencakup pemeriksaan konsistensi yang memerlukan konektivitas antar wilayah.

    • Service-managed failover: Microsoft secara otomatis mendeteksi pemadaman dan memulai failover akun Anda. Aplikasi Anda tidak perlu mengambil tindakan apa pun.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah.

    • Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Setiap permintaan aktif mungkin dihentikan dan perlu dicoba kembali oleh klien setelah failover selesai. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Kehilangan data yang diharapkan: Jika Anda mengonfigurasi akun Anda dengan konsistensi yang kuat, tidak ada kehilangan data yang terjadi. Jika tidak, tulisan yang tidak direplikasi mungkin hilang setelah failover selesai. Untuk informasi tentang kehilangan data maksimum yang diharapkan selama pemadaman wilayah, lihat Potensi kehilangan data selama pemadaman wilayah.

  • Waktu henti yang diharapkan: Jumlah waktu henti yang dialami akun Anda tergantung pada jenis failover yang digunakan akun Anda.

    • PPAF: Ketika PPAF diaktifkan, harapkan gangguan singkat, yang biasanya sekitar 3 menit.

    • Failover paksa: Waktu henti tergantung pada:

      • Berapa lama waktu yang dibutuhkan Anda untuk menemukan pemadaman dan memulai failover.
      • Durasi failover, yang biasanya hanya beberapa detik.

    Warning

    Jangan melakukan operasi sarana kontrol apa pun di wilayah yang terpengaruh selama skenario pemadaman, karena mengakibatkan ketidakkonsistensian akun dan pemulihan penundaan. Beberapa contoh operasi sarana kontrol untuk menghindari meliputi:

    • Mengubah wilayah tulis atau mengubah prioritas failover
    • Memperbarui akun ke konfigurasi multi-tulis
    • Memperbarui tingkat konsistensi atau pengaturan akun lainnya
    • Memperbarui konfigurasi titik akhir privat atau pengaturan jaringan
    • Memperbarui kapasitas akun atau operasi penskalaan
    • Operasi lain yang memodifikasi konfigurasi akun atau pengaturan wilayah
    • Service-managed failover: Microsoft bertanggung jawab untuk memulai failover yang dikelola layanan, dan waktu henti pengalaman akun Anda didasarkan pada waktu yang diperlukan Microsoft untuk menyatakan pemadaman dan memulai failover. Dalam beberapa situasi, mungkin perlu waktu satu jam atau lebih. Untuk memulihkan ketersediaan tulis dengan cepat, lakukan failover paksa.

  • Redistribusi: Redistribusi lalu lintas penulisan bergantung pada jenis failover yang digunakan oleh akun Anda.

    • PPAF: Azure Cosmos DB secara otomatis mengalihkan partisi yang mengalami masalah ke wilayah yang berfungsi baik.

    • Failover paksa: Saat Anda melakukan failover paksa, wilayah tulis akun Anda berubah ke wilayah yang Anda tentukan.

    Nota

    Jika Anda menggunakan titik akhir privat dengan akun Azure Cosmos DB, pastikan DNS privat berfungsi dengan benar setelah operasi wilayah menjadi offline. Untuk panduan terperinci, lihat Pertimbangan failover untuk titik akhir privat.

    • Service-managed failover: Azure Cosmos DB secara otomatis mempromosikan salah satu wilayah sekunder akun menjadi wilayah tulis utama baru. Failover terjadi ke wilayah lain dalam urutan prioritas wilayah yang Anda tentukan.

Pemulihan wilayah

Microsoft harus membuat wilayah kembali online. Saat suatu wilayah pulih setelah pemadaman, Microsoft secara otomatis membuat wilayah online. Namun, proses ini dapat memakan waktu beberapa hari.

Important

Setelah failover paksa, Microsoft secara otomatis membawa wilayah kembali online untuk wilayah yang sehat. Jika wilayah tidak kembali online dalam satu atau dua hari, buka kasus dukungan untuk meminta bantuan.

Setelah wilayah kembali aktif, tindakan yang Anda lakukan akan berbeda tergantung pada apakah pemadaman terjadi di wilayah baca atau wilayah tulis.

  • Setelah gangguan wilayah baca: Ketika wilayah yang terpengaruh kembali online, wilayah tersebut disinkronkan dengan wilayah tulis saat ini dan tersedia lagi untuk melayani permintaan baca setelah sepenuhnya terupdate. 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.

  • Pengagalan wilayah tulis: Ketika wilayah yang terpengaruh kembali online, wilayah menunjukkan sebagai "online" di portal Azure, dan tersedia sebagai wilayah baca. Pada titik ini, aman untuk mengubah wilayah tulis kembali ke wilayah yang dipulihkan.

    Important

    Wilayah yang dipulihkan tidak akan secara otomatis dipromosikan kembali sebagai wilayah tulis setelah dipulihkan. Anda bertanggung jawab untuk mengembalikan ke wilayah yang telah dipulihkan sebagai wilayah tulis, setelah dianggap aman.

    Tidak ada kehilangan data atau aksesibilitas sebelum, saat, atau sesudah Anda mengubah daerah penulisan. Aplikasi Anda terus tersedia dengan baik.

    Jika ada penulisan yang tidak direplikasi sebelum wilayah tersebut offline, Anda dapat membaca penulisan yang tidak direplikasi dari umpan konflik. Aplikasi Anda dapat membaca stream konflik, mengatasi konflik apa pun berdasarkan logika khusus aplikasi, dan menulis data yang diperbarui kembali ke kontainer sesuai kebutuhan.

Pengujian untuk mendeteksi kegagalan wilayah

Aplikasi Anda mungkin tidak menangani failover wilayah secara benar, meskipun akun Azure Cosmos DB Anda berketersediaan tinggi. 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. Lakukan failover forced dengan menggunakan PowerShell, Azure CLI, atau portal Azure, lalu pantau aplikasi Anda. Setelah menyelesaikan pengujian, Anda dapat kembali ke wilayah utama setelah wilayah tersebut kembali online secara otomatis, lalu memulihkan failover yang dikelola oleh layanan untuk akun tersebut. Jika wilayah tidak kembali online dalam satu atau dua hari, buka kasus dukungan untuk meminta bantuan.

Jika akun Anda menggunakan PPAF, Anda dapat mensimulasikan failover partisi. Untuk informasi selengkapnya, lihat Menguji penyiapan PPAF (simulasikan kesalahan).

Beberapa wilayah tulis

Anda dapat mengonfigurasi Azure Cosmos DB untuk menerima tulisan di beberapa wilayah. Konfigurasi ini dapat memberikan ketahanan yang sangat tinggi terhadap pemadaman wilayah. Ini juga berguna untuk mengurangi latensi tulis dalam aplikasi yang didistribusikan secara geografis.

Diagram memperlihatkan akun Azure Cosmos DB. Wilayah A dan wilayah B keduanya adalah wilayah tulis dan baca. Aplikasi di wilayah A melakukan baca dan tulis terhadap akun Azure Cosmos DB di wilayah A. Aplikasi di wilayah B melakukan baca dan tulis terhadap akun Azure Cosmos DB di wilayah B. Secara internal, Azure Cosmos DB secara asinkron mereplikasi perubahan antara regions.

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

Penting untuk mempertimbangkan desain aplikasi Anda dan cara kerjanya dengan beberapa wilayah tulis. Tinjau praktik terbaik untuk penulisan di beberapa wilayah.

Requirements

Region support: Anda dapat mengonfigurasi wilayah Azure apa pun sebagai wilayah baca atau tulis untuk akun Azure Cosmos DB Anda.

Biaya

Menambahkan wilayah tulis tambahan ke akun Azure Cosmos DB meningkatkan biaya yang ada untuk setiap wilayah. Untuk informasi selengkapnya, lihat Harga Azure Cosmos DB.

Mengonfigurasi beberapa wilayah tulis

Anda dapat mengonfigurasi beberapa wilayah tulis di akun Anda saat membuat akun atau kapan saja setelah akun dibuat. Untuk informasi selengkapnya, lihat Mengonfigurasi beberapa wilayah tulis.

Untuk menggunakan beberapa wilayah tulis secara efektif, aplikasi Anda juga perlu dikonfigurasi dengan tepat. Lihat Mengonfigurasi penulisan multi-wilayah dalam aplikasi yang menggunakan Azure Cosmos DB.

Perencanaan dan manajemen kapasitas

Jika aplikasi Anda menyebarkan permintaan di seluruh wilayah dan satu wilayah offline, wilayah yang tersisa mengalami volume permintaan yang lebih tinggi. Gunakan throughput skala otomatis untuk menyesuaikan kapasitas secara dinamis berdasarkan permintaan. Jika Anda menggunakan throughput yang dialokasikan, rencanakan kapasitas yang memadai untuk menangani hilangnya region tanpa penurunan kualitas layanan, dan pertimbangkan penyediaan berlebih. Untuk informasi selengkapnya, lihat Mengelola kapasitas dengan penyediaan berlebih.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan saat Anda mengonfigurasi akun Azure Cosmos DB dengan beberapa wilayah tulis, dan semua wilayah beroperasi.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang harus diantisipasi saat Anda mengonfigurasi akun Azure Cosmos DB dengan beberapa region penulisan, dan ada pemadaman di salah satu region pembacaan atau penulisan akun.

  • Deteksi dan respons: Aplikasi Anda mendeteksi hilangnya wilayah. Azure Cosmos DB SDK menyediakan kemampuan pemilihan wilayah otomatis yang merutekan operasi baca dan tulis ke wilayah yang sehat.

  • Pemberitahuan: Microsoft tidak secara otomatis memberi tahu Anda saat suatu wilayah tidak berfungsi. Namun:

    • Anda dapat menggunakan Azure Resource Health untuk memantau kesehatan sumber daya individual, dan Anda dapat menyiapkan pemberitahuan Resource Health untuk memberi tahu Anda tentang masalah.

    • Anda dapat menggunakan Azure Service Health untuk memahami kesehatan keseluruhan layanan, termasuk kegagalan wilayah apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Setiap permintaan aktif mungkin dihentikan dan perlu dicoba kembali oleh klien setelah failover selesai. Jika klien Anda menangani kesalahan sementara dengan tepat dengan mencoba kembali setelah waktu yang singkat, mereka biasanya menghindari dampak yang signifikan.

  • Kehilangan data yang diharapkan: Data yang baru diperbarui mungkin menjadi tidak tersedia di wilayah lain. Untuk informasi tentang kehilangan data maksimum yang diharapkan selama pemadaman wilayah, lihat Potensi kehilangan data selama pemadaman wilayah. Dalam kemungkinan kecil wilayah yang terpengaruh mengalami kehilangan data permanen, Anda mungkin kehilangan data yang tidak direplikasi.

  • Waktu henti yang diharapkan: Tidak ada waktu henti yang diharapkan dalam konfigurasi multi-tulis, asalkan SDK dikonfigurasi dengan benar dengan ApplicationRegions atau PreferredRegions.

    Tip

    Untuk hasil terbaik, aplikasi yang didistribusikan secara global harus dihadapkan oleh layanan penyeimbang beban global, seperti Azure Front Door atau Azure Traffic Manager. Layanan ini dapat mendeteksi degradasi regional dan secara otomatis merutekan lalu lintas ke instans aplikasi di wilayah yang sehat.

  • Redistribution: SDK Azure Cosmos DB secara otomatis mendeteksi bahwa wilayah tersebut tidak sehat dan mengalihkan operasi baca dan tulis ke wilayah berikutnya yang tersedia di daftar wilayah pilihan. Tidak ada perubahan yang diperlukan dalam kode aplikasi Anda.

    Tip

    Jika aplikasi Anda dilayani oleh Azure Front Door atau Traffic Manager, layanan tersebut juga mendeteksi degradasi regional dan merutekan lalu lintas ke wilayah yang tidak bermasalah.

Pemulihan wilayah

Ketika wilayah yang terpengaruh kembali online, wilayah ditampilkan sebagai "online" di portal Azure, dan tersedia lagi.

Setiap data tulis yang tidak direplikasi ketika terjadi kegagalan di wilayah dapat diakses 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.

Pengujian untuk mendeteksi kegagalan wilayah

Untuk menguji skenario failover penulisan di berbagai wilayah, Anda dapat mematikan wilayah penulisan menggunakan failover paksa. Proses ini mensimulasikan pemadaman wilayah, dan Anda dapat mengamati bagaimana aplikasi Anda merespons.

Pencadangan dan pemulihan

Untuk sebagian besar solusi, Anda tidak boleh mengandalkan cadangan secara eksklusif. Sebagai gantinya, gunakan kemampuan lain yang dijelaskan dalam panduan ini untuk mendukung persyaratan ketahanan Anda. Namun, pencadangan melindungi dari beberapa risiko yang tidak dapat dicegah oleh pendekatan lain. Untuk informasi selengkapnya, lihat Apa itu redundansi, replikasi, dan cadangan?.

Kehilangan data dapat terjadi karena penghapusan yang tidak disengaja atau masalah lain dalam aplikasi Anda yang menyebabkan kerusakan data. Saat Anda menggunakan akun wilayah tunggal, kehilangan data mungkin juga terjadi karena bencana yang tidak dapat dipulihkan di wilayah Azure Cosmos DB. Untuk membantu Anda melindungi dari kehilangan data, Azure Cosmos DB menyediakan serangkaian kemampuan pencadangan dan pemulihan. Anda dapat mengonfigurasi pencadangan dan retensi berdasarkan persyaratan pemulihan dan persyaratan biaya Anda. Untuk informasi selengkapnya, lihat Pencadangan online dan pemulihan data sesuai permintaan di Azure Cosmos DB.

Ketahanan terhadap pemeliharaan layanan

Azure Cosmos DB secara transparan mengelola semua detail simpul komputasi individu, dan secara otomatis melakukan patching dan jenis pemeliharaan terencana lainnya. SLA Azure Cosmos DB untuk ketersediaan dan latensi berlaku melalui semua operasi pemeliharaan otomatis yang dilakukan sistem.

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.

Azure Cosmos DB menyediakan SLA untuk berbagai konfigurasi dan karakteristik layanan, termasuk ketersediaan, latensi, throughput, dan konsistensi.

Ketersediaan SLA berbeda tergantung pada apakah Anda menggunakan salah satu kemampuan produk berikut:

  • Throughput yang sudah dialokasikan
  • Akun wilayah tunggal dengan dukungan zona ketersediaan (redundansi zona)
  • Akun yang menggunakan beberapa wilayah baca
  • Akun yang menggunakan beberapa region penulisan (Tingkat Kritis untuk Bisnis)

Konten terkait

  • Last updated on