Bagikan melalui

Keandalan di Azure SQL Managed Instance

Azure SQL Managed Instance adalah mesin database platform as a service (PaaS) yang dikelola sepenuhnya. Ini menyediakan hampir 100% kompatibilitas fitur dengan SQL Server. Azure SQL Managed Instance menangani sebagian besar fungsi manajemen database seperti peningkatan, patching, pencadangan, dan pemantauan tanpa keterlibatan pengguna. Ini berjalan pada versi stabil terbaru dari mesin database SQL Server dan sistem operasi yang di-patch dengan ketersediaan tinggi bawaan.

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

Rekomendasi implementasi produksi untuk keandalan

Untuk sebagian besar penyebaran produksi SQL Managed Instance, pertimbangkan rekomendasi berikut:

Gambaran umum arsitektur keandalan

Instans SQL Tujuan Umum yang dikelola berjalan pada node tunggal yang dikelola oleh Azure Service Fabric. Setiap kali mesin database atau sistem operasi ditingkatkan, atau kegagalan terdeteksi, SQL Managed Instance bekerja dengan Service Fabric untuk memindahkan proses mesin database stateless ke simpul komputasi stateless lain yang memiliki kapasitas bebas yang memadai. File database disimpan di Azure Blob Storage, yang memiliki fitur redundansi bawaan. File data dan log dilepas dari simpul komputasi asli dan dilampirkan ke proses mesin database yang baru diinisialisasi.

Instans terkelola Business Critical SQL menggunakan beberapa replika dalam kluster. Kluster ini mencakup dua jenis replika:

  • Satu replika utama yang dapat diakses untuk beban kerja pelanggan baca-tulis

  • Hingga lima replika sekunder (komputasi dan penyimpanan) yang berisi salinan data

Replika utama terus menerus dan secara berurutan mendorong perubahan pada replika sekunder, yang memastikan bahwa data disimpan pada jumlah replika sekunder yang memadai sebelum melakukan setiap transaksi. Proses ini menjamin bahwa jika replika utama atau replika sekunder yang dapat dibaca menjadi tidak tersedia, replika yang sepenuhnya disinkronkan selalu tersedia untuk failover.

SQL Managed Instance dan Service Fabric memulai failover antar replika. Setelah replika sekunder menjadi replika utama baru, replika sekunder lainnya dibuat untuk memastikan bahwa kluster memiliki jumlah replika yang memadai untuk mempertahankan kuorum. Setelah failover selesai, koneksi Azure SQL secara otomatis dialihkan ke replika utama baru, atau replika sekunder yang dapat dibaca, berdasarkan string koneksi.

Pemborosan

Secara default, SQL Managed Instance mencapai redundansi dengan menyebarkan simpul dan data komputasi di seluruh satu pusat data di wilayah utama. Pendekatan ini melindungi data Anda selama waktu henti yang diharapkan dan tidak terduga berikut:

  • Operasi manajemen oleh pelanggan yang mengakibatkan waktu henti singkat

  • Operasi pemeliharaan layanan

  • Jaringan skala kecil atau kegagalan daya

  • Masalah dan pemadaman pusat data yang melibatkan komponen berikut:

    • Rak tempat mesin yang mendukung layanan Anda berjalan

    • Komputer fisik yang menghosting komputer virtual (VM) yang menjalankan SQL Database Engine.

    • VM yang menjalankan Mesin Database SQL

  • Masalah dengan Mesin SQL Database

  • Potensi pemadaman lokal yang tidak terencana

Untuk informasi selengkapnya tentang bagaimana SQL Managed Instance menyediakan redundansi, lihat Ketersediaan melalui redundansi lokal dan zona.

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.

SQL Managed Instance secara otomatis menangani tugas layanan penting, seperti patching, pencadangan, dan peningkatan Windows dan SQL Database Engine. Ini juga menangani peristiwa tidak terencana seperti kegagalan perangkat keras, perangkat lunak, atau jaringan dasar. SQL Managed Instance dapat dengan cepat pulih bahkan dalam keadaan paling penting, yang memastikan bahwa data Anda selalu tersedia. Sebagian besar pengguna tidak melihat bahwa peningkatan dilakukan terus menerus.

Ketika instans di-patch atau mengalami failover, waktu henti memiliki efek minimal jika Anda menerapkan logika coba lagi di aplikasi Anda. Anda dapat menguji ketahanan aplikasi Anda terhadap kesalahan sementara.

