Gambaran umum grup failover & praktik terbaik - Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL Managed Instance

Fitur grup failover memungkinkan Anda mengelola replikasi dan failover semua database pengguna dalam instans terkelola ke wilayah Azure lain. Artikel ini memberikan gambaran umum tentang fitur grup failover dengan praktik terbaik dan rekomendasi untuk menggunakannya dengan Azure SQL Managed Instance.

Untuk mulai menggunakan fitur ini, tinjau Mengonfigurasi grup failover untuk Azure SQL Managed Instance.

Gambaran Umum

Fitur grup failover memungkinkan Anda mengelola replikasi dan failover database pengguna dalam instans terkelola ke instans terkelola di wilayah Azure lain. Grup failover dirancang untuk menyederhanakan penyebaran dan manajemen database yang direplikasi secara geografis dalam skala besar.

Untuk informasi selengkapnya, lihat Ketersediaan tinggi untuk Azure SQL Managed Instance. Untuk RPO geo-failover dan RTO, lihat gambaran umum kelangsungan bisnis.

Pengalihan titik akhir

Grup failover menyediakan titik akhir pendengar baca-tulis dan baca-saja yang tetap tidak berubah selama geo-failover. Anda tidak perlu mengubah string koneksi untuk aplikasi Anda setelah failover geografis, karena koneksi secara otomatis dirutekan ke primer saat ini. Geo-failover mengalihkan semua database sekunder dalam grup ke peran utama. Setelah geo-failover selesai, catatan DNS secara otomatis diperbarui untuk mengalihkan titik akhir ke wilayah baru.

Membongkar beban kerja baca-saja

Untuk mengurangi lalu lintas ke database utama Anda, Anda juga dapat menggunakan database sekunder dalam grup failover untuk membongkar beban kerja baca-saja. Gunakan pendengar baca-saja untuk mengarahkan lalu lintas baca-saja ke database sekunder yang dapat dibaca.

Memulihkan aplikasi

Untuk mencapai kelangsungan bisnis penuh, menambahkan redundansi basis data regional hanyalah bagian dari solusi. Memulihkan aplikasi (layanan) secara ujung-ke-ujung setelah kegagalan besar membutuhkan pemulihan semua komponen yang membentuk layanan dan layanan yang bergantung. Contoh komponen ini termasuk perangkat lunak klien (misalnya, browser dengan JavaScript khusus), front end web, penyimpanan, dan DNS. Sangat penting bahwa semua komponen tahan terhadap kegagalan yang sama dan tersedia dalam tujuan waktu pemulihan (RTO) aplikasi Anda. Oleh karena itu, Anda perlu mengidentifikasi semua layanan yang bergantung dan memahami jaminan dan kemampuan yang diberikan layanan tersebut. Kemudian, Anda harus mengambil langkah-langkah yang memadai untuk memastikan bahwa layanan Anda berfungsi selama failover layanan yang bergantung padanya.

Kebijakan failover

Grup failover mendukung dua kebijakan failover:

  • Dikelola pelanggan (disarankan) - Pelanggan dapat melakukan failover suatu grup ketika mereka melihat ada pemadaman tak terduga yang berdampak pada satu atau beberapa database dalam grup failover. Saat menggunakan alat baris perintah seperti PowerShell, Azure CLI, atau Rest API, nilai kebijakan failover untuk dikelola pelanggan adalah manual.
  • Dikelola Microsoft - Jika terjadi pemadaman yang meluas yang berdampak pada wilayah utama, Microsoft memulai failover semua grup failover yang terkena dampak yang kebijakan failover-nya dikonfigurasi agar dikelola Microsoft. Failover yang dikelola Microsoft tidak akan dimulai untuk grup failover individual atau subset grup failover di suatu wilayah. Saat menggunakan alat baris perintah seperti PowerShell, Azure CLI, atau Rest API, nilai kebijakan failover untuk dikelola Microsoft adalah automatic.

Setiap kebijakan failover memiliki serangkaian kasus penggunaan yang unik dan ekspektasi yang sesuai pada cakupan failover dan kehilangan data, seperti yang dirangkum tabel berikut:

Kebijakan failover Cakupan failover Gunakan huruf besar Potensi kehilangan data
Dikelola pelanggan
(Disarankan)		 Grup failover Satu atau beberapa database dalam grup failover terpengaruh oleh pemadaman dan menjadi tidak tersedia. Anda dapat memilih untuk melakukan failover. Ya
Dikelola Microsoft Semua grup failover di wilayah Pemadaman luas di pusat data, zona ketersediaan, atau wilayah menyebabkan tidak tersedianya database dan tim layanan Microsoft Azure SQL memutuskan untuk memicu failover paksa.
Gunakan opsi ini hanya ketika Anda ingin mendelegasikan tanggung jawab pemulihan bencana kepada Microsoft dan aplikasi ini toleran terhadap RTO (waktu henti) setidaknya satu jam atau lebih.		 Ya

Dikelola pelanggan

Pada kesempatan yang jarang terjadi, ketersediaan bawaan atau ketersediaan tinggi tidak cukup untuk mengurangi pemadaman, dan database Anda dalam grup failover mungkin tidak tersedia selama durasi yang tidak dapat diterima oleh perjanjian tingkat layanan (SLA) aplikasi menggunakan database. Database dapat tidak tersedia karena masalah yang dilokalkan hanya berdampak pada beberapa database, atau bisa berada di pusat data, zona ketersediaan, atau tingkat wilayah. Dalam salah satu kasus ini, untuk memulihkan kelangsungan bisnis, Anda dapat memulai failover paksa.

Mengatur kebijakan failover Anda ke yang dikelola pelanggan sangat disarankan, karena membuat Anda terkendali kapan harus memulai failover dan memulihkan kelangsungan bisnis. Anda dapat memulai failover saat melihat pemadaman tak terduga yang berdampak pada satu atau beberapa database dalam grup failover.

Dikelola Microsoft

Dengan kebijakan failover terkelola Microsoft, tanggung jawab pemulihan bencana didelegasikan ke layanan Azure SQL. Agar layanan Azure SQL memulai failover paksa, kondisi berikut harus dipenuhi:

  • Pusat data, zona ketersediaan, atau pemadaman tingkat wilayah yang disebabkan oleh peristiwa bencana alam, perubahan konfigurasi, bug perangkat lunak atau kegagalan komponen perangkat keras dan banyak database di wilayah tersebut terpengaruh.
  • Masa tenggang kedaluwarsa. Karena memverifikasi skala, dan mengurangi, pemadaman tergantung pada tindakan manusia, masa tenggang tidak dapat diatur di bawah satu jam.

Ketika kondisi ini terpenuhi, layanan Azure SQL memulai failover paksa untuk semua grup failover di wilayah yang memiliki kebijakan failover yang diatur ke dikelola Microsoft.

Atur kebijakan failover ke Microsoft yang dikelola hanya saat:

  • Anda ingin mendelegasikan tanggung jawab pemulihan bencana ke layanan Azure SQL.
  • Aplikasi ini toleran terhadap database Anda yang tidak tersedia setidaknya selama satu jam atau lebih.
  • Dapat diterima untuk memicu failover paksa beberapa waktu setelah masa tenggang berakhir karena waktu aktual untuk failover paksa dapat bervariasi secara signifikan.
  • Dapat diterima bahwa semua database dalam grup failover gagal, terlepas dari konfigurasi redundansi zona atau status ketersediaannya. Meskipun database yang dikonfigurasi untuk redundansi zona tahan terhadap kegagalan zonal dan mungkin tidak terpengaruh oleh pemadaman, database tersebut masih akan gagal jika merupakan bagian dari grup failover dengan kebijakan failover terkelola Microsoft.
  • Dapat diterima untuk memaksa failover database dalam grup failover tanpa mempertimbangkan dependensi aplikasi pada layanan atau komponen Azure lainnya yang digunakan oleh aplikasi, yang dapat menyebabkan penurunan performa atau tidak tersedianya aplikasi.
  • Dapat diterima untuk menimbulkan jumlah kehilangan data yang tidak diketahui, karena waktu yang tepat dari failover paksa tidak dapat dikontrol, dan mengabaikan status sinkronisasi database sekunder.
  • Semua database utama dan sekunder dalam grup failover memiliki tingkat layanan yang sama, tingkat komputasi (disediakan atau tanpa server) & ukuran komputasi (DTU atau vCore). Jika tujuan tingkat layanan (SLO) dari semua database dalam grup failover tidak cocok, maka kebijakan failover pada akhirnya akan diperbarui dari layanan Microsoft Managed to Customer Managed by Azure SQL.

