Bagikan melalui

Gambaran Umum Grup Failover & Praktik Terbaik (Azure SQL Database)

  • Artikel

Berlaku untuk:Azure SQL Database

Fitur grup failover memungkinkan Anda mengelola replikasi dan failover beberapa atau semua database di server logis ke server logis di wilayah lain. Artikel ini memberikan gambaran umum tentang fitur grup failover dengan praktik terbaik dan rekomendasi untuk menggunakannya dengan Azure SQL Database.

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

Catatan

Artikel ini membahas grup failover untuk Azure SQL Database. Untuk Azure SQL Managed Instance, lihat Ikhtisar dan praktik terbaik grup failover - Azure SQL Managed Instance.

Untuk mempelajari selengkapnya tentang pemulihan bencana Azure SQL Database, tonton video ini:

Gambaran Umum

Fitur grup failover memungkinkan Anda mengelola replikasi dan failover database ke wilayah Azure lain. Anda dapat memilih semua, atau subset, database pengguna di server logis untuk direplikasi ke server logis lain. Ini adalah abstraksi deklaratif di atas fitur replikasi geografis aktif, yang dirancang untuk menyederhanakan penyebaran dan manajemen database yang direplikasi secara geografis dalam skala besar.

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 diarahkan ke server utama 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.

Mengalihkan beban kerja baca-saja

Untuk mengurangi lalu lintas ke database utama Anda, Anda juga dapat menggunakan database sekunder dalam grup failover untuk mengalihkan 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 oleh 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 Kasus penggunaan Potensi kehilangan data
Dikelola oleh 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 oleh Microsoft Semua grup failover di wilayah tersebut 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 oleh 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 menginisiasi failover saat melihat gangguan tak terduga yang mempengaruhi 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 telah kedaluwarsa. Karena verifikasi dan pengurangan skala pemadaman bergantung pada tindakan manusia, masa tenggang tidak dapat disetel kurang dari satu jam.

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

Penting

Gunakan kebijakan failover yang dikelola pelanggan untuk menguji dan menerapkan rencana pemulihan bencana Anda. Jangan mengandalkan failover terkelola Microsoft, yang mungkin hanya dijalankan oleh Microsoft dalam keadaan ekstrem. Failover yang diatur oleh Microsoft akan dimulai untuk semua grup failover di wilayah yang memiliki kebijakan failover diatur oleh Microsoft. Ini tidak bisa diaktifkan untuk grup failover individu. Jika Anda memerlukan kemampuan untuk secara selektif melakukan failover pada grup failover Anda, gunakan kebijakan failover yang dikelola pelanggan.

Atur kebijakan failover ke yang dikelola Microsoft 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.
  • Bisa diterima melakukan failover paksa pada database dalam grup failover tanpa memperhitungkan dependensi aplikasi pada layanan atau komponen Azure lain yang digunakan oleh aplikasi, yang dapat menyebabkan penurunan kinerja atau ketidaktersediaan aplikasi.
  • Dapat diterima untuk mengalami kehilangan data dalam jumlah yang tidak diketahui, karena waktu yang tepat dari failover yang dipaksakan tidak dapat dikontrol, dan dilakukan dengan mengabaikan status sinkronisasi database sekunder.
  • Semua database utama dan sekunder dalam grup failover dan hubungan replikasi geografis apa pun memiliki tingkat layanan, tingkat komputasi yang sama (disediakan atau tanpa server) & ukuran komputasi (DTU atau vCore). Jika tujuan tingkat layanan (SLO) dari semua database tidak sesuai, maka kebijakan failover pada akhirnya akan diperbarui dari Microsoft Managed menjadi Customer Managed oleh layanan Azure SQL.