Ketahanan terhadap kegagalan zona ketersediaan

Nota

Redundansi zona saat ini tidak tersedia untuk tingkat layanan Tujuan Umum Next-gen.

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.

Saat mengaktifkan konfigurasi zona-redundan , Anda dapat memastikan bahwa instans terkelola SQL Anda tahan terhadap serangkaian kegagalan besar, termasuk pemadaman pusat data bencana, tanpa perubahan apa pun pada logika aplikasi.

SQL Managed Instance mencapai redundansi zona dengan menempatkan simpul komputasi tanpa status di zona ketersediaan yang berbeda. Ini bergantung pada ZRS stateful yang dilampirkan ke node mana pun yang saat ini berisi proses Mesin Database SQL aktif. Jika pemadaman terjadi, proses SQL Database Engine menjadi aktif pada salah satu simpul komputasi stateless, yang kemudian mengakses data di penyimpanan stateful.

SQL Managed Instance mencapai redundansi zona dengan menempatkan replika instans terkelola SQL Anda di beberapa zona ketersediaan. Untuk menghilangkan satu titik kegagalan, cincin kontrol juga diduplikasi di beberapa zona. Lalu lintas sarana kontrol dirutekan ke load balancer yang juga disebarkan di seluruh zona ketersediaan. Azure Traffic Manager mengontrol perutean lalu lintas dari sarana kontrol ke load balancer.

Persyaratan

  • Dukungan wilayah: Redundansi zona untuk SQL Managed Instance didukung di wilayah tertentu. Untuk informasi selengkapnya, lihat Wilayah yang didukung.

  • Redundansi penyimpanan cadangan: Untuk mengaktifkan redundansi zona untuk instans terkelola SQL Anda, atur redundansi penyimpanan cadangan ke ZRS atau penyimpanan geo-zona-redundan (GZRS).

Biaya

Saat Anda mengaktifkan redundansi zona, ada biaya tambahan untuk instans terkelola SQL Anda dan untuk pencadangan zona redundan. Untuk informasi selengkapnya, lihat Harga.

Anda dapat menghemat uang dengan berkomitmen untuk menggunakan sumber daya komputasi dengan tarif diskon untuk jangka waktu tertentu, yang mencakup instans redundansi zona di tingkat layanan Business Critical. Untuk informasi selengkapnya, lihat Reservasi untuk SQL Managed Instance.

Mengonfigurasi dukungan zona ketersediaan

Bagian ini menjelaskan cara mengonfigurasi dukungan zona ketersediaan untuk instans terkelola SQL Anda:

  • Aktifkan redundansi zona: Untuk mempelajari cara mengonfigurasi redundansi zona pada instans baru dan yang sudah ada, lihat Mengonfigurasi redundansi zona.

    Semua operasi penskalaan untuk SQL Managed Instance, termasuk mengaktifkan redundansi zona, adalah operasi online yang tidak membutuhkan atau hanya memerlukan sedikit waktu henti. Untuk informasi selengkapnya, lihat Durasi operasi manajemen.

  • Nonaktifkan redundansi zona: Anda dapat menonaktifkan redundansi zona dengan mengikuti langkah yang sama untuk mengaktifkan redundansi zona. Proses ini adalah operasi online yang mirip dengan peningkatan tujuan tingkat layanan reguler. Pada akhir proses, instans dimigrasikan dari infrastruktur zona redundan ke infrastruktur zona tunggal.

Perilaku ketika semua zona sehat

