Bagikan melalui

Pemulihan Bencana WSFC melalui Forced Quorum (SQL Server)

  • Artikel

Berlaku untuk: SQL Server

Kegagalan kuorum biasanya disebabkan oleh bencana sistemik, atau kegagalan komunikasi terus-menerus, atau kesalahan konfigurasi yang melibatkan beberapa simpul di kluster WSFC. Intervensi manual diperlukan untuk pemulihan dari kegagalan kuorum.

Sebelum Memulai

Prasyarat

Prosedur Kuorum Paksa mengasumsikan bahwa kuorum yang sehat ada sebelum kegagalan kuorum.

Peringatan

Pengguna harus diberi tahu dengan baik tentang konsep dan interaksi Pengklusteran Failover Windows Server, Model Kuorum WSFC, SQL Server, dan konfigurasi penyebaran khusus lingkungan.

Untuk informasi selengkapnya, lihat: Pengklusteran Failover Windows Server (WSFC) dengan SQL Server, Mode Kuorum WSFC, dan Konfigurasi Pemungutan Suara (SQL Server)

Keamanan

Pengguna harus merupakan akun domain yang merupakan anggota grup Administrator lokal pada setiap simpul kluster WSFC.

Pemulihan Bencana WSFC melalui Prosedur Kuorum Paksa

Ingat bahwa kegagalan kuorum akan menyebabkan semua layanan berkluster, instans SQL Server, dan grup ketersediaan AlwaysOn, di kluster WSFC diatur offline, karena kluster, seperti yang dikonfigurasi, tidak dapat memastikan toleransi kesalahan tingkat node. Kegagalan kuorum berarti bahwa node pemungutan suara yang sehat di kluster WSFC tidak lagi memenuhi model kuorum. Beberapa simpul mungkin gagal sepenuhnya, dan beberapa mungkin baru saja mematikan layanan WSFC dan sebaliknya sehat, kecuali hilangnya kemampuan untuk berkomunikasi dengan kuorum.

Untuk membuat kluster WSFC kembali online, Anda harus memperbaiki akar penyebab kegagalan kuorum di bawah konfigurasi yang ada, memulihkan database yang terpengaruh sesuai kebutuhan, dan Anda mungkin ingin mengonfigurasi ulang node yang tersisa di kluster WSFC untuk mencerminkan topologi kluster yang masih ada.

Anda dapat menggunakan prosedur kuorum paksa pada node kluster WSFC untuk mengambil alih kontrol keamanan yang membuat kluster offline. Ini secara efektif memberi tahu kluster untuk menangguhkan pemeriksaan pemungutan suara kuorum, dan memungkinkan Anda membawa sumber daya kluster WSFC dan SQL Server kembali online pada salah satu simpul dalam kluster.

Jenis proses pemulihan bencana ini harus mencakup langkah-langkah berikut:

Untuk Memulihkan dari Kegagalan Kuorum:

  1. Tentukan cakupan kegagalan. Identifikasi grup ketersediaan atau instans SQL Server mana yang tidak responsif, simpul kluster mana yang online dan tersedia untuk penggunaan pasca bencana, dan periksa log peristiwa Windows dan log sistem SQL Server. Jika praktis, Anda harus mempertahankan data forensik dan log sistem untuk analisis nanti.

    Tip

    Pada instans responsif SQL Server, Anda dapat memperoleh informasi tentang kesehatan grup ketersediaan yang memiliki replika ketersediaan pada instans server lokal dengan mengkueri tampilan manajemen dinamis (DMV) sys.dm_hadr_availability_group_states.

  2. Mulai kluster WSFC dengan menggunakan kuorum paksa pada satu simpul. Identifikasi node dengan jumlah kegagalan komponen minimal, selain itu layanan kluster WSFC dimatikan. Verifikasi bahwa simpul ini dapat berkomunikasi dengan sebagian besar simpul lain.

    Pada simpul ini, paksa kluster secara manual untuk online menggunakan prosedur kuorum paksa. Untuk meminimalkan potensi kehilangan data, pilih simpul yang terakhir menghosting replika utama grup ketersediaan.

    Untuk informasi selengkapnya, lihat: Memaksa Kluster WSFC untuk Memulai Tanpa Kuorum

    Catatan

    Pengaturan kuorum paksa memiliki pengaruh di seluruh kluster untuk memblokir pemeriksaan kuorum sampai kluster WSFC logis mencapai sebagian besar suara dan secara otomatis beralih ke mode operasi kuorum reguler.

  3. Mulai layanan WSFC biasanya pada setiap node yang sehat, satu per satu. Anda tidak perlu menentukan opsi kuorum paksa saat memulai layanan kluster pada simpul lain.

    Ketika layanan WSFC pada setiap node kembali online, layanan ini bernegosiasi dengan simpul sehat lainnya untuk menyinkronkan status konfigurasi kluster baru. Ingatlah untuk melakukan simpul satu ini pada satu waktu untuk mencegah potensi kondisi balapan dalam menyelesaikan status kluster terakhir yang diketahui.

    Peringatan

    Pastikan bahwa setiap simpul yang Anda mulai dapat berkomunikasi dengan node online lainnya. Pertimbangkan untuk menonaktifkan layanan WSFC pada simpul lain. Jika tidak, Anda menjalankan risiko membuat lebih dari satu set node kuorum; itu adalah skenario split-brain. Jika temuan Anda di langkah 1 akurat, ini seharusnya tidak terjadi.

  4. Terapkan mode kuorum baru dan konfigurasi suara simpul. Jika memaksa kuorum berhasil memulai ulang semua node dalam kluster dan akar penyebab kegagalan kuorum telah diperbaiki, perubahan pada mode kuorum asli dan konfigurasi suara simpul tidak perlu.

    Jika tidak, Anda harus mengevaluasi node kluster yang baru dipulihkan dan topologi replika ketersediaan, dan mengubah mode kuorum dan penetapan suara untuk setiap simpul yang sesuai. Simpul yang tidak dipulihkan harus diatur offline atau memiliki suara simpul yang diatur ke nol.

    Tip

    Pada titik ini, simpul dan instans SQL Server dalam kluster mungkin tampak dipulihkan kembali ke operasi reguler. Namun, kuorum yang sehat mungkin masih belum ada. Menggunakan Pengelola Kluster Failover, atau Dasbor AlwaysOn dalam SQL Server Management Studio, atau DMV yang sesuai, verifikasi bahwa kuorum telah dipulihkan.

  5. Pulihkan replika database grup ketersediaan sesuai kebutuhan. Database grup non-ketersediaan harus pulih dan kembali online sendiri sebagai bagian dari proses startup SQL Server reguler.

    Anda dapat meminimalkan potensi kehilangan data dan waktu pemulihan untuk replika grup ketersediaan dengan membawanya kembali online dalam urutan ini: replika utama, replika sekunder sinkron, replika sekunder asinkron.

Catatan

Setelah menggunakan kuorum paksa, perlu untuk melakukan failover paksa dengan kemungkinan kehilangan data untuk membawa grup ketersediaan kembali online. Untuk informasi selengkapnya, tinjau Melakukan failover manual paksa grup ketersediaan (SQL Server).

  1. Perbaiki atau ganti komponen yang gagal dan validasi ulang kluster. Sekarang setelah Anda pulih dari bencana awal dan kegagalan kuorum, Anda harus memperbaiki atau mengganti node yang gagal dan menyesuaikan konfigurasi WSFC dan AlwaysOn terkait. Ini dapat mencakup menghilangkan replika grup ketersediaan, mengusir simpul dari kluster, atau meratakan dan menginstal ulang perangkat lunak pada simpul.

    Anda harus memperbaiki atau menghapus semua replika ketersediaan yang gagal. SQL Server tidak akan memotong log transaksi melewati titik terakhir yang diketahui dari replika ketersediaan terjauh di belakang. Jika replika yang gagal tidak diperbaiki atau dihapus dari grup ketersediaan, log transaksi akan tumbuh dan Anda akan menjalankan risiko kehabisan ruang log transaksi pada replika lain.

    Catatan

    Jika Anda menjalankan Wizard Validasi Konfigurasi WSFC saat pendengar grup ketersediaan ada di kluster WSFC, wizard menghasilkan pesan peringatan yang salah berikut ini:

    "Properti RegisterAllProviderIP untuk nama jaringan 'Name:<network_name>' diatur ke 1 Untuk konfigurasi kluster saat ini, nilai ini harus diatur ke 0."

    Abaikan pesan ini.

  2. Ulangi langkah 4 sesuai kebutuhan. Tujuannya adalah untuk membangun kembali tingkat toleransi kesalahan yang sesuai dan ketersediaan tinggi untuk operasi yang sehat.

  3. Lakukan analisis RPO/RTO. Anda harus menganalisis log sistem SQL Server, tanda waktu database, dan log peristiwa Windows untuk menentukan akar penyebab kegagalan, dan untuk mendokumentasikan titik pemulihan aktual dan pengalaman waktu pemulihan.

Tugas Terkait

Konten Terkait

Lihat Juga

Pengklusteran Failover Windows Server (WSFC) dengan SQL Server