Saat failover dipicu oleh Microsoft, entri untuk nama operasi Failover Grup failover Azure SQL ditambahkan ke log aktivitas Azure Monitor. Entri menyertakan nama grup failover di bawah Sumber Daya, dan Peristiwa yang dimulai dengan menampilkan satu tanda hubung (-) untuk menunjukkan failover dimulai oleh Microsoft. Informasi ini juga dapat ditemukan di halaman Log aktivitas server utama atau instans baru di portal Azure.

Terminologi dan kemampuan

  • Grup failover (FOG)

    Grup failover memungkinkan semua database pengguna dalam instans terkelola mengalami failover sebagai unit ke wilayah Azure lain jika instans terkelola utama menjadi tidak tersedia karena pemadaman wilayah utama. Karena grup failover untuk SQL Managed Instance berisi semua database pengguna dalam instans, hanya satu grup failover yang dapat dikonfigurasi pada suatu instans.

    Penting

    Nama grup failover harus unik secara global dalam domain .database.windows.net.

  • Primer

    Instans terkelola yang menghosting database utama dalam grup failover.

  • Sekunder

    Instans terkelola yang menghosting database sekunder dalam grup failover. Sekunder tidak boleh berada di wilayah Azure yang sama dengan yang utama.

    Penting

    • Jika database berisi objek OLTP dalam memori, instans geo-replika primer dan sekunder harus memiliki tingkat layanan yang cocok, karena objek OLTP dalam memori berada dalam memori. Tingkat layanan yang lebih rendah pada instans geo-replika dapat mengakibatkan masalah di luar memori. Jika ini terjadi, replika sekunder mungkin gagal memulihkan database, menyebabkan tidak tersedianya database sekunder bersama dengan objek OLTP dalam memori pada geo-sekunder. Ini, pada gilirannya, dapat menyebabkan failover juga gagal. Untuk menghindari hal ini, pastikan tingkat layanan instans geo-sekunder cocok dengan database utama. Peningkatan tingkat layanan dapat berupa operasi ukuran data dan dapat memakan waktu cukup lama untuk diselesaikan.

  • Failover (tidak ada kehilangan data)

    Failover melakukan sinkronisasi data penuh antara database primer dan sekunder sebelum sekunder beralih ke peran utama. Hal ini menjamin tidak ada data yang hilang. Failover hanya dimungkinkan ketika primer dapat diakses. Failover digunakan dalam skenario berikut:

    • Melakukan latihan pemulihan bencana (DR) dalam produksi saat kehilangan data tidak dapat diterima
    • Merelokasi beban kerja ke wilayah lain
    • Mengembalikan beban kerja ke wilayah utama setelah pemadaman dimitigasi (failback)

  • Failover paksa (potensi kehilangan data)

    Failover paksa segera mengalihkan sekunder ke peran utama tanpa menunggu perubahan terbaru untuk disebarluaskan dari primer. Operasi ini dapat mengakibatkan potensi kehilangan data. Failover paksa digunakan sebagai metode pemulihan selama pemadaman saat primer tidak dapat diakses. Ketika pemadaman dikurangi, primer lama akan secara otomatis terhubung kembali dan menjadi sekunder baru. Failover dapat dieksekusi untuk melakukan failback, mengembalikan replika ke peran utama dan sekunder aslinya.

  • Masa tenggang dengan kehilangan data

    Karena data direplikasi ke sekunder menggunakan replikasi asinkron, failover paksa grup dengan kebijakan failover terkelola Microsoft dapat mengakibatkan kehilangan data. Anda dapat menyesuaikan kebijakan failover untuk mencerminkan toleransi aplikasi Anda terhadap kehilangan data. Dengan mengonfigurasi GracePeriodWithDataLossHours, Anda dapat mengontrol berapa lama layanan Azure SQL menunggu sebelum memulai failover paksa, yang dapat mengakibatkan kehilangan data.

  • Zona DNS

    ID unik yang dibuat secara otomatis saat Azure SQL Managed Instance baru dibuat. Sertifikat multi-domain (SAN) untuk instans ini disediakan untuk mengautentikasi koneksi klien ke instans apa pun di zona DNS yang sama. Dua instans terkelola dalam grup failover yang sama harus berbagi zona DNS.

  • Pendengar baca-tulis grup failover

    Data CNAME DNS yang menunjuk ke URL utama saat ini. Ini dibuat secara otomatis ketika grup failover dibuat dan memungkinkan beban kerja baca-tulis untuk terhubung kembali secara transparan ke primer ketika primer berubah setelah failover. Ketika grup failover dibuat pada Azure SQL Managed Instance, data CNAME DNS untuk URL pendengar dibentuk sebagai <fog-name>.<zone_id>.database.windows.net.

  • Pendengar baca-saja grup failover

    Data CNAME DNS yang menunjuk ke URL utama saat ini. Ini dibuat secara otomatis ketika grup failover dibuat dan memungkinkan beban kerja SQL baca-saja untuk terhubung secara transparan ke sekunder ketika sekunder berubah setelah failover. Ketika grup failover dibuat pada Azure SQL Managed Instance, data CNAME DNS untuk URL pendengar dibentuk sebagai <fog-name>.secondary.<zone_id>.database.windows.net. Secara default, failover pendengar baca-saja dinonaktifkan karena memastikan performa primer tidak terpengaruh saat sekunder offline. Namun, itu juga berarti sesi baca-saja tidak akan dapat terhubung sampai sekunder dipulihkan. Jika Anda tidak dapat mentolerir waktu henti untuk sesi baca-saja dan dapat menggunakan yang utama untuk lalu lintas baca-saja dan baca-tulis dengan mengorbankan potensi penurunan performa primer, Anda dapat mengaktifkan failover untuk pendengar baca-saja dengan mengonfigurasi AllowReadOnlyFailoverToPrimary properti. Dalam hal ini, lalu lintas baca-saja secara otomatis dialihkan ke primer jika sekunder tidak tersedia.

    Catatan

    Properti AllowReadOnlyFailoverToPrimary hanya berpengaruh jika kebijakan failover terkelola Microsoft diaktifkan dan failover paksa telah dipicu. Dalam hal ini, jika properti diatur ke Benar, primer baru akan melayani sesi baca-tulis dan baca-saja.

Arsitektur grup failover

Grup failover harus dikonfigurasi pada instans utama dan akan menghubungkannya ke instans sekunder di wilayah Azure yang berbeda. Semua database pengguna dalam instans akan direplikasi ke instans sekunder. Database sistem seperti master dan msdb tidak akan direplikasi.

Diagram berikut mengilustrasikan konfigurasi umum aplikasi cloud geo-redundan menggunakan instans terkelola dan grup failover:

diagram grup failover untuk Azure SQL Managed Instance.

Jika aplikasi Anda menggunakan Azure SQL Managed Instance sebagai tingkat data, ikuti panduan umum dan praktik terbaik yang ditulis dalam artikel ini ketika merancang kelangsungan bisnis.

Membuat instans geo-sekunder

Untuk memastikan konektivitas yang tidak terganggu ke SQL Managed Instance utama setelah failover, instans primer dan sekunder harus berada di zona DNS yang sama. Ini menjamin bahwa sertifikat multi-domain (SAN) yang sama dapat digunakan untuk mengautentikasi koneksi klien ke salah satu dari dua instans dalam grup failover. Saat aplikasi Anda siap untuk penyebaran produksi, buat SQL Managed Instance sekunder di wilayah yang berbeda, dan pastikan aplikasi tersebut berbagi zona DNS dengan SQL Managed Instance utama. Anda dapat melakukannya dengan menentukan parameter opsional selama pembuatan. Jika Anda menggunakan PowerShell atau REST API, nama parameter opsional adalah DNSZonePartner. Nama bidang opsional yang sesuai di portal Azure adalah Contoh Terkelola Utama.

Penting

Instance terkelola pertama yang dibuat di subnet menentukan zona DNS untuk semua contoh berikutnya dalam subnet yang sama. Ini berarti bahwa dua instans dari subnet yang sama tidak dapat termasuk dalam zona DNS yang berbeda.

Untuk informasi selengkapnya tentang membuat SQL Managed Instance sekunder di zona DNS yang sama dengan instans utama, lihat Mengonfigurasi grup failover untuk Azure SQL Managed Instance.

Gunakan wilayah berpasangan

Sebarkan kedua instans terkelola ke wilayah yang dipasangkan karena alasan performa. SQL Grup failover Instans Terkelola di wilayah berpasangan memiliki kinerja yang lebih baik dibandingkan dengan wilayah yang tidak berpasangan.

Azure SQL Managed Instance mengikuti praktik penyebaran yang aman di mana wilayah berpasangan Azure umumnya tidak disebarkan secara bersamaan. Namun, tidak mungkin untuk memprediksi wilayah mana yang akan ditingkatkan terlebih dahulu, sehingga urutan penyebaran tidak dijamin. Terkadang, instans utama Anda ditingkatkan terlebih dahulu, dan terkadang instans sekunder ditingkatkan terlebih dahulu.

Dalam situasi di mana Azure SQL Managed Instance adalah bagian dari grup failover, dan instans dalam grup tidak berada di wilayah berpasangan Azure, pilih jadwal jendela pemeliharaan yang berbeda untuk database utama dan sekunder Anda. Misalnya, pilih jendela pemeliharaan Hari Kerja untuk database geo-sekunder Anda dan jendela pemeliharaan Akhir Pekan untuk database geo-primer Anda.

Mengaktifkan dan mengoptimalkan arus lalu lintas replikasi geografis antar instans

Koneksi ivitas antara subnet jaringan virtual yang menghosting instans primer dan sekunder harus dibuat dan dikelola untuk arus lalu lintas replikasi geografis yang tidak terganggu. Ada beberapa cara untuk menyediakan konektivitas antara instans yang dapat Anda pilih di antaranya berdasarkan topologi dan kebijakan jaringan Anda:

Peering jaringan virtual global (peering VNet) adalah cara yang disarankan untuk membangun konektivitas antara dua instans dalam grup failover. Cara ini menyediakan latensi rendah, koneksi privat bandwidth tinggi antara jaringan virtual yang di-peering menggunakan infrastruktur backbone Microsoft. Tidak ada Internet publik, gateway, atau enkripsi tambahan yang diperlukan dalam komunikasi antara jaringan virtual yang di-peering.

Seeding awal

Saat membuat grup failover antara instans terkelola, ada fase seeding awal sebelum replikasi data dimulai. Fase penyemaian awal adalah bagian terpanjang dan termahal dari operasi. Setelah penyemaian awal menyelesaikan data disinkronkan, dan hanya perubahan data berikutnya yang direplikasi. Waktu yang diperlukan agar penyemaian awal selesai tergantung pada ukuran data, jumlah database yang direplikasi, intensitas beban kerja pada database utama, dan kecepatan tautan antara jaringan virtual yang menghosting instans primer dan sekunder yang sebagian besar tergantung pada cara konektivitas dibuat. Dalam keadaan normal, dan ketika konektivitas dibuat menggunakan peering jaringan virtual global yang direkomendasikan, kecepatan penyemaian hingga 360 GB per jam untuk SQL Managed Instance. Penyemaian dilakukan untuk kumpulan database pengguna secara paralel - tidak harus untuk semua database secara bersamaan. Beberapa batch mungkin diperlukan jika ada banyak database yang dihosting pada instans.

Jika kecepatan tautan antara kedua instans lebih lambat dari yang diperlukan, waktu untuk seed kemungkinan akan terpengaruh secara nyata. Anda dapat menggunakan kecepatan seeding, jumlah database, ukuran total data, dan kecepatan tautan yang dinyatakan untuk memperkirakan berapa lama fase seeding awal akan berlangsung sebelum replikasi data dimulai. Misalnya, untuk database 100 GB tunggal, fase seed awal akan memakan waktu sekitar 1,2 jam jika tautan mampu mendorong 84 GB per jam, dan jika tidak ada database lain yang disemai. Jika tautan hanya dapat mentransfer 10 GB per jam, maka menyemai database 100 GB dapat memakan waktu sekitar 10 jam. Jika ada beberapa database untuk direplikasi, penyemaian akan dijalankan secara paralel, dan, ketika dikombinasikan dengan kecepatan tautan yang lambat, fase penyemaian awal mungkin memakan waktu jauh lebih lama, terutama jika penyemaian paralel data dari semua database melebihi bandwidth tautan yang tersedia.

Penting

Jika terjadi tautan berkecepatan sangat rendah atau sibuk yang menyebabkan fase seeding awal memakan waktu ber hari pembuatan grup failover dapat kehabisan waktu. Proses pembuatan akan dibatalkan secara otomatis setelah 6 hari.

Kelola failover geografis ke instans sekunder geografis

Grup failover mengelola geo-failover semua database pada instans terkelola utama. Ketika grup dibuat, setiap database dalam instans akan secara otomatis direplikasi secara geo ke SQL Managed Instance sekunder. Anda tidak dapat menggunakan grup failover untuk memulai failover parsial dari subset database.

Penting

Jika database dihapus dari SQL Managed Instance utama, database juga akan dihapus secara otomatis pada SQL Managed Instance sekunder geo.