Bagian ini menjelaskan apa yang diharapkan ketika instans terkelola SQL Anda dikonfigurasi menjadi zona redundan dan semua zona ketersediaan beroperasi:

  • Perutean lalu lintas antar zona: Selama operasi normal, permintaan dirutekan ke simpul yang menjalankan lapisan komputasi SQL Managed Instance Anda.

  • Replikasi data antar zona: File database disimpan di Azure Storage dengan menggunakan ZRS, yang dilampirkan ke simpul mana pun yang saat ini berisi proses Mesin Database SQL aktif.

    Operasi tulis sinkron dan tidak dianggap selesai sampai data berhasil direplikasi di semua zona ketersediaan. Replikasi sinkron ini memastikan konsistensi yang kuat dan kehilangan data nol selama kegagalan zona. Namun, hal ini dapat mengakibatkan latensi tulis yang sedikit lebih tinggi dibandingkan dengan penyimpanan yang berlebihan secara lokal.

  • Perutean lalu lintas antar zona: Selama operasi normal, permintaan dirutekan ke replika utama instans terkelola SQL Anda.

  • Replikasi data antar zona: Replika utama terus-menerus dan secara berurutan mendorong perubahan pada replika sekunder di zona ketersediaan yang berbeda. Proses ini memastikan bahwa data dipertahankan pada jumlah replika sekunder yang memadai sebelum melakukan setiap transaksi. Replika tersebut terletak di zona ketersediaan yang berbeda. Proses ini menjamin bahwa, jika replika utama atau replika sekunder yang dapat dibaca menjadi tidak tersedia karena alasan apa pun, replika yang sepenuhnya disinkronkan selalu tersedia untuk failover.

    Karena instans zona-redundan memiliki replika di pusat data yang berbeda dengan jarak tertentu di antaranya, latensi jaringan yang meningkat dapat meningkatkan waktu komit transaksi. Peningkatan ini dapat memengaruhi performa beberapa beban kerja Pemrosesan Transaksi Online (OLTP). Sebagian besar aplikasi tidak sensitif terhadap latensi tambahan ini.

Perilaku selama kegagalan zona

Bagian ini menjelaskan apa yang diharapkan ketika instans terkelola SQL Anda dikonfigurasi menjadi zona redundan dan satu atau beberapa zona ketersediaan tidak tersedia:

  • Deteksi dan respons: SQL Managed Instance bertanggung jawab untuk mendeteksi dan merespons 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 layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.
  • Permintaan aktif: Ketika zona ketersediaan tidak tersedia, permintaan apa pun yang sedang diproses di zona ketersediaan yang rusak dihentikan dan harus dicoba kembali. Untuk membuat aplikasi Anda tahan terhadap jenis masalah ini, lihat Panduan ketahanan terhadap kesalahan sementara .

  • Pengalihan lalu lintas: SQL Managed Instance bekerja dengan Service Fabric untuk memindahkan mesin database ke simpul komputasi stateless yang sesuai yang berada di zona ketersediaan yang berbeda dan memiliki kapasitas bebas yang memadai. Setelah failover selesai, koneksi baru secara otomatis dialihkan ke simpul komputasi utama baru.

    Beban kerja yang berat mungkin mengalami beberapa penurunan performa selama transisi dari satu simpul komputasi ke simpul komputasi lainnya karena proses mesin database baru dimulai dengan cache dingin.

  • Pengalihan lalu lintas: SQL Managed Instance bekerja dengan Service Fabric untuk memilih replika yang sesuai di zona ketersediaan lain untuk menjadi replika utama. Setelah replika sekunder menjadi replika utama baru, replika sekunder lainnya dibuat untuk memastikan bahwa kluster memiliki jumlah replika yang memadai untuk mempertahankan kuorum. Setelah failover selesai, koneksi baru secara otomatis dialihkan ke replika utama baru, atau replika sekunder yang dapat dibaca, berdasarkan string koneksi.

  • Waktu henti yang diharapkan: Mungkin ada sedikit waktu henti ketika terjadi failover pada zona ketersediaan. Waktu henti biasanya kurang dari 30 detik, yang harus ditoleransi aplikasi Anda jika mengikuti panduan Ketahanan terhadap kesalahan sementara .

  • Kehilangan data yang diharapkan: Tidak ada kehilangan data yang diharapkan untuk transaksi yang dilakukan selama failover zona ketersediaan. Transaksi yang sedang berlangsung perlu dicoba kembali.

Pemulihan Zona

Ketika zona ketersediaan pulih, SQL Managed Instance bekerja dengan Service Fabric untuk memulihkan operasi di zona yang dipulihkan. Tidak diperlukan intervensi pelanggan.

Uji kegagalan zona

Platform SQL Managed Instance mengelola perutean lalu lintas, failover, dan failback untuk instans zona redundan. Karena fitur ini dikelola sepenuhnya, Anda tidak perlu memulai atau memvalidasi proses kegagalan zona ketersediaan. Namun, Anda dapat memvalidasi penanganan kegagalan aplikasi Anda.

Ketahanan terhadap kegagalan di seluruh wilayah

Sebuah SQL Managed Instance individual disebarkan dalam satu wilayah. Namun, Anda dapat menyebarkan instans terkelola SQL sekunder di wilayah Azure terpisah dan mengonfigurasi grup failover.

Grup failover

Grup failover secara otomatis mereplikasi data Anda secara geografis dan dapat secara otomatis atau manual melakukan failover jika kegagalan regional terjadi, berdasarkan kebijakan failover yang ditentukan.

