Gambaran umum grup failover otomatis &praktik terbaik (Azure SQL Managed Instance)

BERLAKU UNTUK: Azure SQL Managed Instance

• Azure SQL Database
• Instans Terkelola Azure SQL

Fitur grup failover otomatis memungkinkan Anda untuk mengelola replikasi dan failover semua database pengguna dalam instans terkelola ke wilayah Azure lain. Artikel ini berfokus pada penggunaan fitur grup failover otomatis dengan Azure SQL Managed Instance dan beberapa praktik terbaik.

Untuk memulai, tinjau Konfigurasikan grup failover otomatis. Untuk pengalaman end-to-end, lihat Tutorial grup failover otomatis.

Catatan

Artikel ini mencakup grup failover otomatis untuk Azure SQL Managed Instance. Untuk Azure SQL Database, lihat Grup failover otomatis di SQL Database.

Gambaran Umum

Fitur grup failover otomatis memperbolehkan Anda untuk mengelola replikasi serta failover dari grup database di server atau semua database pengguna dalam instans terkelola ke wilayah Azure lain. Ini adalah abstraksi deklaratif di atas fitur replikasi-geografis aktif, yang didesain untuk menyederhanakan penyebaran dan pengelolaan database dengan replikasi-geografis dalam skala besar.

Failover otomatis

Anda dapat memulai failover secara manual atau Anda dapat melimpahkannya ke layanan Azure berdasarkan kebijakan yang ditentukan pengguna. Opsi terakhir memungkinkan Anda secara otomatis memulihkan beberapa database terkait di wilayah sekunder setelah failover besar atau peristiwa tidak terencana lainnya yang mengakibatkan hilangnya sebagian atau seluruh SQL Database atau ketersediaan SQL Managed Instance di wilayah utama. Biasanya, ini adalah pemadaman yang tidak dapat secara otomatis dikurangi oleh infrastruktur ketersediaan tinggi bawaan. Contoh dari pemicu failover-geografis mencakup bencana alam, atau insiden yang disebabkan oleh penyewa atau cincin kontrol yang tidak berfungsi karena adanya kebocoran memori kernel OS pada node komputasi. Untuk informasi selengkapnya, lihat ketersediaan tinggi Azure SQL.

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.

Pengalihan titik akhir

Selain itu, grup failover otomatis menyediakan titik akhir pendengar baca-tulis dan baca-saja yang tidak berubah selama failover. Ini berarti Anda tidak perlu mengubah string koneksi untuk aplikasi Anda setelah failover-geografis, karena koneksi secara otomatis dirutekan menuju yang utama saat ini. Baik Anda menggunakan aktivasi failover manual atau otomatis, failover akan mengalihkan semua database sekunder di grup ke primer. Setelah failover database selesai, catatan DNS secara otomatis akan diperbarui untuk mengalihkan titik akhir ke wilayah baru. Untuk data RPO dan RTO tertentu, lihat Gambaran Umum Kelangsungan Bisnis.

Memulihkan aplikasi

Untuk mencapai kelangsungan bisnis penuh, menambahkan redundansi basis data regional hanyalah bagian dari solusi. Memulihkan aplikasi (layanan) secara end-to-end setelah kegagalan bencana membutuhkan pemulihan semua komponen yang merupakan layanan dan layanan dependen apa pun. Contoh komponen ini termasuk perangkat lunak klien (misalnya, browser dengan JavaScript kustom), ujung depan 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 tergantung dan memahami jaminan dan kemampuan yang mereka berikan. Kemudian, Anda harus mengambil langkah-langkah yang memadai untuk memastikan bahwa layanan Anda berfungsi selama kegagalan layanan yang bergantung padanya.

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 dapat berada di wilayah Azure yang sama dengan yang utama.

• 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 secara transparan terhubung kembali ke database utama ketika database utama 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 secara transparan terhubung ke sekunder menggunakan aturan penyeimbangan beban yang ditentukan. 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.

