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

Berlaku untuk: database Azure SQL

Fitur grup failover otomatis memperbolehkan Anda untuk mengelola replikasi dan failover beberapa atau semua database di server logis ke wilayah lainnya. Artikel ini berfokus pada penggunaan fitur grup Failover otomatis dengan Azure SQL Database 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 Database. Untuk Azure SQL Managed Instance, lihat Grup failover otomatis di Azure SQL Managed Instance.
  • Grup failover otomatis mendukung replikasi-geografis semua database dalam grup ke hanya satu server sekunder di wilayah yang berbeda. Jika Anda perlu membuat beberapa replika geo-sekunder Azure SQL Database (di daerah yang sama atau berbeda) untuk replika primer yang sama, gunakan replikasi geografis aktif.

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 adalah grup database bernama yang dikelola oleh server tunggal yang dapat gagal sebagai unit ke wilayah Azure lain jika semua atau beberapa database utama menjadi tidak tersedia karena pemadaman di wilayah utama.

    Penting

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

  • Server

    Beberapa atau semua database pengguna pada server logis dapat ditempatkan di grup failover. Selain itu, server mendukung beberapa grup failover pada satu server.

  • Primer

    Server yang menghosting database utama dalam grup failover.

  • Sekunder

    Server yang menghosting database sekunder dalam grup failover. Sekunder tidak dapat berada di wilayah Azure yang sama dengan yang utama.

  • Menambahkan database tunggal ke grup failover

    Anda dapat menempatkan beberapa database tunggal di server yang sama ke dalam grup failover yang sama. Jika Anda menambahkan database tunggal ke grup failover, database tersebut akan secara otomatis membuat database sekunder menggunakan edisi dan ukuran komputasi yang sama di server sekunder. Anda menentukan server tersebut ketika grup failover dibuat. Jika Anda menambahkan database yang sudah memiliki database sekunder di server sekunder, tautan geo-replikasi tersebut diwarisi oleh grup. Ketika Anda menambahkan database yang sudah memiliki database sekunder di server yang bukan bagian dari grup failover, sekunder baru akan dibuat di server sekunder.

    Penting

    Pastikan bahwa server sekunder tidak memiliki database dengan nama yang sama kecuali jika itu adalah database sekunder yang sudah ada.

  • Menambahkan database dalam kumpulan elastis ke grup failover

    Anda dapat memasukkan semua atau beberapa database dalam kumpulan elastis ke dalam grup failover yang sama. Jika database utama berada dalam kumpulan elastis, database sekunder secara otomatis dibuat di kumpulan elastis dengan nama yang sama (kumpulan sekunder). Anda harus memastikan bahwa server sekunder berisi kumpulan elastis dengan nama yang sama persis dan memiliki kapasitas bebas yang cukup untuk menghosting database sekunder yang akan dibuat oleh grup failover. Jika Anda menambahkan database di kumpulan yang sudah memiliki database sekunder di kumpulan sekunder, tautan geo-replikasi tersebut diwarisi oleh grup. Ketika Anda menambahkan database yang sudah memiliki database sekunder di server yang bukan bagian dari grup failover, database sekunder baru dibuat di kumpulan sekunder.

  • 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 di server, data CNAME DNS untuk URL pendengar dibentuk sebagai <fog-name>.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 di server, data CNAME DNS untuk URL pendengar dibentuk sebagai <fog-name>.secondary.database.windows.net.

  • Beberapa grup failover

    Anda dapat mengonfigurasi beberapa grup failover untuk pasangan server yang sama guna mengontrol cakupan failover. Setiap kelompok melakukan failover secara independen. Jika aplikasi penyewa per database Anda digunakan di beberapa wilayah dan menggunakan kumpulan elastis, Anda dapat menggunakan kemampuan ini untuk mencampur database primer dan sekunder di setiap kumpulan. Dengan cara ini Anda mungkin dapat mengurangi dampak pemadaman hanya untuk beberapa database penyewa.

  • 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)

    Catatan

    Jika database berisi objek OLTP dalam memori, database utama dan database geo-replika sekunder target harus memiliki tingkat layanan yang cocok, karena objek OLTP dalam memori selalu terhidrasi dalam memori. Tingkat layanan yang lebih rendah pada database geo-replika target dapat mengakibatkan masalah kehabisan memori. Jika ini terjadi, replika database geo-sekunder yang terpengaruh dapat dimasukkan ke dalam mode baca-saja terbatas yang disebut mode khusus titik pemeriksaan OLTP dalam memori . Kueri tabel baca-saja diperbolehkan, tetapi kueri tabel OLTP baca-saja dalam memori tidak diizinkan pada replika database geo-sekunder yang terpengaruh. Failover yang direncanakan diblokir jika semua replika dalam database geo-sekunder berada dalam mode titik pemeriksaan saja. Failover yang tidak direncanakan mungkin gagal karena masalah kehabisan memori. Untuk menghindari hal ini, tingkatkan tingkat layanan database sekunder agar sesuai dengan database utama selama failover yang direncanakan, atau latihan. Peningkatan tingkat layanan dapat berupa operasi ukuran data, dan mungkin perlu waktu beberapa saat untuk diselesaikan.

  • 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 di Azure SQL Database dapat mencakup satu atau beberapa database, biasanya digunakan oleh aplikasi yang sama. Ketika Anda menggunakan grup failover otomatis dengan kebijakan failover otomatis, setiap pemadaman yang memengaruhi satu atau beberapa database di grup akan menghasilkan failover otomatis.

Grup failover otomatis harus dikonfigurasi di server utama dan akan menyambungkannya ke server sekunder di wilayah Azure yang berbeda. Grup dapat menyertakan semua atau beberapa database di server ini. Diagram berikut mengilustrasikan konfigurasi umum aplikasi cloud geo-redundan menggunakan beberapa database dan grup failover otomatis.

Diagram memperlihatkan konfigurasi umum aplikasi cloud geo-redundan menggunakan beberapa database dan grup failover otomatis.

Saat mendesain layanan dengan mempertimbangkan kelangsungan bisnis, ikuti panduan umum dan praktik terbaik yang diuraikan dalam artikel ini. Saat mengonfigurasi grup failover, pastikan bahwa autentikasi dan akses jaringan pada sekunder diatur agar berfungsi dengan benar setelah geo-failover, ketika geo-sekunder menjadi primer baru. Untuk detailnya, lihat Keamanan SQL Database setelah pemulihan bencana. Untuk informasi selengkapnya tentang merancang solusi untuk pemulihan bencana, lihat Merancang Solusi Cloud untuk Pemulihan Bencana Menggunakan replikasi geo aktif.

Untuk informasi tentang menggunakan pemulihan point-in-time dengan grup failover, lihat Pemulihan Titik-Waktu-Tertentu (PITR).

Seeding awal

Saat menambahkan database atau kumpulan elastis 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 500 GB per jam untuk SQL Database. Seeding dilakukan untuk semua database secara paralel.

Gunakan beberapa grup failover untuk melakukan failover pada beberapa database

Satu atau banyak grup failover dapat dibuat antara dua server di wilayah berbeda (server utama dan sekunder). Setiap grup dapat menyertakan satu atau beberapa database yang dipulihkan sebagai pelajaran jika semua atau beberapa database utama menjadi tidak tersedia karena pemadaman di wilayah utama. Grup failover membuat database geo-sekunder dengan tujuan layanan yang sama dengan yang primer. Jika Anda menambahkan hubungan geo-replikasi yang ada ke grup failover, pastikan geo-sekunder dikonfigurasi dengan tingkat layanan dan ukuran komputasi yang sama dengan primer.

Gunakan pendengar baca-tulis (utama)

Untuk beban kerja baca-tulis, gunakan <fog-name>.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 tembolok DNS klien direfresh. Waktu untuk hidup (TTL) dari catatan DNS pendengar primer dan sekunder adalah 30 detik.

Gunakan pendengar baca-saja (sekunder)