Bagian ini meringkas informasi utama tentang grup failover, tetapi penting untuk meninjau ringkasan grup Failover dan praktik terbaik untuk mempelajari selengkapnya tentang cara kerjanya dan cara mengonfigurasinya.

Kebijakan failover

Saat membuat grup failover, Anda memilih kebijakan failover, yang menentukan siapa yang bertanggung jawab untuk mendeteksi pemadaman dan melakukan failover. Anda dapat mengonfigurasi dua jenis kebijakan failover:

  • Failover yang dikelola pelanggan (disarankan): Saat Anda menggunakan kebijakan failover yang dikelola pelanggan, Anda dapat memutuskan apakah akan melakukan failover, yang tidak menimbulkan kehilangan data, atau failover paksa, yang mungkin menyebabkan kehilangan data. Failover paksa digunakan sebagai metode pemulihan selama pemadaman ketika instans utama tidak dapat diakses.

  • Failover yang dikelola Microsoft: Failover yang dikelola Microsoft hanya digunakan dalam situasi luar biasa untuk memicu failover paksa.

Penting

Gunakan opsi failover yang dikelola pelanggan untuk mengembangkan, menguji, dan mengimplementasikan rencana DR Anda. Jangan mengandalkan failover yang dikelola Microsoft, yang mungkin hanya digunakan dalam keadaan ekstrem. Failover yang dikelola oleh Microsoft kemungkinan besar dimulai untuk seluruh wilayah. Ini tidak dapat dimulai untuk grup failover individual, instans SQL yang dikelola, langganan, atau pelanggan. Failover mungkin terjadi pada waktu yang berbeda untuk layanan Azure yang berbeda. Kami menyarankan agar Anda menggunakan failover yang dikelola pelanggan.

Dukungan wilayah

Anda dapat memilih wilayah Azure apa pun untuk instans terkelola SQL dalam grup failover. Karena latensi jaringan area luas yang tinggi, replikasi geografis menggunakan mekanisme replikasi asinkron. Untuk mengurangi penundaan jaringan, pilih wilayah yang memiliki koneksi latensi rendah. Untuk informasi selengkapnya tentang latensi antar wilayah Azure, lihat Statistik latensi pulang pergi jaringan Azure.

Biaya

Saat Anda membuat beberapa instans terkelola SQL di wilayah yang berbeda, Anda akan ditagih untuk setiap instans terkelola SQL.

Namun, jika instans sekunder Anda tidak memiliki beban kerja baca atau aplikasi yang terhubung ke instans tersebut, Anda dapat menghemat biaya lisensi dengan menunjuk replika sebagai instans siaga. Untuk informasi selengkapnya, lihat Mengonfigurasi replika siaga bebas lisensi untuk SQL Managed Instance.

Untuk informasi selengkapnya tentang harga SQL Managed Instance, lihat Informasi harga layanan.

Mengonfigurasi dukungan multiregional

Untuk mempelajari cara mengonfigurasi grup failover, lihat Mengonfigurasi grup failover untuk SQL Managed Instance.

Perencanaan dan manajemen kapasitas

Selama failover, lalu lintas dialihkan ke instans terkelola SQL sekunder. Penting bahwa instans terkelola SQL sekunder Anda siap untuk menerima lalu lintas. Buat instans terkelola SQL sekunder dengan tingkat layanan, pembuatan perangkat keras, dan ukuran komputasi yang sama dengan instans utama.

Untuk informasi selengkapnya tentang penskalaan instans terkelola SQL dalam grup failover, lihat Menskalakan instans.

Perilaku ketika semua wilayah sehat

