SQL Server Failover Cluster: Panduan Lengkap untuk DBA [2026]

SQL Server klaster failover adalah solusi ketersediaan tinggi yang menyimpan SQL Server Instance tetap beroperasi bahkan ketika server mengalami kegagalan. Hal ini dicapai dengan menjalankan instance yang sama di beberapa server fisik — yang disebut node — sehingga jika satu server mati, server lain secara otomatis mengambil alih tanpa memerlukan intervensi manual atau perubahan di sisi klien.

1.2 Komponen Utama dan Arsitektur

A SQL Server Instance klaster failover dibangun dari lima komponen inti, yang masing-masing memainkan peran berbeda. Bersama-sama, mereka membentuk satu unit logis tunggal yang berinteraksi dengan klien seolah-olah itu adalah satu server.

nodes: Server fisik yang berpartisipasi dalam klaster. Pada waktu tertentu, tepat satu node aktif dan menjalankan SQL Server Sebagai contoh; node yang tersisa akan siaga dan memantau kesehatan node yang aktif.
Penyimpanan bersama: Volume penyimpanan — SAN, iSCSI, Storage Spaces Direct, atau berbagi file SMB — yang dapat diakses oleh semua node secara bersamaan. Karena setiap node membaca dan menulis ke penyimpanan yang sama, tidak diperlukan replikasi data antar node, dan file basis data yang sama langsung tersedia terlepas dari node mana yang mengambil alih.
Nama jaringan virtual dan alamat IP virtual: Identitas stabil yang selalu dihubungkan oleh klien, terlepas dari node fisik mana yang saat ini aktif. Ketika terjadi failover, nama jaringan virtual dan alamat IP didaftarkan ulang pada node aktif yang baru, sehingga peralihan menjadi transparan bagi aplikasi.
Klaster Failover Windows Server (WSFC): Platform dasar yang menyatukan semuanya. WSFC terus memantau kesehatan node dan sumber daya melalui jaringan heartbeat, mengelola kepemilikan grup sumber daya, dan mengatur proses failover ketika kegagalan terdeteksi.
Kuorum: Mekanisme pemungutan suara dalam WSFC yang mencegah skenario split-brain. Setiap node memberikan suara pada kesehatan klaster; disk saksi atau berbagi file memberikan suara tambahan pada klaster dengan jumlah node genap. Klaster tetap online hanya ketika mayoritas suara dapat dicapai, memastikan bahwa dua kelompok node yang terisolasi tidak akan pernah secara bersamaan mengklaim kepemilikan klaster. SQL Server contoh.

Komponen-komponen ini bekerja dalam hierarki yang jelas: WSFC mengelola node dan menegakkan kuorum, node berbagi akses ke penyimpanan yang sama, dan nama jaringan virtual menyediakan titik koneksi yang konsisten bagi klien di seluruh jaringan tersebut. Ketika sebuah node gagal, WSFC mendeteksi hilangnya heartbeat, memastikan kuorum masih berlaku, mentransfer kepemilikan grup sumber daya — termasuk nama jaringan virtual, IP virtual, dan penyimpanan — ke node siaga, dan mengembalikannya ke kondisi semula. SQL Server kembali online di sana. Seluruh rangkaian terjadi secara otomatis dan tanpa perlu perubahan apa pun di sisi klien.

1.3 FCI vs. Always On Availability Groups

SQL Server Menyediakan dua teknologi Always On yang dibangun di atas WSFC. Perbedaan utamanya:

Instance Klaster Failover (FCI): Ketersediaan tinggi (HA) tingkat instance. Semua basis data melakukan failover secara bersamaan. Membutuhkan penyimpanan bersama. Tidak ada replikasi data antar node. Tidak ada pemulihan bencana (DR) bawaan.
Grup Ketersediaan (AG) Selalu Aktif: Ketersediaan tinggi tingkat basis data. Replikasi berbasis log ke replika sekunder. Tidak memerlukan penyimpanan bersama. Mendukung HA (High Availability) dan DR (Disaster Recovery).

Gunakan FCI untuk failover tingkat instance dengan penyimpanan bersama yang sudah ada. Gabungkan FCI dengan AG ketika pemulihan bencana atau secondary yang dapat dibaca juga diperlukan.

