Bagikan melalui

Mencadangkan SQL Server selalu dalam grup ketersediaan

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 cadangan SQL untuk mengetahui selengkapnya 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 dijalankan di simpul utama terlepas dari preferensi pencadangan yang digunakan. Untuk pencadangan penuh hanya salin dan log transaksi, preferensi pencadangan AG akan dipertimbangkan saat memutuskan node tempat pencadangan akan dijalankan.

Preferensi Pencadangan AG Cadangan Penuh dan Diferensial dijalankan pada Pencadangan Copy-Only dan pencadangan Log diambil dari
Primer Replika utama Replika utama
Sekunder saja Replika utama Salah satu dari replika sekunder
Preferensi ke yang Sekunder Replika utama Replika sekunder akan dipilih, tetapi pencadangan juga dapat berjalan pada replika utama.
Tidak ada/Apa pun Replika utama Replika apapun

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 dijalankan pada semua simpul AG dan ekstensi pencadangan beban kerja pada simpul ini saling menyinkronkan untuk menentukan 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 tugas pencadangan, sedangkan tugas yang dipicu di node lain membatalkan, yaitu melewatkan tugas.

Catatan

Azure Backup tidak memperhitungkan prioritas pencadangan atau replika saat memilih di antara replika sekunder.

Mendaftarkan node AG ke penyimpanan Layanan Pemulihan

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

  • Daftarkan node utama ke vault (jika tidak dilakukan, pencadangan penuh tidak akan dapat dilakukan).
  • Daftarkan setidaknya satu node sekunder ke vault (jika tidak, pencadangan penuh log atau hanya salin tidak dapat dilakukan) jika preferensi hanya sekunder.

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

Mari kita jadikan penyebaran AG berikut ini sebagai acuan.

Diagram untuk penerapan 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 cadangan hanya sekunder, VM1 (Primer) dan VM2 (Sekunder) harus didaftarkan ke Vault 1 (karena pencadangan penuh memerlukan simpul utama 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 proses failover

Setelah AG melakukan failover ke salah satu simpul sekunder:

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

Catatan

Pemutusan rantai log tidak akan terjadi pada failover jika failover tidak bersamaan dengan cadangan.

Berdasarkan contoh penyebaran AG di atas, berikut adalah berbagai kemungkinan failover:

  • Pengalihan otomatis 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.
  • Pengalihan ke VM3 (langganan yang berbeda)
    • Karena pencadangan tidak dikonfigurasi di Brankas 2, pencadangan tidak akan dilakukan.
    • Jika preferensi pencadangan bukan hanya sekunder, pencadangan ini dapat dikonfigurasi di Vault 2 karena simpul utama terdaftar di Vault ini. Tetapi tindakan ini dapat menyebabkan konflik/kegagalan pencadangan. Selengkapnya tentang ini di Mengonfigurasi cadangan untuk AG multi-wilayah.
  • Alih fungsi ke VM4 (wilayah lain)
    • Karena pencadangan tidak dikonfigurasi di Brankas 4, maka tidak ada pencadangan yang akan dilakukan.
    • 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. Selengkapnya tentang ini di Mengonfigurasi cadangan 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 backup untuk AG yang mencakup beberapa langganan atau wilayah Azure serta pertimbangan-pertimbangan yang terkait.

  • Evaluasi apakah Anda benar-benar perlu memungkinkan pencadangan dari semua node. Jika suatu wilayah atau langganan mencakup 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 data dari titik pemulihan ini hanya dapat dilakukan untuk VM yang terdaftar di brankas yang sama.

  • Pencadangan penuh/diferensial hanya akan berhasil dilakukan di brankas yang memiliki simpul utama. Pencadangan ini di brankas lain 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

    Ada batas tegas 15 hari, setelah itu pencadangan log akan mulai gagal.

  • Pencadangan penuh hanya salin dapat digunakan di semua brankas.

  • Perlindungan pada setiap brankas dianggap sebagai sumber data yang unik dan ditagihkan secara terpisah.

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

Berdasarkan penyebaran AG contoh di atas, berikut ini adalah langkah-langkah untuk mengaktifkan cadangan dari setiap node. Asumsi adalah bahwa preferensi pencadangan terpenuhi pada setiap langkah.

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

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

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

  1. Pindahkan AG ke VM3 agar simpul utama tersedia di Vault 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 dijalankan di Vault 2 yang memutus rantai log untuk Vault 1.
  4. Kembalikan AG ke VM1.

Langkah 3: Aktifkan pencadangan di Region 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 pekerjaan 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 yang mengantre akan mulai dikerjakan.

Anda dapat mengubah nilai ini ke nilai yang lebih kecil jika pencadangan simultan menyebabkan tekanan pada memori/IO/CPU di simpul. Karena pembatasan berada pada tingkat simpul, memiliki simpul AG yang tidak seimbang dapat menyebabkan masalah sinkronisasi cadangan. Untuk memahaminya, pertimbangkan AG dengan 2 node sebagai contoh.

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 suatu titik, semua 55 pencadangan tersebut akan terpicu pada Simpul 1 dan 35 di antaranya akan mengantre. Beberapa di antaranya adalah cadangan basis data 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, proses 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 Node 1 sementara berjalan di Node 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. Ukuran total frontend dari semua database yang dilindungi pada suatu instans dibebankan. Pertimbangkan penyebaran berikut:

Diagram memperlihatkan perhitungan instans 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 terlindungi keluar atau masuk dari AG

Azure Backup mempertimbangkan instans SQL atau nama AG\Nama database sebagai nama unik database. Ketika DB mandiri dilindungi, nama uniknya adalah StandAloneInstanceName\DBName. Saat berpindah di bawah AG, nama unik berubah menjadi AGName\DBName. Cadangan untuk database mandiri akan mulai gagal dengan kode kesalahan: 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, cadangannya mulai gagal dengan kode kesalahan: UserErrorBackupFailedDatabaseMovedOutOfAG.

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

Penambahan/Penghapusan node ke dalam 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 memulai alur kerja un-configuration pada simpul yang dihapus untuk menghapus jadwal pencadangan untuk database AG dan membersihkan metadata terkait AG.

Membatalkan pendaftaran simpul AG dari Azure Backup

Jika nodus merupakan bagian dari Grup Ketersediaan (AG) yang memiliki satu atau beberapa basis data yang dikonfigurasi untuk pencadangan, maka Azure Backup tidak mengizinkan pembatalan pendaftaran nodus tersebut. Ini untuk mencegah kegagalan cadangan di masa depan jika preferensi pencadangan tidak dapat dipenuhi tanpa simpul ini. Untuk membatalkan registrasi simpul, langkah pertama Anda perlu menghapusnya dari AG. Ketika alur kerja un-configuration pada node selesai dan node tersebut sudah dibersihkan, Anda dapat membatalkan pendaftarannya.

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 dan kemudian 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:

Konten terkait

  • Last updated on