Bagikan melalui

Mencadangkan SQL Server selalu dalam grup ketersediaan

  • Artikel

Azure Backup menawarkan dukungan end-to-end untuk mencadangkan SQL Server selalu dalam grup ketersediaan (AG) jika semua simpul berada dalam satu lokasi dan langganan dengan brankas Layanan Pemulihan. Namun, jika simpul AG tersebar di seluruh lokasi/langganan/lokal, dan Azure, ada beberapa hal yang perlu dipertimbangkan.

Catatan

  • Pencadangan database Grup Ketersediaan Dasar tidak didukung oleh Azure Backup.
  • Lihat matriks dukungan pencadangan SQL untuk mengetahui lebih lanjut tentang konfigurasi dan skenario yang didukung.

Preferensi pencadangan yang digunakan oleh Azure Backup SQL AG mendukung pencadangan penuh dan diferensial hanya dari replika utama. Jadi, pekerjaan pencadangan ini selalu berjalan di simpul Primer apa pun preferensi pencadangan yang digunakan. Untuk pencadangan log transaksi dan hanya salin penuh, preferensi pencadangan AG akan dipertimbangkan saat memutuskan simpul tempat pencadangan akan dijalankan.

Preferensi Pencadangan AG Tempat pencadangan Penuh dan Diferensial berjalan Pencadangan Hanya Salin dan Log diambil dari
Primer Replika utama Replika utama
Sekunder saja Replika utama Salah satu dari replika sekunder
Lebih suka sekunder Replika utama Replika sekunder akan dipilih, tetapi pencadangan juga dapat berjalan pada replika utama.
Tidak ada/Apa pun Replika utama Replika apa pun

Ekstensi cadangan beban kerja diinstal pada simpul saat Anda mendaftarkannya dengan layanan Azure Backup. Jika database AG dikonfigurasi untuk cadangan, jadwal cadangan dikirimkan ke semua simpul AG yang terdaftar. Jadwal diaktifkan pada semua simpul AG dan ekstensi cadangan beban kerja pada simpul ini disinkronkan antara mereka sendiri untuk memutuskan simpul mana yang dapat melakukan pencadangan. Pemilihan simpul disesuaikan menurut tipe pencadangan dan preferensi pencadangan seperti yang telah dijelaskan di bagian 1.

Node yang dipilih akan melanjutkan pekerjaan pencadangan, sedangkan pekerjaan yang dipicu di node lain dihentikan dan melewatkan pekerjaan.

Catatan

Azure Backup tidak mempertimbangkan prioritas pencadangan atau replika saat memutuskan di antara replika sekunder.

Mendaftarkan simpul AG ke brankas Layanan Pemulihan

Vault Layanan Pemulihan mendukung pencadangan database hanya dari VM di wilayah dan langganan yang sama dengan vault.

  • Daftarkan simpul utama ke vault (jika tidak, pencadangan penuh tidak dapat terjadi).
  • Daftarkan setidaknya satu simpul sekunder ke vault (jika tidak, pencadangan penuh log/salin-saja tidak dapat terjadi) jika preferensi cadangan hanya sekunder.

Mengonfigurasi cadangan untuk database AG gagal dengan kode kesalahan FabricSvcBackupPreferenceCheckFailedUserError jika kondisi di atas tidak terpenuhi.

Mari kita pertimbangkan penyebaran AG berikut sebagai referensi.

Diagram untuk penyebaran AG sebagai referensi.

Berdasarkan contoh penyebaran AG yang diberikan, berikut adalah berbagai pertimbangan:

  • Karena simpul utama berada di wilayah 1 dan langganan 1, brankas Layanan Pemulihan (Brankas 1) harus berada di Wilayah 1 dan Langganan 1 untuk melindungi AG ini.
  • VM3 tidak dapat didaftarkan ke Vault 1 karena berada dalam langganan yang berbeda.
  • VM4 tidak dapat didaftarkan ke Vault 1 karena berada di wilayah yang berbeda.
  • Jika preferensi pencadangan hanya sekunder, VM1 (Primer) dan VM2 (Sekunder) harus terdaftar ke Brankas 1 (karena pencadangan penuh memerlukan simpul primer dan log memerlukan simpul sekunder). Untuk preferensi pencadangan lainnya, VM1 (Primer) harus terdaftar ke Brankas 1, VM2 bersifat opsional (karena semua pencadangan dapat berjalan pada simpul utama).
  • Meski VM3 dapat didaftarkan ke brankas 2 di langganan 2 dan database AG akan muncul untuk perlindungan di brankas 2, konfigurasi pencadangan akan gagal karena tidak adanya simpul utama di brankas 2.
  • Demikian pula, sementara VM4 dapat didaftarkan ke vault 4 di wilayah 2, mengonfigurasi cadangan akan gagal karena node utama tidak terdaftar di vault 4.