Jika Anda memiliki beban kerja baca-saja yang terisolasi secara logis yang toleran terhadap latensi data, Anda dapat menjalankannya di geo-sekunder. Untuk beban kerja baca-tulis, gunakan <fog-name>.secondary.database.windows.net sebagai nama server dalam string koneksi. Koneksi akan secara otomatis diarahkan ke geo-sekunder. Disarankan juga agar Anda menunjukkan niat baca dalam string koneksi dengan menggunakan ApplicationIntent=ReadOnly.

Di tingkat layanan Premium, Kritis untuk Bisnis, dan Hyperscale, SQL Database mendukung penggunaan replika baca-saja untuk membongkar beban kerja kueri baca-saja, menggunakan parameter ApplicationIntent=ReadOnly dalam string koneksi. Saat Anda telah mengonfigurasikan lokasi geo-sekunder, Anda dapat menggunakan kemampuan ini untuk membuat sambungan ke replika baca-saja di lokasi utama atau di lokasi geo-replika:

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

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 DR, ikuti pedoman keamanan jaringanini, dan atur geo-failover komponen aplikasi yang relevan 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. Jika kebijakan failover otomatis dikonfigurasi, sistem menunggu periode yang Anda tentukan GracePeriodWithDataLossHours sebelum memulai geo-failover otomatis. Nilai defaultnya adalah 1 jam. Ini mendukung ketersediaan database karena tidak ada kehilangan data. 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.

Penting

Kumpulan elastis dengan 800 atau lebih sedikit DTU dan lebih dari 8 database yang menggunakan geo-replikasi dapat mengalami masalah termasuk failover terencana yang berlangsung lebih lama dan kinerja yang menurun. Masalah ini lebih mungkin terjadi untuk beban kerja intensif tulis, ketika titik akhir geo-replikasi dipisahkan secara luas oleh geografi, atau ketika beberapa titik akhir sekunder digunakan untuk setiap database. Gejala dari masalah ini adalah peningkatan lag geo-replikasi dari waktu ke waktu, berpotensi menyebabkan kehilangan data yang lebih luas dalam pemadaman. Jeda ini dapat dipantau menggunakan sys.dm_geo_replication_link_status. Jika masalah ini terjadi, maka mitigasi termasuk meningkatkan kumpulan untuk memiliki lebih banyak DCU atau vCores, atau mengurangi jumlah database geo-replikasi di kumpulan.

Grup failover dan keamanan jaringan

Untuk beberapa aplikasi, aturan keamanan mengharuskan akses jaringan ke tingkat data dibatasi untuk komponen atau komponen tertentu seperti komputer virtual, layanan web, dll. Persyaratan ini menghadirkan beberapa tantangan untuk desain kelangsungan bisnis dan penggunaan grup failover. Pertimbangkan opsi berikut saat menerapkan akses terbatas tersebut.

Menggunakan grup failover dan titik akhir layanan jaringan virtual

Jika Anda menggunakan titik akhir dan aturan layanan Virtual Network untuk membatasi akses ke database Anda di SQL Database, hati-hati bahwa setiap titik akhir layanan jaringan virtual berlaku hanya 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. Karena hasil failover dalam sesi klien SQL Database yang dialihkan ke server di wilayah (sekunder) yang berbeda, sesi ini akan gagal jika berasal dari klien di luar wilayah tersebut. Untuk alasan itu, kebijakan failover otomatis tidak dapat diaktifkan jika server atau instans yang berpartisipasi disertakan dalam aturan Virtual Network. Untuk mendukung failover manual, ikuti langkah-langkah berikut:

  1. Provisikan salinan redundan dari komponen front-end aplikasi Anda (layanan web, mesin virtual, dll.) di wilayah sekunder.
  2. Konfigurasikan aturan jaringan virtual satu per satu untuk server primer dan sekunder.
  3. Aktifkan failover front-end menggunakan pengelola konfigurasi lalu lintas.
  4. Memulai failover manual ketika pemadaman terdeteksi. Opsi ini dioptimalkan untuk aplikasi yang memerlukan latensi yang konsisten antara front-end dan tingkat data dan mendukung pemulihan ketika front-end, tingkat data atau keduanya terkena dampak pemadaman.

Catatan

Jika Anda menggunakan pendengar baca-saja untuk menyeimbangkan muatan beban kerja baca-saja, pastikan beban kerja ini dijalankan dalam komputer virtual atau sumber daya lain di wilayah sekunder sehingga dapat tersambung ke database sekunder.

Menggunakan grup failover dan aturan firewall

Jika paket kelangsungan bisnis Anda memerlukan failover menggunakan grup dengan failover otomatis, Anda dapat membatasi akses ke database Anda di SQL Database dengan menggunakan aturan firewall tradisional. Untuk mendukung failover otomatis, ikuti langkah-langkah berikut:

  1. Buat IP publik.
  2. Buat load balancer publik dan tetapkan IP publik ke dalamnya.
  3. Buat jaringan virtual dan mesin virtual untuk komponen front-end Anda.
  4. Buat grup keamanan jaringan dan konfigurasikan sambungan masuk.
  5. Pastikan koneksi keluar terbuka ke Azure SQL Database di suatu wilayah dengan menggunakan Sql.<Region>tag layanan.
  6. Buat aturan firewall SQL Database untuk memungkinkan lalu lintas masuk dari alamat IP publik yang Anda buat di langkah 1.

Untuk informasi selengkapnya tentang cara mengonfigurasi akses keluar dan IP apa yang digunakan dalam aturan firewall, lihat Sambungan keluar load balancer.

Konfigurasi di atas akan memastikan bahwa failover otomatis tidak akan memblokir koneksi dari komponen front-end dan mengasumsikan bahwa aplikasi dapat mentolerir latensi yang lebih lama antara front end dan tingkat data.

Penting

Guna menjamin kelangsungan bisnis untuk pemadaman regional, Anda harus memastikan redundansi geografis untuk komponen dan database front-end.

Skala database utama

Anda dapat meningkatkan atau menurunkan basis data utama ke ukuran komputasi yang berbeda (dalam tingkat layanan yang sama) tanpa memutuskan geo-sekunder. Saat meningkatkan, kami sarankan Anda meningkatkan geo-sekunder terlebih dahulu, dan kemudian meningkatkan primer. Saat menskalakan, balikkan urutan: skala bawah primer pertama, dan kemudian skala bawah sekunder. Ketika Anda menskalakan database ke tingkat layanan yang berbeda, rekomendasi ini diberlakukan.

Urutan ini direkomendasikan khususnya untuk menghindari masalah saat instans sekunder di SKU yang lebih rendah mengalami kelebihan beban dan harus ditambahkan kembali selama proses peningkatan atau penurunan. Anda juga dapat menghindari masalah dengan menjadikan instans utama sebagai baca-saja, yang akan memengaruhi semua beban kerja baca-tulis terhadap instans utama.

Catatan

Jika Anda membuat geo-sekunder sebagai bagian dari konfigurasi grup failover, tidak disarankan untuk mengurangi geo-sekunder. Ini untuk memastikan tingkat data Anda memiliki kapasitas yang cukup untuk memproses beban kerja reguler Anda setelah failover diaktifkan.

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.

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. Peran Kontributor SQL Server memiliki semua izin yang diperlukan untuk mengelola grup failover.

Untuk cakupan izin spesifik, tinjau bagaimana cara mengonfigurasikan grup failover otomatis di Azure SQL Database.

Batasan

Ketahui batasan berikut:

  • Grup failover tidak dapat dibuat antara dua server 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 untuk dapat mengganti nama database, atau menghapus database dari grup failover.

Mengelola grup failover secara terprogram

Seperti yang telah dibahas sebelumnya, grup auto-failover 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).

Cmdlet Deskripsi
Baru-AzSqlDatabaseFailoverGroup Perintah ini membuat grup failover dan mendaftarkannya di server utama dan sekunder
Remove-AzSqlDatabaseFailoverGroup Menghapus grup failover dari server
Dapatkan-AzSqlDatabaseFailoverGroup Mengambil konfigurasi grup failover
Set-AzSqlDatabaseFailoverGroup Memodifikasi konfigurasi grup failover
Alihkan-AzSqlDatabaseFailoverGroup Memicu failover grup failover ke server sekunder
Tambahkan-AzSqlDatabaseToFailoverGroup Menambahkan satu atau beberapa database ke grup failover

Langkah berikutnya