Bagian ini menjelaskan apa yang diharapkan ketika instans terkelola SQL dikonfigurasi untuk menggunakan grup failover multi-wilayah dan semua wilayah beroperasi:

  • Perutean lalu lintas antar wilayah: Selama operasi normal, permintaan baca-tulis masuk ke satu instans utama di wilayah utama.

    Grup failover juga menyediakan titik akhir listener baca-saja terpisah. Selama operasi normal, titik akhir ini terhubung ke basis data sekunder untuk merutekan lalu lintas yang hanya bisa dibaca yang ditentukan dalam string koneksi.

    Untuk informasi selengkapnya tentang cara grup failover mengirim lalu lintas ke setiap instans dan bagaimana Anda dapat mengarahkan lalu lintas ke titik akhir pendengar baca-saja, lihat Gambaran umum grup failover dan praktik terbaik.

  • Replikasi data antar wilayah: Secara default, data direplikasi secara asinkron dari instans utama ke instans terkelola SQL sekunder.

    Karena replikasi geografis tidak sinkron, jika Anda melakukan failover paksa, anda dapat mengalami kehilangan data. Anda dapat memantau lag replikasi untuk memahami potensi kehilangan data selama failover paksa. Untuk informasi selengkapnya, lihat Daftar periksa DR.

    Jika Anda perlu menghilangkan kehilangan data dari replikasi asinkron selama failover, konfigurasikan aplikasi Anda untuk memblokir utas panggilan sampai mengonfirmasi bahwa transaksi terakhir yang dilakukan telah ditransmisikan dan diperkuat dalam log transaksi database sekunder. Pendekatan ini memerlukan pengembangan kustom dan menurunkan performa aplikasi Anda. Untuk informasi selengkapnya, lihat Mencegah hilangnya data penting.

Perilaku selama kegagalan wilayah

Bagian ini menjelaskan apa yang diharapkan ketika instans terkelola SQL dikonfigurasi untuk menggunakan grup failover multi-wilayah dan ada pemadaman di wilayah utama:

  • Deteksi dan respons: Tanggung jawab untuk deteksi dan respons tergantung pada kebijakan failover yang digunakan grup failover Anda.

    • Kebijakan failover yang dikelola pelanggan: Anda bertanggung jawab untuk mendeteksi kegagalan di suatu wilayah dan memicu failover atau failover paksa ke instans sekunder dalam grup failover.

      Jika Anda melakukan failover, SQL Managed Instance menunggu data disinkronkan ke instans sekunder sebelum melakukan prosedur failover.

      Jika Anda melakukan failover paksa, SQL Managed Instance segera mengalihkan instans sekunder ke peran utama tanpa menunggu perubahan terbaru untuk disebarluaskan dari primer. Jenis failover ini dapat menimbulkan kehilangan data.

    • Kebijakan failover yang dikelola Microsoft: Failover yang dikelola Microsoft dilakukan dalam keadaan luar biasa. Saat Microsoft memicu failover, grup failover secara otomatis melakukan failover paksa ke instans sekunder dalam grup failover. Namun, sebaiknya gunakan kebijakan failover yang dikelola pelanggan untuk beban kerja produksi sehingga Anda dapat mengontrol kapan failover terjadi.

  • 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 layanan secara keseluruhan, termasuk kegagalan zona apa pun, dan Anda dapat menyiapkan pemberitahuan Service Health untuk memberi tahu Anda tentang masalah.

  • Permintaan aktif: Ketika failover terjadi, setiap permintaan yang sedang diproses dihentikan dan harus dicoba kembali. Untuk membuat aplikasi Anda tahan terhadap jenis masalah ini, lihat Ketahanan terhadap kesalahan sementara.

  • Kehilangan data yang diharapkan: Jumlah kehilangan data tergantung pada cara Anda mengonfigurasi aplikasi Anda. Untuk informasi lebih lanjut, lihat Ikhtisar grup failover dan praktik terbaik.

  • Perkiraan waktu henti: Mungkin terdapat sedikit waktu henti selama failover grup. Waktu henti biasanya kurang dari 60 detik.

  • Pengalihan lalu lintas: Setelah grup failover menyelesaikan proses failover, lalu lintas baca-tulis dirutekan ke instans utama baru secara otomatis. Jika aplikasi Anda menggunakan titik akhir grup failover dalam string koneksinya, aplikasi tidak perlu memodifikasi string koneksi mereka setelah failover.

Pemulihan wilayah

Grup failover tidak secara otomatis beralih kembali ke wilayah utama setelah dipulihkan, sehingga Anda bertanggung jawab untuk memulai failback.

Pengujian untuk mendeteksi kegagalan wilayah

Anda dapat menguji failover kelompok failover.

Menguji grup failover hanyalah satu bagian dari melakukan latihan DR. Untuk informasi selengkapnya, lihat Melakukan latihan DR.

Pencadangan dan pemulihan

Ambil cadangan database Anda untuk melindungi dari berbagai risiko, termasuk hilangnya data. Cadangan dapat dipulihkan untuk pulih dari kehilangan data yang tidak disengaja, kerusakan, atau masalah lainnya. Pencadangan tidak sama dengan replikasi geografis, dan mereka memiliki tujuan yang berbeda dan mengurangi risiko yang berbeda.