Menangani failover

Setelah AG gagal ke salah satu simpul sekunder:

  • Pencadangan penuh dan diferensial akan berlanjut dari simpul utama baru jika terdaftar di brankas.
  • Pencadangan penuh hanya salin dan log akan dilanjutkan dari simpul primer/sekunder sesuai preferensi pencadangan.

Catatan

Hentian rangkaian log tidak akan terjadi pada failover jika failover tidak terjadi bersamaan dengan pencadangan.

Berdasarkan penyebaran AG sampel di atas, berikut adalah kemungkinan potensi failover:

  • Failover ke VM2
    • Pencadangan penuh dan diferensial akan dilakukan dari VM2.
    • Pencadangan penuh log dan hanya salin akan dilakukan dari VM1 atau VM2 sesuai preferensi pencadangan.
  • Failover ke VM3 (langganan lain)
    • Karena pencadangan tidak dikonfigurasi di Brankas 2, pencadangan tidak akan dilakukan.
    • Jika preferensi pencadangan bukan hanya sekunder, pencadangan ini dapat dikonfigurasi di Brankas 2 karena simpul utama terdaftar di brankas ini. Tetapi tindakan ini dapat menyebabkan konflik/kegagalan pencadangan. Lihat informasi selengkapnya tentang hal ini di Mengonfigurasi pencadangan untuk AG multi-wilayah.
  • Failover ke VM4 (wilayah lain)
    • Karena pencadangan tidak dikonfigurasi di Brankas 4, tidak akan ada pencadangan.
    • Jika preferensi cadangan tidak hanya sekunder, cadangan dapat dikonfigurasi sekarang di Vault 4, karena simpul utama terdaftar di vault ini. Tetapi tindakan ini dapat menyebabkan konflik/kegagalan pencadangan. Lihat informasi selengkapnya tentang hal ini di Mengonfigurasi pencadangan untuk AG multi-wilayah.

Mengonfigurasi cadangan untuk AG multi-wilayah

Brankas layanan pemulihan tidak mendukung pencadangan lintas langganan atau lintas wilayah. Bagian ini merangkum cara mengaktifkan pencadangan untuk AG yang mencakup langganan atau wilayah Azure dan pertimbangan terkait.

  • Evaluasi apakah Anda benar-benar perlu mengaktifkan pencadangan dari semua simpul. Jika satu wilayah/langganan memiliki sebagian besar node AG dan failover ke node lain sangat jarang terjadi, menyiapkan pencadangan di kawasan pertama tersebut mungkin sudah cukup. Jika failover ke wilayah/langganan lain sering terjadi dan untuk durasi yang lama, maka Anda mungkin juga ingin menyiapkan cadangan secara proaktif di wilayah lain.

  • Setiap brankas yang mengaktifkan pencadangan akan memiliki rangkaian rantai titik pemulihannya sendiri. Pemulihan dari titik pemulihan ini hanya dapat dilakukan untuk VM yang terdaftar di brankas tersebut.

  • Pencadangan penuh/diferensial hanya akan berhasil dilakukan di brankas yang memiliki simpul utama. Jika dilakukan di brankas lain, pencadangan ini akan terus gagal.

  • Pencadangan log akan terus bekerja di vault sebelumnya hingga cadangan log berjalan di vault baru (yaitu, di vault tempat simpul utama baru ada) dan memutus rantai log untuk vault lama.

    Catatan

    Terdapat batas maksimal selama 15 hari saat pencadangan log mulai gagal.

  • Pencadangan penuh hanya salin dapat digunakan di semua brankas.

  • Perlindungan di setiap brankas diperlakukan sebagai sumber data yang berbeda dan ditagih secara terpisah.

Untuk mencegah konflik pencadangan log antara dua brankas, sebaiknya atur preferensi pencadangan ke Primer. Kemudian, brankas yang memiliki simpul utama juga akan mengambil pencadangan log.

Berdasarkan penyebaran AG sampel di atas, berikut adalah langkah-langkah untuk mengaktifkan cadangan dari semua node. Asumsinya adalah bahwa preferensi pencadangan telah terpenuhi dalam semua langkah.

Langkah 1: Aktifkan pencadangan di Wilayah 1, Langganan 1 (Brankas 1)

Karena simpul utama berada di wilayah dan langganan, langkah-langkah standar untuk mengaktifkan pencadangan dapat digunakan.

Langkah 2: Aktifkan pencadangan di Wilayah 1, Langganan 2 (Brankas 2)

  1. Alihkan AG ke VM3 agar simpul utama tersedia di Brankas 2.
  2. Konfigurasikan pencadangan untuk database AG di Brankas 2.
  3. Pada titik ini:
    1. Pencadangan diferensial/penuh akan gagal di Vault 1 karena tidak ada node terdaftar yang dapat melakukan pencadangan ini.
    2. Pencadangan log akan berhasil di Vault 1 hingga cadangan log berjalan di Vault 2 dan memutus rantai log untuk Vault 1.
  4. Kembalikan AG ke VM1.