Saat failover dipicu oleh Microsoft, entri untuk nama Failover grup failover Azure SQL ditambahkan ke log aktivitas Azure Monitor. Entri menyertakan nama grup failover di bawah Sumber Daya, dan Peristiwa yang diinisiasi oleh menampilkan satu tanda hubung (-) untuk menunjukkan bahwa failover diinisiasi 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 adalah grup database bernama yang dikelola oleh satu server logis di Azure yang dapat berpindah sebagai kesatuan 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 logis yang mengelola database utama dalam grup failover.

  • Sekunder

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

  • 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 server utama 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
    • Kembalikan beban kerja ke wilayah utama setelah pemadaman teratasi (failback)

  • Pemulihan 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 pemulihan, 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.

  • Menambahkan database tunggal ke grup failover

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

    Penting

    • Pastikan server logis sekunder tidak memiliki database dengan nama yang sama kecuali itu adalah database sekunder yang sudah ada.
    • Jika database berisi objek OLTP dalam memori, database utama dan database geo-replika sekunder harus memiliki tingkat layanan yang cocok, karena objek OLTP dalam memori berada di memori. Tingkat layanan yang lebih rendah pada database geo-replika dapat mengakibatkan masalah kehabisan memori. Jika ini terjadi, replika geografis mungkin gagal memulihkan database, menyebabkan tidak tersedianya database sekunder bersama dengan objek OLTP dalam memori pada geo-sekunder. Hal ini, pada gilirannya, dapat menyebabkan proses failover juga tidak berhasil. Untuk menghindari hal ini, pastikan bahwa tingkat layanan database geo-sekunder cocok dengan database utama. Peningkatan tingkat layanan dapat berupa operasi ukuran data dan mungkin perlu waktu cukup lama untuk diselesaikan.

  • 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. Saat Anda menambahkan database yang sudah memiliki database sekunder di server yang bukan bagian dari grup failover, database sekunder baru dibuat di kumpulan sekunder.

  • Listener 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 dan tulis untuk terhubung kembali dengan mudah ke server utama ketika server utama berubah setelah failover. Ketika grup failover dibuat di server, data CNAME DNS untuk URL pendengar dibentuk sebagai <fog-name>.database.windows.net. Setelah failover, catatan DNS secara otomatis diperbarui untuk mengalihkan pendengar ke primer baru.

  • Pendengar read-only untuk 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 di server, catatan CNAME DNS untuk URL listener dibentuk sebagai <fog-name>.secondary.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 server 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 utama 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 true, server utama baru akan melayani sesi baca-tulis dan baca-saja.

  • Beberapa grup failover

    Anda dapat mengonfigurasi beberapa grup failover untuk pasangan server yang sama guna mengontrol cakupan failover geografis. Setiap kelompok mengalami 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.

Arsitektur kelompok failover

Grup failover di Azure SQL Database dapat mencakup satu atau beberapa database, biasanya digunakan oleh aplikasi yang sama. Grup failover harus dikonfigurasi di server utama, yang menghubungkannya ke server sekunder di wilayah Azure yang berbeda. Grup failover dapat menyertakan semua atau beberapa database di server utama. Diagram berikut mengilustrasikan konfigurasi umum dari aplikasi cloud dengan redundansi geografis menggunakan beberapa database dalam grup failover.

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

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 berfungsi sebagai primer baru. Untuk detailnya, lihat Mengonfigurasi dan mengelola keamanan Azure SQL Database untuk pemulihan geografis atau failover. Untuk informasi selengkapnya, lihat Merancang layanan yang tersedia secara global menggunakan Azure SQL Database dan Geo-restore untuk Azure SQL Database.

Gunakan wilayah berpasangan

Saat membuat grup failover Antara server utama dan sekunder, gunakan wilayah berpasangan karena grup failover di wilayah berpasangan memiliki performa yang lebih baik dibandingkan dengan wilayah yang tidak berpasangan.

Mengikuti praktik penyebaran yang aman, Azure SQL Database umumnya tidak memperbarui wilayah yang dipasangkan secara bersamaan. Namun, tidak dimungkinkan untuk memprediksi wilayah mana yang akan ditingkatkan terlebih dahulu, sehingga urutan penyebaran tidak dijamin. Terkadang, server utama Anda ditingkatkan terlebih dahulu, dan terkadang ditingkatkan kedua.

Jika Anda memiliki geo-replikasi atau grup failover yang dikonfigurasi untuk database yang tidak sesuai dengan pemadanan wilayah Azure, gunakan jadwal jendela pemeliharaan yang berbeda untuk database utama dan sekunder Anda. Misalnya, Anda dapat memilih Jendela pemeliharaan hari kerja untuk database sekunder dan jendela pemeliharaan Akhir Pekan untuk database utama Anda.

Penyemaian awal

Saat menambahkan database atau kumpulan elastis ke grup failover, ada 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 agar penyemaian awal selesai tergantung pada ukuran data Anda, jumlah database yang direplikasi, beban pada database utama, dan kecepatan tautan jaringan antara database utama dan sekunder. Dalam keadaan normal, kemungkinan kecepatan seeding mencapai 500 GB per jam untuk SQL Database. Seeding dilakukan untuk semua database secara bersamaan.

Jumlah database dalam grup failover

Jumlah basis data dalam grup failover secara langsung berpengaruh pada durasi operasi Failover dan Failover Paksa.

  • Selama Failover (juga dikenal sebagai Failover Terencana), kami memastikan bahwa semua database utama sepenuhnya disinkronkan dengan database sekunder mereka dan dalam kondisi siap. Untuk menghindari kewalahan sarana kontrol, database disiapkan dalam batch. Oleh karena itu, sangat disarankan untuk membatasi jumlah database dalam grup failover.
  • Dalam kasus Failover Paksa, fase persiapan dipercepat karena sinkronisasi data tidak dimulai. Untuk mencapai durasi failover yang lebih cepat dan dapat diprediksi, mungkin bermanfaat untuk menyimpan jumlah database dalam grup failover ke jumlah yang lebih kecil.

Menggunakan 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 satu kesatuan jika semua atau beberapa database utama menjadi tidak tersedia akibat gangguan di wilayah utama. Membuat grup failover menciptakan database geo-sekunder dengan tujuan layanan yang sama seperti yang utama. 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 secara otomatis diarahkan ke utama. Nama ini tidak berubah setelah failover. Perhatikan bahwa failover melibatkan pembaruan catatan DNS sehingga koneksi klien dialihkan ke server utama yang baru hanya setelah tembolok DNS klien diperbarui. Waktu hidup (TTL) dari catatan DNS pendengar utama 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 sesi hanya-baca, gunakan <fog-name>.secondary.database.windows.net sebagai nama server dalam string koneksi. Koneksi secara otomatis diarahkan ke lokasi sekunder geografis. Disarankan juga agar Anda menunjukkan niat baca di string koneksi dengan menggunakan ApplicationIntent=ReadOnly.

Di tingkat layanan Premium, Business Critical, dan Hyperscale, SQL Database mendukung penggunaan replika baca-saja untuk mengurangi beban kerja kueri baca-saja, menggunakan ApplicationIntent=ReadOnly parameter dalam string koneksi. Ketika Anda telah mengonfigurasi pengaturan sekunder-geografis, Anda dapat menggunakan fitur ini untuk menyambungkan ke replika yang hanya dapat dibaca di lokasi utama atau di lokasi sekunder-geografis.

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 grup dipicu berdasarkan status Azure SQL Database 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 (DR), latensi antar 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 proses 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.

Penting

Kumpulan elastis dengan DTU sebanyak 800 atau kurang, atau vCore sebanyak 8 atau kurang, dan memiliki lebih dari 250 database, dapat mengalami masalah termasuk rencana geo-failover yang lebih lama dan performa yang terdegradasi. Masalah ini lebih mungkin terjadi untuk menulis beban kerja intensif ketika replika geografi dipisahkan secara luas oleh geografi, atau ketika beberapa replika geografi 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 dengan menambah lebih banyak DTU atau vCores, atau mengurangi jumlah database dengan replikasi geo dalam kumpulan.

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.

Izin dan batasan

Tinjau panduan grup failover konfigurasi untuk daftar izin dan batasan.

Mengelola grup failover secara terprogram

Grup failover juga dapat dikelola secara terprogram menggunakan Azure PowerShell, Azure CLI, dan REST API. Untuk informasi selengkapnya, tinjau Mengonfigurasi grup failover untuk Azure SQL Database.

Aktifkan ketersediaan tinggi (redundansi zona)

Ketersediaan melalui redundansi meningkatkan ketahanan lebih lanjut dengan melindungi dari pemadaman zona ketersediaan dalam suatu wilayah.

Saat membuat grup failover yang menyertakan satu atau beberapa database, tidak ada opsi untuk mengaktifkan ketersediaan tinggi untuk database sekunder, terlepas dari pengaturan ketersediaan tinggi database utama.

Redundansi zona dengan database non-Hyperscale

Database sekunder yang dibuat melalui grup failover tidak akan memiliki ketersediaan tinggi yang diaktifkan secara default. Setelah grup failover dibuat, aktifkan keandalan tinggi pada database dalam grup tersebut. Perilaku ini juga berlaku jika Anda membuat Active Geo-Replication terlebih dahulu lalu secara opsional menambahkan database ke grup failover.

Redundansi zona dengan Hyperscale

Database sekunder yang dibuat melalui grup failover akan mewarisi pengaturan ketersediaan tinggi dari database utama masing-masing. Oleh karena itu, jika database utama mengaktifkan ketersediaan tinggi, database sekunder juga akan mengaktifkannya. Sebaliknya, jika database utama tidak mengaktifkan ketersediaan tinggi, database sekunder juga tidak akan mengaktifkannya.

Dukungan regional untuk zona ketersediaan

Dalam skenario di mana ketersediaan tinggi diaktifkan pada database utama, dan database sekunder yang ditambahkan berada di wilayah yang belum mendukung zona ketersediaan, alur kerja akan gagal dengan pesan kesalahan dengan kode 45122: "Operasi Buat atau perbarui Grup Failover berhasil diselesaikan; namun, beberapa database tidak dapat ditambahkan atau dihapus dari Grup Failover. Penyediaan database/kumpulan zona redundan tidak didukung untuk permintaan Anda saat ini. Untuk mengatasi masalah ini, gunakan Replikasi geografis aktif di mana Anda dapat mengaktifkan atau menonaktifkan ketersediaan yang tinggi saat membuat database sekunder. Anda kemudian dapat secara opsional menambahkan database ini ke grup failover.

Konten terkait