SQL Managed Instance secara otomatis mengambil cadangan penuh, diferensial, dan log transaksi dari database Anda. Untuk informasi selengkapnya tentang jenis cadangan, frekuensinya, kemampuan pemulihan, biaya penyimpanan, dan enkripsi cadangan, lihat Pencadangan otomatis di SQL Managed Instance.

SQL Managed Instance menyediakan pencadangan otomatis bawaan dan juga mendukung pencadangan hanya salin yang diinisiasi pengguna untuk database pengguna. Untuk informasi selengkapnya, lihat Pencadangan khusus salin.

Replikasi cadangan

Saat mengonfigurasi pencadangan otomatis untuk instans terkelola SQL, Anda dapat menentukan bagaimana cadangan harus direplikasi. Cadangan yang dikonfigurasi untuk disimpan di ZRS memiliki tingkat ketahanan yang lebih tinggi. Kami menyarankan agar Anda mengonfigurasi cadangan untuk menggunakan salah satu jenis penyimpanan berikut:

  • ZRS untuk ketahanan dalam wilayah, jika wilayah memiliki zona ketersediaan

  • GZRS untuk meningkatkan ketahanan cadangan Anda di seluruh wilayah jika wilayah memiliki zona ketersediaan dan dipasangkan dengan wilayah lain

  • GRS jika wilayah Anda tidak mendukung zona ketersediaan tetapi memiliki wilayah berpasangan

Untuk informasi selengkapnya tentang berbagai jenis penyimpanan dan kemampuannya, lihat Redundansi penyimpanan cadangan.

Pemulihan Data Geografis

Kemampuan pemulihan geografis adalah solusi DR dasar yang memungkinkan Anda memulihkan salinan cadangan ke wilayah Azure yang berbeda. Pencadangan geografis biasanya memerlukan sejumlah besar waktu henti dan kehilangan data. Untuk mencapai tingkat pemulihan yang lebih tinggi jika gangguan regional terjadi, Anda harus mengonfigurasi grup failover.

Jika Anda menggunakan pemulihan geografis, Anda perlu mempertimbangkan cara membuat cadangan Anda tersedia di wilayah sekunder Anda:

  • Jika wilayah utama Anda dipasangkan, gunakan penyimpanan cadangan GZRS atau GRS untuk mendukung pemulihan geografis ke wilayah yang dipasangkan.

  • Jika wilayah utama Anda tidak dipasangkan, Anda dapat membangun solusi kustom untuk mereplikasi cadangan Anda ke wilayah lain. Pertimbangkan untuk menggunakan cadangan khusus salinan yang dimulai pengguna dan menyimpannya di akun penyimpanan yang menggunakan replikasi objek blob untuk mereplikasi ke akun penyimpanan di wilayah lain.

Ketahanan terhadap pemeliharaan layanan

Saat SQL Managed Instance melakukan pemeliharaan pada instans Anda, instans terkelola SQL tetap tersedia sepenuhnya tetapi dapat tunduk pada konfigurasi ulang singkat. Aplikasi klien mungkin mengamati gangguan konektivitas singkat saat peristiwa pemeliharaan terjadi. Aplikasi klien Anda harus mengikuti panduan Ketahanan terhadap kesalahan sementara untuk meminimalkan efeknya.

SQL Managed Instance memungkinkan Anda menentukan jendela pemeliharaan yang umumnya digunakan untuk peningkatan layanan dan operasi pemeliharaan lainnya. Mengonfigurasi jendela pemeliharaan dapat membantu Anda meminimalkan efek samping apa pun, seperti failover otomatis, selama jam kerja Anda. Anda juga dapat menerima pemberitahuan terlebih dahulu tentang pemeliharaan terencana.

Untuk informasi selengkapnya, lihat Jendela pemeliharaan di SQL Managed Instance.

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 SQL Managed Instance, SLA ketersediaan hanya berlaku saat jaringan virtual Azure Anda dikonfigurasi dengan benar sehingga tidak menghambat lalu lintas manajemen. Konfigurasi ini mencakup ukuran subnet, kelompok keamanan jaringan (NSG), rute yang ditentukan pengguna (UDR), konfigurasi DNS, dan sumber daya lain yang memengaruhi manajemen dan penggunaan sumber daya jaringan. Untuk informasi selengkapnya tentang konfigurasi jaringan yang diperlukan untuk SQL Managed Instance, lihat Persyaratan jaringan.

Konten terkait

  • Last updated on