Gunakan pendengar baca-tulis (MI utama)

Untuk beban kerja baca-tulis, gunakan <fog-name>.zone_id.database.windows.net sebagai nama server dalam string koneksi. Koneksi secara otomatis diarahkan ke primer. Nama ini tidak berubah setelah failover. Geo-failover melibatkan pembaruan catatan DNS, sehingga koneksi klien baru dirutekan ke primer baru hanya setelah cache DNS klien di-refresh. Karena instans sekunder berbagi zona DNS dengan primer, aplikasi klien akan dapat terhubung kembali ke sana menggunakan sertifikat SAN yang sama. Koneksi klien yang ada perlu dihentikan dan kemudian dibuat ulang untuk dirutekan ke primer baru. Pendengar baca-tulis dan pendengar baca-saja tidak dapat dijangkau melalui titik akhir publik untuk instans terkelola.

Gunakan pendengar baca-saja (MI sekunder)

Jika Anda memiliki beban kerja baca-saja yang terisolasi secara logis yang toleran terhadap latensi data, Anda dapat menjalankannya di geo-sekunder. Untuk terhubung langsung ke geo-sekunder, gunakan <fog-name>.secondary.<zone_id>.database.windows.net sebagai nama server.

Di tingkat Kritis untuk Bisnis, SQL Managed Instance mendukung penggunaan replika baca-saja untuk membongkar beban kerja kueri baca-saja, menggunakan parameter ApplicationIntent=ReadOnly dalam string koneksi. Jika telah mengonfigurasi lokasi sekunder geo-replikasi, Anda dapat menggunakan kemampuan ini untuk terhubung ke replika baca-saja di lokasi utama atau di lokasi geo-replikasi:

  • Untuk terhubung ke replika baca-saja di lokasi utama, gunakan ApplicationIntent=ReadOnly dan <fog-name>.<zone_id>.database.windows.net.
  • Untuk terhubung ke replika baca-saja di lokasi sekunder, gunakan ApplicationIntent=ReadOnly dan <fog-name>.secondary.<zone_id>.database.windows.net.

Pendengar baca-tulis dan pendengar baca-saja tidak dapat dijangkau melalui titik akhir publik untuk instans terkelola.

Potensi penurunan kinerja setelah failover

Aplikasi Azure yang khas menggunakan beberapa layanan Azure dan terdiri dari beberapa komponen. Failover geografis grup dipicu berdasarkan status komponen Azure SQL saja. Layanan Azure lainnya di wilayah utama mungkin tidak terpengaruh oleh pemadaman dan komponennya mungkin masih tersedia di wilayah tersebut. Setelah database utama beralih ke wilayah sekunder, latensi antara komponen dependen dapat meningkat. Pastikan redundansi semua komponen aplikasi di wilayah sekunder dan failover komponen aplikasi bersama dengan database sehingga performa aplikasi tidak terpengaruh oleh latensi lintas wilayah yang lebih tinggi.

Potensi kehilangan data setelah failover paksa

Jika pemadaman terjadi di wilayah utama, transaksi terbaru mungkin belum direplikasi ke geo-sekunder dan mungkin ada kehilangan data jika failover paksa dilakukan.

Pembaruan DNS

Pembaruan DNS pendengar baca-tulis akan terjadi segera setelah failover dimulai. Operasi ini tidak akan mengakibatkan kehilangan data. Namun, proses peralihan peran database dapat memakan waktu hingga 5 menit dalam kondisi normal. Hingga selesai, beberapa database dalam instans utama baru masih akan bersifat baca-saja. Jika failover dimulai menggunakan PowerShell, operasi untuk mengalihkan peran replika utama bersifat sinkron. Jika dimulai menggunakan portal Azure, UI menunjukkan status penyelesaian. Jika dimulai menggunakan REST API, gunakan mekanisme polling Azure Resource Manager standar untuk memantau penyelesaian.

Penting

Gunakan failover yang direncanakan manual untuk memindahkan bagian primer kembali ke lokasi asli setelah pemadaman yang menyebabkan geo-failover dikurangi.

Menghemat biaya dengan replika DR bebas lisensi

Anda dapat menghemat biaya lisensi SQL Server dengan mengonfigurasi instans terkelola sekunder Anda untuk digunakan hanya untuk pemulihan bencana (DR). Untuk menyiapkannya, lihat Mengonfigurasi replika siaga bebas lisensi untuk Azure SQL Managed Instance.

Selama instans sekunder tidak digunakan untuk beban kerja baca, Microsoft memberi Anda jumlah vCore gratis agar sesuai dengan instans utama. Anda masih dikenakan biaya untuk komputasi dan penyimpanan yang digunakan oleh instans sekunder. Grup failover hanya mendukung satu replika - replika harus berupa replika yang dapat dibaca, atau ditetapkan sebagai replika khusus DR.

Mengaktifkan skenario yang bergantung pada objek dari database sistem

Database sistem tidak direplikasi ke instans sekunder dalam grup failover. Untuk mengaktifkan skenario yang bergantung pada objek dari database sistem, pastikan untuk membuat objek yang sama pada instans sekunder dan tetap sinkronkan dengan instans utama.

Misalnya, jika Anda berencana untuk menggunakan login yang sama pada instans sekunder, pastikan untuk membuatnya dengan SID yang identik.

-- Code to create login on the secondary instance
CREATE LOGIN foo WITH PASSWORD = '<enterStrongPasswordHere>', SID = <login_sid>;

Untuk mempelajari selengkapnya, lihat Replikasi login dan pekerjaan agen.

Menyinkronkan properti instans dan instans kebijakan retensi

Instans dalam grup failover tetap memisahkan sumber daya Azure, dan tidak ada perubahan yang dilakukan pada konfigurasi instans primer akan secara otomatis direplikasi ke instans sekunder. Pastikan untuk melakukan semua perubahan yang relevan baik pada contoh primer dan sekunder. Misalnya, jika Anda mengubah redundansi penyimpanan cadangan atau kebijakan retensi cadangan jangka panjang pada contoh primer, pastikan untuk mengubahnya pada instans sekunder juga.

Menskalakan instans

Anda dapat meningkatkan atau menurunkan instans primer dan sekunder ke ukuran komputasi yang berbeda dalam tingkat layanan yang sama atau ke tingkat layanan yang berbeda. Saat meningkatkan skala dalam tingkat layanan yang sama, kami sarankan Anda meningkatkan skala geo-sekunder terlebih dahulu, lalu meningkatkan skala primer. Saat menurunkan skala dalam tingkat layanan yang sama, balikkan urutan: turunkan skala primer terlebih dahulu, lalu turunkan skala sekunder. Saat Anda menskalakan instans ke tingkat layanan yang berbeda, rekomendasi ini diberlakukan. Urutan operasi diberlakukan saat menskalakan tingkat layanan dan vCore, serta penyimpanan.

Urutan ini direkomendasikan khususnya untuk menghindari masalah di mana instans sekunder di SKU yang lebih rendah mengalami kelebihan beban dan harus ditambahkan kembali selama proses peningkatan atau penurunan.

Catatan

Ada masalah umum yang dapat memengaruhi aksesibilitas instans yang diskalakan menggunakan pendengar grup failover terkait.

Mencegah hilangnya data penting

Dikarenakan latensi jaringan area luas yang tinggi, salinan berkelanjutan menggunakan mekanisme replikasi asinkron. Replikasi asinkron membuat kemungkinan kehilangan data tidak dapat dihindari jika primer gagal. Untuk melindungi pembaruan penting ini, pengembang aplikasi dapat memanggil prosedur sistem sp_wait_for_database_copy_sync segera setelah melakukan transaksi. Memanggil sp_wait_for_database_copy_sync akan memblokir utas panggilan hingga transaksi terakhir yang dilakukan telah dikirim ke database sekunder. Namun, tidak menunggu transaksi yang dikirimkan diputar ulang (redone) pada sekunder. sp_wait_for_database_copy_sync dicakup ke tautan geo-replikasi tertentu. Setiap pengguna dengan hak koneksi ke database utama dapat memanggil prosedur ini.

Untuk mencegah kehilangan data selama geo-failover yang dimulai pengguna, direncanakan, replikasi secara otomatis dan sementara berubah menjadi replikasi sinkron, lalu melakukan failover. Replikasi kemudian kembali ke mode asinkron setelah geo-failover selesai.

Catatan

sp_wait_for_database_copy_sync mencegah kehilangan data setelah geo-failover untuk transaksi tertentu, tetapi tidak menjamin sinkronisasi penuh untuk akses baca. Keterlambatan yang disebabkan oleh panggilan sp_wait_for_database_copy_sync prosedur dapat menjadi signifikan dan bergantung pada ukuran log transaksi pada saat panggilan.

Status grup failover

Grup failover melaporkan statusnya yang menjelaskan status replikasi data saat ini:

  • Seeding- Seeding awal terjadi setelah pembuatan grup failover, hingga semua database pengguna diinsialisasi pada instans sekunder. Proses failover tidak dapat dimulai saat grup failover berada dalam status Seeding, karena database pengguna belum disalin ke instans sekunder.
  • Menyinkronkan - status grup failover yang biasa. Ini berarti bahwa perubahan data pada instans utama direplikasi secara asinkron ke instans sekunder. Status ini tidak menjamin bahwa data disinkronkan sepenuhnya setiap saat. Mungkin ada perubahan data dari primer yang masih akan direplikasi ke sekunder karena sifat asinkron dari proses replikasi antara instans dalam grup failover. Failover otomatis dan manual dapat dimulai saat grup failover berada dalam status Sinkronisasi.
  • Failover sedang berlangsung - status ini menunjukkan bahwa proses failover yang dimulai secara otomatis atau manual sedang berlangsung. Tidak ada perubahan pada grup failover atau failover tambahan yang dapat dimulai saat grup failover berada dalam status ini.

Gagal kembali

Ketika grup failover dikonfigurasi dengan kebijakan failover yang dikelola Microsoft, maka failover paksa ke server geo-sekunder dimulai selama skenario bencana sesuai masa tenggang yang ditentukan. Failback ke primer lama harus dimulai secara manual.

Grup failover dengan replikasi transaksional

Menggunakan replikasi transaksional dengan instans yang berada dalam grup failover didukung. Namun, jika Anda mengonfigurasi replikasi sebelum menambahkan instans terkelola SQL Anda ke dalam grup failover, replikasi berhenti sementara saat Anda mulai membuat grup failover, dan monitor replikasi menunjukkan status Replicated transactions are waiting for the next log backup or for mirroring partner to catch up. Replikasi dilanjutkan setelah grup failover berhasil dibuat.

Jika penerbit atau distributor instans terkelola SQL berada dalam grup failover, administrator instans terkelola SQL harus membersihkan semua publikasi pada primer lama dan mengonfigurasi ulang pada primer baru setelah failover terjadi. Tinjau panduan replikasi transaksional untuk langkah aktivitas yang diperlukan dalam skenario ini.

Izin, batasan, dan prasyarat

Tinjau panduan grup failover konfigurasi untuk daftar izin, batasan, dan prasyarat sebelum melanjutkan untuk mengonfigurasi grup failover.

Mengelola grup failover secara terprogram

Grup failover juga dapat dikelola secara terprogram menggunakan Azure PowerShell, Azure CLI, dan REST API. Tinjau mengonfigurasi grup failover untuk mempelajari lebih lanjut.

Latihan pemulihan bencana

Cara yang disarankan untuk melakukan latihan DR menggunakan failover yang direncanakan manual, sesuai tutorial berikut: Uji failover.

Melakukan latihan menggunakan failover paksa tidak disarankan, karena operasi ini tidak menyediakan pagar pembatas terhadap kehilangan data. Namun demikian, dimungkinkan untuk mencapai failover paksa tanpa kehilangan data dengan memastikan kondisi berikut terpenuhi sebelum memulai failover paksa:

  • Beban kerja dihentikan pada instans terkelola utama.
  • Semua transaksi yang berjalan lama telah selesai.
  • Semua koneksi klien ke instans terkelola utama telah terputus.
  • Status grup failover adalah 'Menyinkronkan'.

Pastikan dua instans terkelola telah beralih peran dan bahwa status grup failover telah beralih dari 'Failover sedang berlangsung' ke 'Sinkronisasi' sebelum secara opsional membuat koneksi ke instans terkelola utama baru dan memulai beban kerja baca-tulis.

Untuk melakukan failback tanpa kehilangan data ke peran instans terkelola asli, menggunakan failover terencana manual alih-alih failover paksa sangat disarankan. Untuk melanjutkan dengan failback paksa:

  • Ikuti langkah-langkah yang sama seperti untuk failover tanpa kehilangan data.
  • Waktu eksekusi failback yang lebih lama diharapkan jika failback paksa dijalankan segera setelah failover paksa awal selesai, karena harus menunggu penyelesaian operasi pencadangan otomatis yang luar biasa pada instans terkelola utama sebelumnya.

Konten terkait