1.4 Manfaat dan Keterbatasan

Manfaat:

Pengalihan otomatis jika terjadi kegagalan perangkat keras, sistem operasi, atau layanan;
tidak ada konfigurasi ulang klien;
Waktu failover yang dapat diprediksi melalui checkpoint tidak langsung;
Opsi penyimpanan bersama yang fleksibel.

Keterbatasan:

Penyimpanan bersama merupakan titik kegagalan tunggal kecuali jika penyimpanan itu sendiri bersifat redundan;
Hanya satu node yang berjalan SQL Server pada satu waktu sehingga tidak ada penyeimbangan beban baca;
Tidak ada DR bawaan tanpa dipasangkan dengan AG.

2. Prasyarat dan Persyaratan

2.1 Perangkat Keras dan Perangkat Lunak

Minimal dua server fisik dengan perangkat keras yang identik atau setara, prosesor 64-bit, dan pengontrol penyimpanan yang bersertifikasi untuk failover clustering.
Windows Server 2016, 2019, atau 2022 (Standar atau Datacenter). Semua node harus menjalankan edisi OS, versi, dan tingkat pembaruan kumulatif yang sama.
SQL Server Edisi Standar atau Enterprise. Semua node harus menjalankan versi yang sama. SQL Server versi dan tingkat patch.

2.2 Persyaratan Jaringan dan Domain

Semua node harus berada dalam domain Active Directory yang sama. Klaster workgroup, klaster multi-domain, dan Read-Only Domain Controller tidak didukung.
Tetapkan alamat IP statis ke semua adaptor. Dedikasikan setidaknya satu kartu antarmuka jaringan (NIC) per node untuk lalu lintas heartbeat klaster. Konfigurasikan Sistem Nama Domain (DNS) untuk resolusi nama.
Akun instalasi memerlukan hak Administrator lokal di semua node dan Membuat Objek Komputer izin di Active Directory.

2.3 Opsi Penyimpanan Bersama

SQL Server Failover clustering mendukung beberapa teknologi penyimpanan bersama. Pilih yang paling sesuai dengan infrastruktur dan anggaran Anda:

SAN (Fibre Channel atau iSCSI): Paling umum. Semua node harus mengakses nomor unit logis (LUN) yang sama. Gunakan I/O multipath (MPIO) untuk menghindari kegagalan jalur tunggal.
Storage Spaces Direct (S2D): NVMe atau SSD yang terpasang secara lokal dan dikelola bersama di seluruh node. Membutuhkan Windows Server 2016 Datacenter atau versi yang lebih baru.
Berbagi file Server Message Block (SMB) dan Cluster Shared Volumes (CSV): Didukung dari SQL Server Mulai tahun 2014 dan seterusnya.