• Kebijakan failover otomatis

  Secara default, grup failover dikonfigurasi dengan kebijakan failover otomatis. Sistem memicu failover setelah geo-failover terdeteksi dan masa tenggang telah kedaluwarsa. Sistem harus memverifikasi bahwa pemadaman tidak bisa dimitigasi oleh infrastruktur ketersediaan tinggi bawaan karena skala dampaknya. Jika Anda ingin mengontrol alur kerja failover dari aplikasi atau secara manual, Anda dapat menonaktifkan failover otomatis.

  Catatan

  Karena verifikasi skala ketersediaan dan seberapa cepat hal tersebut dapat dikurangi memerlukan tindakan manusia, maka masa tenggang tidak dapat ditetapkan di bawah satu jam. Pembatasan ini berlaku untuk semua database dalam grup failover terlepas dari status sinkronisasi data mereka.

• Kebijakan failover baca-saja

  Secara default, failover pendengar baca-saja dinonaktifkan. Ini memastikan bahwa performa primer tidak terpengaruh ketika sekunder offline. Namun, itu juga berarti sesi baca-saja tidak akan dapat terhubung sampai sekunder pulih. Jika Anda tidak dapat mentolerir waktu henti untuk sesi baca-saja dan dapat menggunakan primer untuk lalu lintas baca-saja dan baca-tulis dengan mengorbankan potensi penurunan kinerja dari primer, Anda dapat mengaktifkan failover untuk pendengar baca-saja dengan mengonfigurasi properti AllowReadOnlyFailoverToPrimary. Dalam hal ini, lalu lintas baca-saja akan secara otomatis dialihkan ke primer jika sekunder tidak tersedia.

  Catatan

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

• Kegagalan terencana

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

  • Melakukan latihan pemulihan bencana (DR) dalam produksi ketika kehilangan data tidak dapat diterima
  • Merelokasi database ke wilayah lain
  • Mengembalikan database ke wilayah utama setelah pemadaman dimitigasi (dikembalikan)

• Kegagalan tidak terencana

  Failover yang tidak direncanakan atau dipaksakan segera mengalihkan peran sekunder ke peran utama tanpa menunggu perubahan terbaru menyebar dari peran utama. Operasi ini dapat mengakibatkan hilangnya data. Failover tidak terencana digunakan sebagai metode pemulihan selama pemadaman ketika primer tidak dapat diakses. Ketika pemadaman dikurangi, primer lama akan secara otomatis terhubung kembali dan menjadi sekunder baru. Sebuah failover yang direncanakan dapat dieksekusi untuk gagal kembali, mengembalikan replika ke peran utama dan sekunder aslinya.

• Failover manual

  Anda dapat memulai failover secara manual kapan saja terlepas dari konfigurasi failover otomatis. Selama pemadaman yang berdampak pada primer, jika kebijakan failover otomatis tidak dikonfigurasi, failover manual diperlukan untuk mempromosikan sekunder ke peran utama. Anda dapat memulai kegagalan yang dipaksakan (tidak direncanakan) atau ramah (terencana). Failover yang ramah hanya mungkin ketika primer lama dapat diakses, dan dapat digunakan untuk memindahkan primer ke wilayah sekunder tanpa kehilangan data. Ketika failover selesai, catatan DNS diperbarui secara otomatis untuk memastikan konektivitas ke primer baru.

• Masa tenggang dengan kehilangan data

  Karena data direplikasi ke database sekunder menggunakan replikasi asinkron, failover-geografis otomatis mungkin menyebabkan kehilangan data. Anda dapat menyesuaikan kebijakan failover otomatis untuk mencerminkan toleransi aplikasi Anda terhadap kehilangan data. Dengan mengonfigurasi GracePeriodWithDataLossHours, Anda dapat mengontrol berapa lama sistem harus menunggu sebelum memulai failover yang mungkin dapat menyebabkan kehilangan data.

Arsitektur grup failover

Grup failover otomatis 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 ini mengilustrasikan konfigurasi khusus aplikasi cloud geo-redundan menggunakan instans terkelola dan grup failover otomatis:

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.

Penting

Jika Anda menyebarkan grup failover otomatis di lintas wilayah topologi jaringan hub-and-spoke, lalu lintas replikasi harus langsung menuju antara dua subnet instans terkelola bukannya diarahkan melalui jaringan hub.

Seeding awal

Saat menambahkan instans terkelola ke grup failover, terdapat fase seeding awal sebelum replikasi data dimulai. Fase seeding awal adalah operasi terpanjang dan termahal. Setelah seeding awal selesai, data disinkronkan, dan hanya perubahan data berikutnya yang akan direplikasi. Waktu yang diperlukan untuk menyelesaikan seeding awal bergantung pada ukuran data Anda, jumlah basis data yang direplikasi, beban pada basis data primer, dan kecepatan tautan antara basis data primer dan sekunder. Dalam keadaan normal, kemungkinan kecepatan seeding mencapai 360 GB per jam untuk SQL Managed Instance. Seeding dilakukan untuk semua database secara paralel.

Untuk Azure SQL Managed Instance, pertimbangkan kecepatan tautan Rute Ekspres antara dua instans ketika memperkirakan waktu fase seeding awal. Jika kecepatan tautan antara kedua instans lebih lambat dari yang diperlukan, waktu untuk penambahan kemungkinan akan terpengaruh. 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 seeding awal akan memakan waktu sekitar 1,2 jam jika tautan mampu mencapai 84 GB per jam, dan jika tidak ada database lain yang ditambahkan. Jika tautan hanya dapat mentransfer 10 GB per jam, maka seeding untuk 100 GB database akan memakan waktu sekitar 10 jam. Jika ada beberapa database untuk direplikasi, seeding akan dijalankan secara paralel, dan, ketika dikombinasikan dengan kecepatan tautan yang lambat, fase seeding mungkin memakan waktu jauh lebih lama, terutama jika seeding paralel data dari semua database melebihi bandwidth tautan yang tersedia. Jika bandwidth jaringan antara dua instans terbatas dan Anda menambahkan beberapa instans terkelola ke grup failover, pertimbangkan untuk menambahkan beberapa instans terkelola ke grup failover secara berurutan, satu per satu. Mengingat SKU gateway berukuran tepat di antara dua instans terkelola, dan jika bandwidth jaringan perusahaan memungkinkannya, kecepatan dapat mencapai 360 GB per jam.

Membuat instans geo-sekunder

Untuk memastikan konektivitas yang tidak terganggu ke Azure SQL Managed Instance utama setelah failover instans utama dan sekunder harus berada di zona DNS yang sama. Ini akan menjamin bahwa sertifikat multi-domain (SAN) yang sama dapat digunakan untuk mengautentikasi koneksi klien ke salah satu dari dua contoh dalam grup failover. Ketika aplikasi Anda siap untuk penyebaran produksi, buat SQL Managed Instance sekunder di wilayah yang berbeda dan pastikan aplikasi 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 berada di zona DNS yang berbeda.

Untuk mengetahui informasi selengkapnya tentang membuat SQL Managed Instance sekunder di zona DNS yang sama dengan instans utama, lihat Membuat instans terkelola sekunder.

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.

Mengaktifkan lalu lintas replikasi-geo antara dua instans

Karena setiap instans diisolasi di VNet sendiri, lalu lintas dua arah antara VNet ini harus diizinkan. Lihat gateway Azure VPN

Mengelola geo-failover ke instans geo-sekunder

Grup failover akan 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 sebagian dari subkumpulan 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 akan secara otomatis diarahkan ke yang utama. Nama ini tidak berubah setelah failover. Perhatikan bahwa failover melibatkan pembaruan catatan DNS sehingga koneksi klien dialihkan ke primer baru hanya setelah cache DNS klien direfresh. Karena instans sekunder berbagi zona DNS dengan primer, aplikasi klien akan dapat terhubung kembali ke sana menggunakan sertifikat SAN yang sama. 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 yang dikelola.

Potensi penurunan kinerja setelah failover

Aplikasi Azure yang khas menggunakan beberapa layanan Azure dan terdiri dari beberapa komponen. Failover otomatis dari grup failover 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. Untuk menghindari dampak latensi yang lebih tinggi pada kinerja aplikasi, pastikan redundansi semua komponen aplikasi di wilayah sekunder dan gagal atas komponen aplikasi bersama dengan database.

Potensi kehilangan data setelah failover

Jika pemadaman terjadi di wilayah primer, transaksi baru-baru ini mungkin tidak dapat mereplikasi ke geo-sekunder. Failover ditangguhkan untuk periode yang Anda tentukan dengan menggunakan GracePeriodWithDataLossHours. Jika Anda mengonfigurasi kebijakan failover otomatis, bersiaplah untuk kehilangan data. Secara umum, selama pemadaman, Azure mendukung ketersediaan. Pengaturan GracePeriodWithDataLossHours ke jumlah yang lebih besar, seperti 24 jam, atau menonaktifkan geo-failover otomatis memungkinkan Anda mengurangi kemungkinan kehilangan data dengan mengorbankan ketersediaan basis data.

Pembaruan DNS

Pembaruan DNS pendengar baca-tulis akan terjadi segera setelah failover dimulai. Operasi ini tidak akan mengakibatkan hilangnya data. Namun, proses peralihan peran database dapat memakan waktu hingga 5 menit dalam kondisi normal. Hingga proses ini selesai, beberapa database dalam contoh utama baru masih akan baca-saja. Jika failover dimulai menggunakan PowerShell, operasi untuk mengalihkan peran replika utama bersifat sinkron. Jika dimulai menggunakan portal Microsoft Azure, antarmuka pengguna akan 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.

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.

Menggunakan grup failover dan titik akhir layanan jaringan virtual

Jika Anda menggunakan titik akhir dan aturan layanan Virtual Network untuk membatasi akses ke SQL Managed Instance, perlu diketahui bahwa setiap titik akhir layanan jaringan virtual hanya berlaku untuk satu wilayah Azure. Titik akhir tidak memungkinkan wilayah lain untuk menerima komunikasi dari subnet. Oleh karena itu, hanya aplikasi klien yang disebarkan di wilayah yang sama yang dapat terhubung ke database utama.

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, ia tidak menunggu transaksi yang ditransmisikan diputar ulang dan dilakukan 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.

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 otomatis 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 diinisiasi saat grup failover otomatis berada dalam status Seeding, karena database pengguna belum disalin ke instans sekunder.
• Sinkronisasi - status biasa grup failover otomatis. 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 menjadi sekunder karena sifat asinkron dari proses replikasi antara instans dalam grup failover otomatis. Baik failover otomatis maupun manual dapat dimulai saat grup failover otomatis berada dalam status Seeding.
• 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 otomatis berada dalam status ini.

Izin

Izin untuk grup failover dikelola melalui kontrol akses berbasis peran Azure (Azure RBAC).

Akses tulis RBAC Azure sangat diperlukan untuk membuat dan mengelola grup failover. Kontributor SQL Managed Instance memiliki semua izin yang diperlukan untuk mengelola grup failover.

Untuk cakupan izin spesifik, tinjau cara mengonfigurasikan grup failover otomatis di Azure SQL Managed Instance.

Batasan

Ketahui batasan berikut:

• Grup failover tidak dapat dibuat antara dua instans di wilayah Azure yang sama.
• Grup failover tidak dapat diganti namanya. Anda harus menghapus grup dan membuatnya kembali dengan nama yang berbeda.
• Penggantian nama database tidak didukung untuk instans dalam grup failover. Anda harus menghapus grup failover untuk sementara waktu agar bisa mengganti nama database.
• Database sistem tidak direplikasi ke instans sekunder dalam grup failover. Oleh karena itu, skenario yang bergantung pada objek dari database sistem seperti pekerjaan Server Logins dan Agent, mengharuskan objek dibuat secara manual pada instans sekunder dan juga secara manual disimpan sesuai dengan perubahan yang telah dibuat pada instans utama. Satu-satunya pengecualian adalah Service master Key (SMK) untuk SQL Managed Instance, yang direplikasi secara otomatis ke instans sekunder selama pembuatan grup failover. Setiap perubahan SMK berikutnya pada contoh utama tetapi tidak akan direplikasi ke instans sekunder. Untuk mempelajari selengkapnya, lihat cara Mengaktifkan skenario yang bergantung pada objek dari database sistem.
• Grup failover tidak dapat dibuat di antara instans jika salah satu dari mereka berada di kumpulan instans.

Mengelola grup failover secara terprogram

Grup failover otomatis juga dapat dikelola secara terprogram menggunakan Azure PowerShell, Azure CLI, dan REST API. Tabel berikut ini menjelaskan kumpulan perintah yang tersedia. Replikasi geo aktif mencakup set API Azure Resource Manager untuk pengelolaan, termasuk Azure SQL Database REST API dan cmdlet Azure PowerShell. API ini memerlukan penggunaan grup sumber daya dan mendukung kontrol akses berbasis peran Azure (Azure RBAC). Untuk informasi selengkapnya tentang cara menerapkan peran akses, lihat Kontrol akses berbasis peran Azure (Azure RBAC).

PowerShell

Cmdlet	Deskripsi
Baru-AzSqlDatabaseInstanceFailoverGroup	Perintah ini membuat grup failover dan mendaftarkannya di instans utama dan sekunder
Set-AzSqlDatabaseInstanceFailoverGroup	Memodifikasi konfigurasi grup failover
Mendapatkan-AzSqlDatabaseInstanceFailoverGroup	Mengambil konfigurasi grup failover
Switch-AzSqlDatabaseInstanceFailoverGroup	Memicu failover grup failover ke instans sekunder
Remove-AzSqlDatabaseInstanceFailoverGroup	Menghapus grup failover

Azure CLI

Perintah	Deskripsi
az sql failover-group create	Perintah ini membuat grup failover dan mendaftarkannya di server utama dan sekunder
az sql failover-group delete	Menghapus grup failover dari server
az sql failover-group show	Mengambil konfigurasi grup failover
az sql failover-group update	Memodifikasi konfigurasi grup failover dan/atau menambahkan satu atau lebih database ke grup failover
az sql failover-group set-primary	Memicu failover grup failover ke server sekunder

REST API

API	Deskripsi
Buat atau Perbarui Grup Failover	Membuat atau memperbarui konfigurasi grup failover
Hapus Grup Failover	Menghapus grup failover dari instans
Failover (Terencana)	Memicu failover dari instans utama saat ini ke instans ini dengan sinkronisasi data penuh.
Failover Paksa Mengakibatkan Data Hilang	Memicu failover dari instance primer saat ini ke instance sekunder tanpa menyinkronkan data. Operasi ini dapat mengakibatkan hilangnya data.
Dapatkan Grup Failover	Mengambil konfigurasi grup failover.
Buat Daftar Grup Failover - Buat Daftar Berdasarkan Lokasi	Membuat daftar grup failover di lokasi.

Langkah berikutnya

• Untuk mengetahui tutorial mendetail, lihat
  • Menambahkan SQL Managed Instance ke grup failover
• Untuk contoh skrip, lihat:
  • Menggunakan PowerShell untuk membuat grup failover otomatis pada Azure SQL Managed Instance
• Untuk gambaran umum dan skenario kelangsungan bisnis, lihat Gambaran umum kelangsungan bisnis
• Untuk mempelajari pencadangan otomatis, lihat Pencadangan otomatis Azure SQL Database.
• Untuk mempelajari tentang menggunakan pencadangan otomatis untuk pemulihan, lihat Memulihkan database dari cadangan yang dimulai layanan.