Langkah 3: Aktifkan pencadangan di Wilayah 2, Langganan 1 (Brankas 4)

Sama seperti Langkah 2.

Cadangkan AG yang mencakup Azure dan lokal

Azure Backup for SQL Server tidak dapat dijalankan secara lokal. Jika simpul utama berada di Azure dan preferensi pencadangan dipenuhi oleh simpul di Azure, Anda dapat mengikuti panduan di atas terkait AG multi-wilayah untuk mengaktifkan pencadangan bagi replika di Azure. Jika failover ke simpul lokal terjadi, pencadangan penuh dan diferensial di Azure akan mulai gagal. Pencadangan log dapat berlanjut hingga pemutusan rantai log terjadi/15 hari berlalu.

Pembatasan untuk pencadangan dalam database AG

Saat ini, pembatasan pencadangan berlaku pada tingkat mesin individu. Batas default adalah 20 – jika lebih dari 20 pencadangan dipicu secara bersamaan, 20 pencadangan pertama akan berjalan sedangkan yang lainnya akan mengantre. Ketika pekerjaan yang berjalan sudah selesai, pekerjaan lain yang mengantre akan mulai berjalan.

Anda dapat mengubah nilai ini ke nilai yang lebih kecil jika pencadangan bersamaan menyebabkan memori/IO/CPU pada simpul terbebani. Karena pembatasan diterapkan pada tingkat simpul, jika simpul AG tidak seimbang dapat menyebabkan masalah sinkronisasi pencadangan. Untuk memahaminya, pertimbangkan untuk memilih 2 node AG sebagai instans.

Misalnya, simpul pertama memiliki 50 database mandiri yang dilindungi dan kedua simpul memiliki 5 database AG yang dilindungi. Secara efektif, Simpul 1 memiliki 55 pekerjaan pencadangan database terjadwal sedangkan Simpul 2 hanya memiliki 5. Selain itu, semua pencadangan ini dikonfigurasi agar berjalan pada saat yang sama, setiap jam. Pada titik tertentu, 55 pencadangan tersebut akan terpicu pada Simpul 1 dan 35 pencadangan akan mengantre. Beberapa di antaranya merupakan pencadangan database AG. Tetapi pada Simpul 2, pencadangan database AG akan terus berlanjut tanpa antrean.

Karena pekerjaan database AG mengantre pada satu simpul dan berjalan di simpul lain, sinkronisasi pencadangan (yang disebutkan di bagian 6) tidak akan berfungsi dengan baik. Simpul 2 mungkin berasumsi bahwa Simpul 1 sedang tidak berfungsi dan karena itu pekerjaan dari simpul tersebut tidak membutuhkan sinkronisasi. Hal ini dapat menyebabkan putusnya rangkaian log atau menghasilkan pencadangan tambahan karena kedua simpul dapat melakukan pencadangan secara mandiri.

Masalah yang mirip dapat terjadi jika jumlah database AG yang dilindungi melampaui pembatasan. Dalam kasus tersebut, pencadangan untuk, misalnya, DB1 dapat mengantre di Simpul 1 tetapi berjalan pada Simpul 2.

Sebaiknya gunakan preferensi pencadangan berikut untuk mencegah masalah sinkronisasi ini:

  • Untuk AG 2 simpul, atur Preferensi Pencadangan ke Primer atau Sekunder Saja, agar hanya satu simpul yang dapat melakukan pencadangan, yang lain akan selalu berhenti.
  • Untuk AG dengan lebih dari 2 simpul, atur Preferensi Pencadangan ke Primer, agar hanya simpul utama yang dapat melakukan pencadangan, yang lain akan berhenti.

Tagihan untuk pencadangan AG

Sama seperti instans SQL server mandiri, satu instans AG yang dicadangkan dianggap sebagai satu instans yang dilindungi. Total ukuran frontend dari semua database yang dilindungi dalam suatu instans dibebankan. Pertimbangkan penyebaran berikut:

Diagram menampilkan penghitungan instans dari database yang dilindungi.

Instans yang dilindungi dihitung sebagai berikut:

Instans yang Dilindungi/Instans Tagihan Database dipertimbangkan untuk menghitung ukuran frontend
AG1 DB1, DB2
AG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

Memindahkan database yang dilindungi yang masuk atau keluar dari AG