Format semua disk cluster sebagai Sistem File NT dasar (NTFSHindari memasang volume pada node klaster.

3. Perencanaan Klaster

Sebelum instalasi, Anda perlu merencanakan jenis konfigurasi node dan pengaturan kuorum, yang secara langsung memengaruhi keandalan klaster dan biaya perangkat keras:

3.1 Jenis Konfigurasi

SQL Server Klaster failover mendukung empat jenis konfigurasi node, masing-masing dengan keseimbangan antara kesederhanaan, biaya perangkat keras, dan kapasitas siaga yang berbeda.

Tipe 1: Aktif/Siaga. 1 FCI, 2 Node. Node 1 Aktif; Node 2 Siaga. Node Siaga memantau detak jantung Node Aktif secara terus menerus dan mengambil alih FCI ketika Node Aktif gagal. Ini adalah konfigurasi paling sederhana dan paling umum digunakan di lingkungan produksi.
Tipe 2: Aktif/Aktif. 2 FCI berbagi 2 Node fisik. Node 1 adalah Node Aktif untuk FCI 1 dan Node Siaga untuk FCI 2; Node 2 adalah Node Aktif untuk FCI 2 dan Node Siaga untuk FCI 1. Kedua Node tersebut merupakan siaga timbal balik — keduanya menangani beban kerja aktif dalam operasi normal. Jika salah satu Node gagal, Node yang bertahan akan mengambil alih FCI Node yang gagal sambil terus menjalankan FCI-nya sendiri. Oleh karena itu, setiap Node harus dirancang untuk menangani beban kerja gabungan dari kedua FCI.
Tipe 3: N+1. N FCI berbagi N+1 Node. Setiap FCI memiliki satu Node Aktif; semua N FCI berbagi satu Node Siaga umum. Node Siaga bersama harus mampu secara independen menyerap seluruh beban kerja dari setiap Node Aktif yang gagal.
Tipe 4: N+M. N FCI berbagi N+M Node. Setiap FCI memiliki satu Node Aktif; semua N FCI berbagi M Node Siaga. M Node Siaga secara kolektif mencakup failover untuk semua N Node Aktif, mendistribusikan potensi beban ke lebih banyak kapasitas siaga dan mengurangi persyaratan perangkat keras per node dibandingkan dengan N+1.

3.2 Pedoman Kuorum

Kuorum menentukan apakah klaster memiliki cukup anggota yang sehat untuk tetap online. Perhatikan pedoman berikut saat mengatur dan memelihara kuorum:

Tetapkan jumlah total suara kuorum yang ganjil untuk menjamin mayoritas dalam skenario perpecahan dan mencegah terjadinya perpecahan intelektual (split-brain).
Untuk klaster dua node, gunakan Mayoritas Node dan Disk dengan disk saksi sebagai suara ketiga. Disk saksi tidak memerlukan huruf drive.
Jika kuorum hilang sepenuhnya, paksa kuorum sebagai upaya terakhir untuk memulihkan node yang masih berfungsi, kemudian konfigurasikan ulang segera sebelum kembali ke produksi.

4. Menginstal Windows Server Failover Cluster (WSFC)

4.1 Menyiapkan Penyimpanan Bersama

Lampirkan dan konfigurasikan semua penyimpanan bersama sebelum membuat klaster.

Secara fisik, pasangkan atau sediakan semua LUN penyimpanan ke setiap node klaster.
pada hanya node pertama, Buka Disk Management, aktifkan setiap disk, inisialisasi, dan buat sebuah NTFS Buat volume dengan huruf drive. Buat volume kecil (1–2 GB) untuk disk saksi — huruf drive tidak diperlukan.
Pada setiap node yang tersisa, buka Disk Management dan hanya aktifkan disk tersebut. Jangan melakukan inisialisasi ulang atau memformat ulang. Tetapkan huruf drive secara manual jika tidak sesuai dengan node pertama.

4.2 Instal Fitur Failover Clustering dan Validasi

Instal fitur Failover Clustering pada setiap node, lalu validasi sebelum membuat cluster.

Pada setiap node, buka Server Manager -> Tambahkan Peran dan Fitur -> Fitur, pilih Pengelompokan failover, Dan klik Install. Mulai ulang jika diminta. Alternatif PowerShell:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
Pada node mana pun, buka Manajer Klaster Failover -> Validasi KonfigurasiTambahkan semua nama host node dan jalankan semua pengujian. Alternatif PowerShell:
```
Test-Cluster -Node Node1, Node2
```
Atasi semua kesalahan dalam laporan validasi sebelum melanjutkan. Peringatan Storage Spaces Direct dapat diabaikan jika S2D tidak digunakan.

4.3 Membuat WSFC

Setelah validasi berhasil, buat klaster dan verifikasi konfigurasinya.

In Manajer Klaster Failoverklik Buat Klaster, tambahkan semua nama host node, masukkan nama cluster dan alamat IP virtual statis, lalu klik SelanjutnyaAlternatif PowerShell:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
Jika izin domain dibatasi, mintalah administrator Active Directory Anda untuk menyiapkan objek komputer nama klaster terlebih dahulu sebelum menjalankan langkah ini.
Setelah pembuatan, konfirmasikan bahwa kuorum telah terpenuhi. Mayoritas Node dan Disk dengan disk saksi yang telah ditetapkan.
Bawah Storage -> Disk, ganti nama setiap disk klaster agar sesuai dengan perannya (misalnya, Data SQL, SQL_LOG, SAKSI). Di bawah Jaringan, ubah nama setiap jaringan klaster agar sesuai dengan jenis lalu lintasnya.

5. Menginstal SQL Server Instans Klaster Failover

5.1 Pilih Metode Pemasangan

SQL Server Setup menyediakan dua pendekatan untuk menginstal instance klaster failover. Pilih salah satu yang sesuai dengan lingkungan Anda.

Instalasi terintegrasi (Tambahkan Node): Instal FCI yang lengkap dan berfungsi pada node pertama, lalu tambahkan setiap node berikutnya menggunakan Tambahkan Node Opsi ini lebih sederhana dan direkomendasikan untuk sebagian besar penerapan.
Instalasi Tingkat Lanjut/Perusahaan: Run Siapkan Klaster Failover pertama-tama di semua node, lalu jalankan Klaster Failover Lengkap pada node yang memiliki disk bersama. Gunakan pendekatan ini untuk peluncuran multi-node skala besar di mana Anda ingin mempersiapkan semua node secara paralel sebelum melakukan commit.

5.2 Instalasi Node Pertama

Run SQL Server Lakukan pengaturan pada node pertama untuk membuat FCI menggunakan metode Terintegrasi.

Run Setup.exe Sebagai administrator. Pilih Instalasi -> New SQL Server instalasi klaster failover.
On Pemilihan Fitur, pilih Layanan Mesin Basis Data ke Alat Manajemen – Dasar.
On Konfigurasi Instans, Masukkan SQL Server Nama Jaringan — nama virtual yang digunakan klien untuk terhubung.
On Kelompok Sumber Daya Klaster, masukkan nama grup yang deskriptif.
On Pemilihan Disk Klaster, pilih disk bersama untuk data, log, dan file cadangan.
On Konfigurasi Jaringan Klaster, tetapkan alamat IP per subnet. Setup secara otomatis menetapkan ketergantungan OR untuk klaster multi-subnet.
On Konfigurasi Server, atur akun layanan. Gunakan Akun Layanan Terkelola Grup (gMSA) untuk manajemen kata sandi otomatis; gunakan akun domain sebagai cadangan.
On Konfigurasi Mesin Basis DataPilih mode otentikasi dan atur jalur direktori data. Tempatkan basis data sistem, basis data pengguna, log, cadangan, dan TempDB pada disk terpisah.
Tinjau ringkasan dan klik. Install.

5.3 Tambahkan Node yang Tersisa

Setelah node pertama selesai, tambahkan setiap node tambahan ke FCI.

Pada node tambahan, jalankan Setup.exe dan pilih Instalasi -> Tambahkan node ke sebuah SQL Server klaster failover.
On Konfigurasi Node Klaster, pilih instance FCI yang sudah ada.
On Konfigurasi Jaringan Klaster, tetapkan alamat IP untuk subnet node ini.
On Akun LayananKonfirmasikan bahwa kata sandi akun layanan sesuai dengan yang telah diatur pada node pertama, lalu klik. Install.
Ulangi langkah ini untuk setiap node tambahan.

6. Pasca-Instalasi: Konfigurasi dan Pengujian

6.1 Sangat Penting SQL Server Pengaturan

Terapkan pengaturan ini segera setelah FCI beroperasi.

set memori server maksimum untuk membatasi SQL Servermemori dan menyisakan ruang untuk layanan OS dan klaster:

EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;

set derajat paralelisme maksimum (MAXDOP) berdasarkan topologi Non-Uniform Memory Access (NUMA) Anda.

Pindahkan TempDB ke volume khusus untuk mengisolasi I/O-nya:

USE master;
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, FILENAME = 'D:\TempDB\tempdb.mdf');
ALTER DATABASE tempdb MODIFY FILE (NAME = templog, FILENAME = 'D:\TempDB\templog.ldf');

Mulai kembali SQL Server layanan agar pemindahan file dapat berlaku.

6.2 Pengujian Failover

Validasi perilaku failover sebelum memindahkan klaster ke lingkungan produksi.

In Manajer Klaster Failover, klik kanan SQL Server Peran dan seleksi FCI Pindah -> Pilih NodePilih node sekunder dan klik OK.
Tunggu hingga status peran muncul Running pada node baru.
Dari mesin klien, sambungkan ke SQL Server Gunakan nama jaringan virtual dan konfirmasikan bahwa koneksi berhasil tanpa mengubah string koneksi.
Tinjau SQL Server log kesalahan dan log peristiwa klaster Windows untuk memastikan failover yang bersih dalam target waktu pemulihan (RTO) Anda.

7. Manajemen, Praktik Terbaik, dan Pemecahan Masalah

7.1 Kebijakan dan Pemantauan Failover

In Manajer Klaster Failover, klik kanan SQL Server Peran FCI -> Properties -> Failover Untuk mengatur tingkat kondisi kegagalan dan batas waktu pemeriksaan kesehatan. Tingkatkan batas waktu pada server yang bebannya berat untuk menghindari failover palsu.
Pantau kesehatan klaster melalui Manajer Klaster Failover, Penampil Acara Windows, yang SQL Server log kesalahan, dan SQL Server Activity Monitor untuk visibilitas sumber daya dan sesi secara real-time.
Setelah terjadi failover otomatis, tinjau kembali SQL Server Log diagnostik (disimpan bersama log kesalahan) untuk status komponen sebelum terjadinya peristiwa. Gunakan SQL Server Acara yang Diperpanjang untuk menangkap jejak rinci tentang kesehatan sumber daya dan kondisi kesalahan di sekitar jendela failover.

7.2 Praktik Terbaik

Gunakan IP statis pada semua node. Masa berlaku lease Dynamic Host Configuration Protocol (DHCP) selama failover memperpanjang downtime dan mempersulit pendaftaran DNS.
Pertahankan jumlah suara kuorum ganjil setiap saat. Tambahkan saksi jika penambahan node membuat jumlahnya menjadi genap.
Lakukan validasi klaster setelah setiap perubahan perangkat keras, pembaruan driver, atau perubahan konfigurasi OS yang signifikan.
Tetapkan huruf drive yang identik pada semua node sebelum SQL Server Instalasi. Ketidaksesuaian menghambat pengaturan dan sulit diperbaiki setelahnya.
Hubungi administrator Active Directory Anda sebelum hari instalasi. Izin pembuatan objek komputer adalah penghambat pra-instalasi yang paling umum.
Pertahankan yang telah diuji SQL Server backup Strategi ini tetap berlaku meskipun FCI sudah diterapkan. FCI melindungi dari kegagalan node, bukan dari kerusakan data, penghapusan yang tidak disengaja, atau kehilangan data di tingkat penyimpanan — pencadangan dan pemulihan rutin adalah satu-satunya pengaman untuk skenario tersebut.

7.3 Masalah Umum dan Perbaikannya

Kesalahan izin Active Directory: Minta administrator Active Directory (AD) Anda untuk melakukan pra-penyiapan objek komputer klaster, atau berikan izin. Membuat Objek Komputer ke Baca Semua Properti ke akun instalasi.
Penyimpanan bersama tidak terlihat pada node: Mulai kembali Server Target iSCSI Layanan pada host penyimpanan, kemudian sambungkan kembali dari inisiator iSCSI pada setiap node. Verifikasi masking dan zoning LUN.
Peringatan validasi pada driver atau tingkat pembaruan: Terapkan pembaruan kumulatif terbaru dari Windows Update pada semua node sebelum menjalankan validasi ulang.
WSFC offline setelah terjadi kegagalan node: Gunakan force quorum untuk mengaktifkan node yang masih berfungsi, memulihkan basis data apa pun Jika terdampak oleh kegagalan tersebut, pulihkan kuorum, lalu konfigurasikan ulang sebelum kembali ke produksi. Jalankan DBCC CHECKDB pada setiap basis data yang dipulihkan untuk memastikan integritas sebelum melanjutkan beban kerja normal.
Pengalihan otomatis yang salah: Tingkatkan batas waktu pemeriksaan kesehatan di properti peran FCI. Tinjau log diagnostik untuk membedakan kegagalan sebenarnya dari lonjakan sumber daya sementara.

8. Tanya Jawab

T: Berapa jumlah minimum node yang dibutuhkan untuk sebuah SQL Server Klaster failover?

A: Minimal dua node. Satu bertindak sebagai node aktif yang menjalankan SQL Server satu sebagai instance; yang lainnya sebagai cadangan. Sebagian besar penerapan produksi dimulai dengan konfigurasi dua node Aktif/Pasif.

T: Apakah SQL Server Apakah FCI memerlukan penyimpanan bersama?

A: Ya. Tidak seperti Always On Availability Group, FCI mengharuskan semua node untuk mengakses penyimpanan yang sama — baik SAN (Fibre Channel atau iSCSI), Storage Spaces Direct, atau berbagi file SMB. Penyimpanan bersama inilah yang memungkinkan file basis data yang sama dapat diakses dari node mana pun setelah terjadi failover.

T: Apa SQL Server Apakah edisi-edisi tersebut mendukung failover clustering?

A: SQL Server Edisi Standard dan Enterprise mendukung FCI. Edisi Express dan Developer tidak mendukungnya. Edisi Enterprise mendukung lebih banyak node dan fitur ketersediaan tinggi tambahan seperti operasi indeks online selama pemeliharaan.

Q: Bisa SQL Server Apakah FCI dan Always On Availability Group dapat digunakan bersamaan?

A: Ya. Node FCI dapat menjadi host replika grup ketersediaan, sehingga Anda mendapatkan HA tingkat instance dari FCI dan DR tingkat basis data dari grup ketersediaan. Namun, failover otomatis grup ketersediaan ke atau dari replika yang dihosting FCI tidak didukung — hanya failover manual yang tersedia dalam konfigurasi tersebut.

T: Berapa lama SQL Server Proses failover biasanya memakan waktu berapa lama?

A: Waktu failover bergantung pada jumlah halaman kotor di buffer cache yang harus ditulis ke disk sebelum instance dimulai ulang pada node baru. Dengan checkpoint tidak langsung diaktifkan (default dari SQL Server (mulai tahun 2012 dan seterusnya), halaman yang mengalami perubahan data dibatasi, dan sebagian besar proses failover selesai dalam waktu kurang dari 30 detik. RTO aktual Anda bergantung pada beban kerja, kecepatan penyimpanan, dan waktu pemulihan basis data.

T: Apa itu kuorum, dan mengapa itu penting?

A: Quorum adalah mekanisme yang digunakan WSFC untuk menentukan apakah klaster memiliki cukup anggota yang sehat untuk tetap online dan melayani permintaan. Ini mencegah skenario split-brain di mana dua kelompok node yang terisolasi masing-masing percaya bahwa mereka adalah pemilik otoritatif dari permintaan tersebut. SQL Server Sebagai contoh, jika kuorum hilang, WSFC akan menonaktifkan klaster untuk melindungi integritas data.

Q: Bisa SQL Server Apakah FCI dapat diinstal pada klaster workgroup (tanpa Active Directory)?

J: Tidak. SQL Server FCI mensyaratkan semua node menjadi anggota domain Active Directory yang sama. Klaster workgroup, klaster multi-domain, dan klaster yang menyertakan Read-Only Domain Controller bukanlah konfigurasi yang didukung.

T: Apa yang terjadi pada koneksi klien ketika terjadi failover?

A: Koneksi aktif ke SQL Server Instance akan terputus selama proses failover. Setelah instance online di node baru, nama jaringan virtual dan IP virtual akan didaftarkan ulang di sana, dan klien yang menggunakan logika percobaan ulang dalam string koneksi mereka akan terhubung kembali secara otomatis tanpa perubahan konfigurasi apa pun.

T: Dapatkah saya menambahkan atau menghapus node dari yang sudah ada? SQL Server Klaster failover?

A: Ya. Lari SQL Server Lakukan pengaturan pada node mana pun dan pilih Tambahkan node ke sebuah SQL Server klaster failover untuk menambahkan node, atau Hapus node dari sebuah SQL Server klaster failover untuk menghapus satu node. Menambahkan atau menghapus node tidak memerlukan waktu henti (downtime) untuk node lain dalam cluster.

T: Apa perbedaan antara failover terencana dan failover otomatis?

A: Failover terencana diinisiasi secara manual oleh administrator — biasanya untuk pemeliharaan seperti patching atau penggantian perangkat keras. Ini memungkinkan SQL Server untuk membersihkan halaman yang kotor dan mematikan sistem dengan bersih sebelum mentransfer kepemilikan, sehingga menghasilkan waktu henti minimal. Failover otomatis dipicu oleh WSFC ketika pemantauan kesehatan mendeteksi bahwa node aktif telah gagal, dan waktu pemulihan bergantung pada jumlah pemulihan kerusakan yang diperlukan.

T: Bagaimana cara saya memulihkan SQL Server Klaster failover jika seluruh WSFC offline?

A: Jika kuorum hilang dan klaster tidak dapat memulai secara normal, gunakan force quorum untuk mengaktifkan node yang masih berfungsi dalam keadaan non-toleransi kesalahan. Jalankan perintah PowerShell berikut pada node yang masih berfungsi: Start-ClusterNode -ForcQuorumSetelah klaster online, pulihkan basis data, verifikasi integritas data, lalu konfigurasikan ulang kuorum dengan node yang tersisa sebelum kembali ke produksi.

T: Apakah saya harus menjalankan Cluster Validation Wizard sebelum setiap SQL Server instalasi?

A: Ya, dan juga setelah perubahan perangkat keras atau konfigurasi yang signifikan. Microsoft hanya mendukung konfigurasi klaster failover yang lolos semua uji validasi tanpa kesalahan. Melewatkan validasi berisiko menjalankan konfigurasi yang tidak didukung yang mungkin berperilaku tidak terduga dalam kondisi kegagalan.

9. Kesimpulan

SQL Server Failover clustering menghadirkan ketersediaan tinggi tingkat instance yang transparan melalui WSFC, dengan failover otomatis dan tanpa konfigurasi ulang klien yang diperlukan. Ini adalah pilihan yang tepat ketika penyimpanan bersama tersedia dan Anda membutuhkan setiap basis data pada instance untuk melakukan failover bersama sebagai satu unit. Untuk lingkungan yang juga membutuhkan pemulihan bencana atau beban kerja baca sekunder, pasangkan FCI dengan Always On Availability Groups untuk mencakup kedua skenario tersebut.

Referensi

Dokumen Resmi Microsoft: Klaster Failover Windows Server dengan SQL Server
Dokumen Resmi Microsoft: Instans Klaster Failover Selalu Aktif
Dokumen Resmi Microsoft: Instal Instance Klaster Failover
Dokumen Resmi Microsoft: Mode Kuorum WSFC dan Konfigurasi Pemungutan Suara

tentang Penulis

Yuan Sheng adalah administrator basis data senior (DBA) dengan lebih dari 10 tahun pengalaman di SQL Server lingkungan dan manajemen basis data perusahaan. Ia telah berhasil menyelesaikan ratusan skenario pemulihan basis data di berbagai organisasi jasa keuangan, layanan kesehatan, dan manufaktur.

Yuan mengkhususkan diri dalam SQL Server Pemulihan basis data, solusi ketersediaan tinggi, dan optimasi kinerja. Pengalaman langsungnya yang luas mencakup pengelolaan basis data multi-terabyte, penerapan Always On Availability Group, dan pengembangan strategi pencadangan dan pemulihan otomatis untuk sistem bisnis yang sangat penting.

Melalui keahlian teknis dan pendekatan praktisnya, Yuan berfokus pada pembuatan panduan komprehensif yang membantu administrator basis data dan profesional TI memecahkan masalah kompleks SQL Server tantangan secara efisien. Dia selalu mengikuti perkembangan terbaru SQL Server rilis dan teknologi basis data Microsoft yang terus berkembang, secara berkala menguji skenario pemulihan untuk memastikan rekomendasinya mencerminkan praktik terbaik di dunia nyata.

Memiliki pertanyaan tentang SQL Server pemulihan atau butuh panduan pemecahan masalah basis data tambahan? Yuan menyambut masukan dan saran untuk meningkatkan sumber daya teknis ini.