Pemulihan Bencana WSFC melalui Kuorum Paksa (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 node di kluster WSFC. Intervensi manual diperlukan untuk pemulihan dari kegagalan kuorum.

Sebelum Memulai

Prasyarat

Prosedur Kuorum Paksa mengasumsikan bahwa kuorum 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 spesifik 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 menjadi 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, SQL Server instans, dan grup ketersediaan AlwaysOn, di kluster WSFC diatur secara offline, karena kluster, seperti yang dikonfigurasi, tidak dapat memastikan toleransi kesalahan tingkat simpul. Kegagalan kuorum berarti bahwa simpul pemungutan suara yang sehat di kluster WSFC tidak lagi memenuhi model kuorum. Beberapa node mungkin telah 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 voting 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 Pulih 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 SQL Server responsif, 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 secara normal 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, ia bernegosiasi dengan node sehat lainnya untuk menyinkronkan status konfigurasi kluster baru. Ingatlah untuk melakukan simpul yang 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 simpul online baru lainnya. Pertimbangkan untuk menonaktifkan layanan WSFC pada simpul lain. Jika tidak, Anda berisiko membuat lebih dari satu set simpul kuorum; itu adalah skenario split-brain. Jika temuan Anda di langkah 1 akurat, ini seharusnya tidak terjadi.

  4. Terapkan mode kuorum baru dan konfigurasi pemungutan suara simpul. Jika memaksa kuorum berhasil memulai ulang semua simpul 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 node sebagaimana mestinya. 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 Manajer 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 membuatnya 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 membuat 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 simpul yang gagal dan menyesuaikan konfigurasi WSFC dan Always On terkait yang sesuai. Ini dapat mencakup menghilangkan replika grup ketersediaan, mengusir simpul dari kluster, atau meratakan dan menginstal ulang perangkat lunak pada node.

    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. Jika replika yang gagal tidak diperbaiki atau dihapus dari grup ketersediaan, log transaksi akan tumbuh dan Anda akan mengalami risiko kehabisan ruang log transaksi pada replika lain.

    Catatan

    Jika Anda menjalankan Panduan Validasi Konfigurasi WSFC saat pendengar grup ketersediaan ada di kluster WSFC, wizard akan 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 kegagalan yang sesuai dan ketersediaan tinggi untuk operasi yang sehat.

  3. Melakukan analisis RPO/RTO. Anda harus menganalisis SQL Server log sistem, 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