Azure Backup menganggap instans SQL Server atau nama AG\Nama database sebagai nama unik database. Ketika DB mandiri dilindungi, nama uniknya yaitu StandAloneInstanceName\DBName. Jika bergerak di bawah AG, nama unik berubah menjadi AGName\DBName. Pencadangan untuk database mandiri akan mulai gagal dengan kode galat: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Database harus dikonfigurasi untuk perlindungan dari bawah AG. Langkah ini akan dianggap sebagai sumber data baru dengan rantai titik pemulihan terpisah. Perlindungan yang lebih lama dari database mandiri dapat dihentikan dengan menyimpan data untuk mencegah pencadangan berikutnya terpicu atau gagal. Demikian pula, ketika database AG yang dilindungi bergerak keluar dari AG dan menjadi database mandiri, pencadangannya mulai gagal dengan kode galat: UserErrorBackupFailedDatabaseMovedOutOfAG.

Database harus dikonfigurasi untuk perlindungan dari bawah AG. Langkah ini akan dianggap sebagai sumber data baru dengan rantai titik pemulihan terpisah. Perlindungan yang lebih lama dari database mandiri dapat dihentikan dengan menyimpan data untuk mencegah pencadangan berikutnya terpicu atau gagal.

Penambahan/Penghapusan simpul ke AG

Ketika simpul baru ditambahkan ke AG yang dikonfigurasi untuk pencadangan, ekstensi pencadangan beban kerja yang berjalan pada simpul AG yang sudah terdaftar mendeteksi perubahan topologi AG dan menginformasikan layanan Azure Backup selama pekerjaan penemuan database yang terjadwal berikutnya. Ketika simpul baru ini terdaftar untuk pencadangan ke brankas Layanan Pemulihan yang sama dengan simpul lain yang ada, layanan Azure Backup memicu alur kerja yang mengonfigurasi simpul baru ini dengan metadata yang diperlukan untuk melakukan pencadangan AG.

Setelah ini, simpul baru menyinkronkan informasi jadwal pencadangan AG dari layanan Azure Backup dan mulai berpartisipasi dalam proses pencadangan yang disinkronkan. Jika simpul baru tidak dapat menyinkronkan jadwal pencadangan dan berpartisipasi dalam pencadangan, memicu pendaftaran ulang pada node memaksa konfigurasi ulang node untuk cadangan AG juga. Demikian pula, penambahan simpul, ekstensi beban kerja mendeteksi perubahan topologi AG dalam kasus ini dan menginformasikan layanan Azure Backup. Layanan ini memulai alur kerja batalkan konfigurasi simpul di simpul yang dihapus untuk menghapus jadwal pencadangan untuk database AG dan menghapus metadata terkait AG.

Membatalkan pendaftaran simpul AG dari Azure Backup

Jika simpul merupakan bagian dari AG yang memiliki satu atau beberapa database yang dikonfigurasi untuk pencadangan, Azure Backup tidak akan mengizinkan pembatalan pendaftaran pada simpul tersebut. Hal ini untuk mencegah kegagalan pencadangan di masa mendatang jika preferensi pencadangan tidak dapat dilakukan tanpa simpul ini. Untuk membatalkan pendaftaran simpul, pertama-tama Anda perlu menghapusnya dari AG. Ketika alur kerja batalkan konfigurasi simpul selesai, bersihkan simpul tersebut, dan Anda akan dapat pembatalan pendaftaran.

Memulihkan database dari Azure Backup ke Grup Ketersediaan AG SQL tidak mendukung pemulihan database secara langsung ke AG. Database perlu dipulihkan ke instans SQL mandiri, lalu digabungkan dengan AG.

Skenario pembuatan ulang grup ketersediaan untuk server database SQL

Pembuatan ulang grup Ketersediaan (AG), AG duplikat, dan item cadangan terdaftar sebagai item yang dapat dilindungi atau item yang dilindungi dalam skenario berikut:

  • Membuat ulang AG yang sudah dilindungi muncul sebagai AG duplikat pada halaman Konfigurasi Cadangan dan di daftar Item terproteksi. Jika Anda ingin menyimpan data cadangan yang sudah ada di AG yang lebih lama, hentikan pencadangan dengan menggunakan opsi Hentikan perlindungan dan pertahankan data sebelum membuat ulang dan menjadwalkan cadangan pada item AG baru.

    Secara desain, Azure Backup mencantumkan item duplikat pada daftar Item terproteksi, dan halaman Konfigurasi Cadangan atau daftar item yang dapat dilindungi dan menampilkan item ini hingga Anda ingin menyimpan data cadangan.

  • Jika Anda tidak ingin data cadangan dari AG yang lebih lama, hentikan operasi pencadangan dengan menggunakan opsi Hentikan perlindungan dan hapus data untuk item lama sebelum membuat ulang dan menjadwalkan cadangan pada AG baru.

    Perhatian

    Menghentikan perlindungan dan menghapus data adalah operasi yang merusak.

  • Anda dapat membuat ulang AG setelah melakukan salah satu proses Hentikan perlindungan di atas untuk menghindari kegagalan pencadangan.

Langkah berikutnya

Pelajari cara: