SQL Server Failover Cluster: Kumpletong Gabay para sa DBA [2026]

SQL Server Ang failover cluster ay isang solusyon na may mataas na availability na nagpapanatili ng isang SQL Server gumagana ang instance kahit na nabigo ang isang server. Nakakamit nito ito sa pamamagitan ng pagpapatakbo ng parehong instance sa maraming pisikal na server — na tinatawag na mga node — upang kung sakaling bumagsak ang isang server, awtomatikong papalit ang isa nang hindi nangangailangan ng manu-manong interbensyon o mga pagbabago sa panig ng kliyente.

1.2 Mga Pangunahing Bahagi at Arkitektura

A SQL Server Ang failover cluster instance ay binuo mula sa limang pangunahing bahagi, na bawat isa ay gumaganap ng isang natatanging papel. Magkasama, bumubuo sila ng isang lohikal na yunit na nakikipag-ugnayan sa mga kliyente na parang isang server lamang.

Node: Ang mga pisikal na server na kalahok sa cluster. Sa anumang oras, eksaktong isang node ang aktibo at nagpapatakbo ng SQL Server halimbawa; ang mga natitirang node ay nakatambay at sinusubaybayan ang kalusugan ng aktibong node.
Ibinahaging imbakan: Isang dami ng imbakan — SAN, iSCSI, Storage Spaces Direct, o SMB file share — ang sabay-sabay na naa-access ng lahat ng node. Dahil ang bawat node ay nagbabasa at nagsusulat sa parehong imbakan, hindi kinakailangan ang pagkopya ng data sa pagitan ng mga node, at ang parehong mga file ng database ay agad na magagamit alinmang node ang pumalit.
Pangalan ng virtual na network at virtual na IP address: Isang matatag na pagkakakilanlan na laging kinokonekta ng mga kliyente, anuman ang pisikal na node na kasalukuyang aktibo. Kapag nagkaroon ng failover, ang pangalan ng virtual network at IP address ay muling irerehistro sa bagong aktibong node, na ginagawang transparent sa mga application ang switchover.
Pag-clustering ng Windows Server Failover (WSFC): Ang pinagbabatayang plataporma na nagbubuklod sa lahat. Patuloy na sinusubaybayan ng WSFC ang kalusugan ng node at resource sa pamamagitan ng isang heartbeat network, pinamamahalaan ang pagmamay-ari ng resource group, at inaayos ang proseso ng failover kapag may natukoy na failure.
Korum: Isang mekanismo ng pagboto sa loob ng WSFC na pumipigil sa mga senaryo ng split-brain. Ang bawat node ay bumoboto sa kalusugan ng cluster; ang isang witness disk o file share ay nagbibigay ng karagdagang boto sa mga even-node cluster. Ang cluster ay mananatili lamang online kapag ang mayoryang boto ay maabot, na tinitiyak na ang dalawang nakahiwalay na grupo ng node ay hindi kailanman maaaring sabay na mag-angkin ng pagmamay-ari ng SQL Server halimbawa.

Ang mga bahaging ito ay gumagana sa isang malinaw na hirarkiya: Pinamamahalaan ng WSFC ang mga node at ipinapatupad ang quorum, ang mga node ay nagbabahagi ng access sa parehong storage, at ang pangalan ng virtual network ay nagbibigay sa mga kliyente ng isang pare-parehong connection point sa lahat ng ito. Kapag nabigo ang isang node, nade-detect ng WSFC ang pagkawala ng heartbeat, kinukumpirma na mayroon pa ring quorum, inililipat ang pagmamay-ari ng resource group — kabilang ang pangalan ng virtual network, virtual IP, at storage — sa isang standby node, at dinadala SQL Server online na ulit doon. Awtomatikong nangyayari ang buong pagkakasunod-sunod at walang kinakailangang pagbabago sa panig ng kliyente.

1.3 Mga Grupo ng FCI vs Always On Availability

SQL Server ay nagbibigay ng dalawang teknolohiyang Always On na binuo sa WSFC. Ang mga pangunahing pagkakaiba:

Instance ng Failover Cluster (FCI): Mataas na availability (HA) sa antas ng instance. Lahat ng database ay magkakasamang nabibigo. Nangangailangan ng shared storage. Walang replikasyon ng data sa pagitan ng mga node. Walang built-in na disaster recovery (DR).
Mga Grupo ng Always On Availability (AG): Mataas na availability sa antas ng database. Replikasyon batay sa log sa mga pangalawang replika. Hindi kinakailangan ang nakabahaging imbakan. Sinusuportahan ang parehong HA at DR.

Gamitin ang FCI para sa instance-level failover kasama ang kasalukuyang shared storage. Pagsamahin ang FCI sa isang AG kapag kinakailangan din ang disaster recovery o readable secondaries.

1.4 Mga Benepisyo at Limitasyon

Benepisyo:

Awtomatikong failover sa pagkabigo ng hardware, OS, o serbisyo;
walang muling pagsasaayos ng kliyente;
nahuhulaang oras ng failover sa pamamagitan ng mga hindi direktang checkpoint;
mga nababaluktot na opsyon sa ibinahaging imbakan.

Limitasyon:

Ang shared storage ay isang nag-iisang punto ng pagkabigo maliban kung ang storage mismo ay kalabisan;
Isang node lang ang tumatakbo SQL Server sa isang pagkakataon kaya walang read load balancing;
Walang built-in na DR kung hindi kakabit ng AG.

2. Mga Kinakailangan at Paunang Kinakailangan

2.1 Hardware at Software

Minimum na dalawang pisikal na server na may magkapareho o katumbas na hardware, 64-bit processors, at storage controllers na sertipikado para sa failover clustering.
Windows Server 2016, 2019, o 2022 (Standard o Datacenter). Dapat magpatakbo ang lahat ng node ng parehong edisyon, bersyon, at antas ng pinagsama-samang pag-update ng OS.
SQL Server Edisyong Standard o Enterprise. Dapat pareho ang pagpapatakbo ng lahat ng node SQL Server bersyon at antas ng patch.

2.2 Mga Kinakailangan sa Network at Domain

Dapat kabilang ang lahat ng node sa iisang Active Directory domain. Hindi sinusuportahan ang mga workgroup cluster, multi-domain cluster, at Read-Only Domain Controller.
Magtalaga ng mga static na IP address sa lahat ng adapter. Maglaan ng kahit isang network interface card (NIC) bawat node para sa trapiko ng cluster heartbeat. I-configure ang Domain Name System (DNS) para sa resolusyon ng pangalan.
Ang account sa pag-install ay nangangailangan ng mga lokal na karapatan ng Administrator sa lahat ng mga node at Gumawa ng mga Bagay sa Kompyuter pahintulot sa Active Directory.

2.3 Mga Opsyon sa Ibinahaging Imbakan

SQL Server Sinusuportahan ng failover clustering ang ilang shared storage technologies. Piliin ang pinakaangkop sa iyong imprastraktura at badyet:

SAN (Fibre Channel o iSCSI): Pinakakaraniwan. Dapat i-access ng lahat ng node ang parehong logical unit numbers (LUNs). Gumamit ng multipath I/O (MPIO) upang maiwasan ang single-path failure.
Mga Storage Spaces Direct (S2D): Lokal na nakakabit na NVMe o SSD na pinagsama-sama sa mga node. Nangangailangan ng Windows Server 2016 Datacenter o mas bago.
Mga pagbabahagi ng file ng Server Message Block (SMB) at Cluster Shared Volumes (CSV): Sinuportahan mula sa SQL Server 2014 pataas.

I-format ang lahat ng cluster disk bilang pangunahing NT File System (NTFSIwasan ang mga naka-mount na volume sa mga cluster node.

3. Pagpaplano ng Klaster

Bago ang pag-install, kailangan mong planuhin ang uri ng configuration ng node at ang quorum setup, na direktang nakakaapekto sa cluster reliability at gastos sa hardware:

3.1 Mga Uri ng Konpigurasyon

SQL Server Sinusuportahan ng mga failover cluster ang apat na uri ng mga configuration ng node, na ang bawat isa ay nagpapalit ng simplisidad, gastos sa hardware, at kapasidad ng standby nang iba.

Uri 1: Aktibo/Naka-standby. 1 FCI, 2 Node. Ang Node 1 ay Aktibo; Ang Node 2 ay Standby. Ang Standby Node ay patuloy na nagmomonitor ng tibok ng puso ng Active Node at humahawak sa FCI kapag nabigo ang Active Node. Ito ang pinakasimpleng configuration at pinakakaraniwan sa produksyon.
Uri 2: Aktibo/Aktibo. 2 FCI na naghahati ng 2 pisikal na Node. Ang Node 1 ay ang Active Node para sa FCI 1 at ang Standby Node para sa FCI 2; ang Node 2 ay ang Active Node para sa FCI 2 at ang Standby Node para sa FCI 1. Ang dalawang Node ay magkaparehong standby — parehong may dalang live workload sa ilalim ng normal na operasyon. Kung sakaling mabigo ang alinmang Node, ang natitirang Node ang hahawak sa FCI ng nabigong Node habang patuloy na nagpapatakbo ng sarili nitong Node. Samakatuwid, ang bawat Node ay dapat na sukatin upang mahawakan ang pinagsamang workload ng parehong FCI.
Uri 3: N+1. N FCI na naghahati ng N+1 Node. Ang bawat FCI ay may isang Active Node; lahat ng N FCI ay naghahati ng iisang karaniwang Standby Node. Ang pinaghahatiang Standby Node ay dapat may kakayahang hiwalay na tanggapin ang buong workload ng alinmang isang bigong Active Node.
Uri 4: N+M. N FCI na nagbabahagi ng N+M Nodes. Ang bawat FCI ay may isang Active Node; lahat ng N FCI ay nagbabahagi ng M Standby Nodes. Sama-samang sinasaklaw ng M Standby Nodes ang failover para sa lahat ng N Active Nodes, na ipinamamahagi ang potensyal na load sa mas maraming standby capacity at binabawasan ang mga kinakailangan sa hardware bawat node kumpara sa N+1.

3.2 Mga Alituntunin sa Korum

Ang Quorum ang nagtatakda kung ang cluster ay may sapat na malulusog na miyembro upang manatiling online. Isaisip ang mga sumusunod na alituntunin kapag nagse-set up at nagpapanatili ng quorum:

Mag-configure ng kakaibang kabuuang bilang ng mga boto sa korum upang garantiyahan ang mayorya sa isang split-brain scenario at maiwasan ang split-brain.
Para sa mga kumpol na may dalawang node, gamitin ang Mayorya ng Node at Disk na may witness disk bilang ikatlong boto. Hindi kailangan ng drive letter ang witness disk.
Kung tuluyang nawala ang quorum, pilitin ang quorum bilang huling paraan upang mabawi ang mga natitirang node, pagkatapos ay i-reconfigure kaagad bago bumalik sa produksyon.

4. Pag-install ng Windows Server Failover Cluster (WSFC)

4.1 Ihanda ang Ibinahaging Imbakan

Ikabit at i-configure ang lahat ng shared storage bago gawin ang cluster.

Pisikal na ikabit o i-provision ang lahat ng storage LUN sa bawat cluster node.
Sa unang node lamang, bukas Disk management, i-online ang bawat disk, i-initialize ito, at lumikha ng isang NTFS volume gamit ang drive letter. Gumawa ng maliit na volume (1–2 GB) para sa witness disk — hindi kinakailangan ang drive letter.
Sa bawat natitirang node, buksan Disk management at i-online lamang ang mga disk. Huwag muling i-initialize o i-reformat. Manu-manong magtalaga ng mga drive letter kung hindi tugma ang mga ito sa unang node.

4.2 I-install ang Failover Clustering Feature at Patunayan

I-install ang feature na Failover Clustering sa bawat node, pagkatapos ay i-validate bago gawin ang cluster.

Sa bawat node, buksan Server Manager -> Magdagdag ng Mga Tungkulin at Tampok -> Mga tampok, piliin Failover Clustering, at i-click I-installI-reboot kung sinenyasan. Alternatibo sa PowerShell:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
Sa kahit anong node, buksan Tagapamahala ng Kumpol ng Failover -> Patunayan ang KonfigurasyonIdagdag ang lahat ng hostname ng node at patakbuhin ang lahat ng pagsubok. Alternatibo sa PowerShell:
```
Test-Cluster -Node Node1, Node2
```
Ayusin ang lahat ng error sa ulat ng pagpapatunay bago magpatuloy. Maaaring balewalain ang mga direktang babala sa mga Storage Space kung hindi ginagamit ang S2D.

4.3 Buuin ang WSFC

Pagkatapos maipasa ang pagpapatunay, gawin ang cluster at i-verify ang configuration nito.

In Tagapamahala ng Kumpol ng Failover, I-click ang Lumikha ng Cluster, idagdag ang lahat ng node hostname, ilagay ang pangalan ng cluster at isang static virtual IP address, pagkatapos ay i-click ang susunodAlternatibo sa PowerShell:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
Kung pinaghihigpitan ang mga pahintulot ng domain, hilingin sa iyong Active Directory administrator na i-pre-stage ang pangalan ng cluster computer object bago isagawa ang hakbang na ito.
Pagkatapos malikha, kumpirmahin ang pagpapakita ng korum Mayorya ng Node at Disk kasama ang nakatalagang witness disk.
Sa ilalim Imbakan -> disks, palitan ang pangalan ng bawat cluster disk upang maipakita ang papel nito (halimbawa, SQL_DATA, SQL_LOG, WITNESS). Sa ilalim Network, palitan ang pangalan ng bawat cluster network upang maipakita ang uri ng trapiko nito.

5. Pag-install SQL Server Instance ng Failover Cluster

5.1 Pumili ng Paraan ng Pag-install

SQL Server Ang setup ay nagbibigay ng dalawang paraan para sa pag-install ng isang failover cluster instance. Piliin ang isa na tumutugma sa iyong environment.

Pinagsamang pag-install (Magdagdag ng Node): Mag-install ng kumpleto at gumaganang FCI sa unang node, pagkatapos ay idagdag ang bawat kasunod na node gamit ang Idagdag ang Node opsyon. Mas simple at inirerekomenda para sa karamihan ng mga deployment.
Pag-install ng Advanced/Enterprise: Tumakbo Ihanda ang Failover Cluster sa lahat ng node muna, pagkatapos ay patakbuhin Kumpletong Kumpol ng Failover sa node na nagmamay-ari ng shared disk. Gamitin ang paraang ito para sa malalaking multi-node rollouts kung saan gusto mong ihanda ang lahat ng node nang parallel bago mag-commit.

5.2 Pag-install ng Unang Node

Tumakbo SQL Server I-setup sa unang node para malikha ang FCI gamit ang Integrated method.

Tumakbo Setup.exe bilang isang administrador. Piliin instalasyon -> bago SQL Server pag-install ng failover cluster.
On Pagpili ng Tampok, piliin ang Mga Serbisyo ng Database Engine at Mga Kagamitan sa Pamamahala – Pangunahing Kaalaman.
On Configuration ng Instance, pumasok sa SQL Server Pangalan ng Network — ang virtual na pangalan na ginagamit ng mga kliyente para kumonekta.
On Grupo ng Mapagkukunan ng Kumpol, maglagay ng naglalarawang pangalan ng grupo.
On Pagpili ng Disk ng Kumpol, piliin ang mga nakabahaging disk para sa data, log, at mga backup file.
On Pag-configure ng Network ng Kumpol, magtalaga ng IP address bawat subnet. Awtomatikong nagtatakda ang setup ng OR dependency para sa mga multi-subnet cluster.
On Server Configuration, magtakda ng mga service account. Gumamit ng Group Managed Service Account (gMSA) para sa awtomatikong pamamahala ng password; gumamit ng mga domain account bilang fallback.
On Pag-configure ng Database Engine, pumili ng authentication mode at magtakda ng data directory paths. Ilagay ang mga system database, user database, log, backup, at TempDB sa magkakahiwalay na disk.
Suriin ang buod at i-click ang I-install.

5.3 Magdagdag ng mga Natitirang Node

Pagkatapos makumpleto ang unang node, idagdag ang bawat karagdagang node sa FCI.

Sa karagdagang node, patakbuhin Setup.exe at piliin ang instalasyon -> Magdagdag ng node sa isang SQL Server kumpol ng failover.
On Konpigurasyon ng mga Cluster Node, piliin ang kasalukuyang instance ng FCI.
On Pag-configure ng Network ng Kumpol, italaga ang IP address para sa subnet ng node na ito.
On Mga Account ng Serbisyo, kumpirmahin na ang mga password ng service account ay tumutugma sa mga nakatakda sa unang node, pagkatapos ay i-click ang I-install.
Ulitin para sa bawat karagdagang node.

6. Pagkatapos ng Pag-install: I-configure at Subukan

6.1 Mahahalaga SQL Server Setting

Ilapat ang mga setting na ito kaagad pagkatapos na gumana ang FCI.

Itakda pinakamataas na memorya ng server takpan SQL Servermemorya at mag-iwan ng headroom para sa mga serbisyo ng OS at cluster:
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;
```
Itakda pinakamataas na antas ng paralelismo (MAXDOP) batay sa iyong Non-Uniform Memory Access (NUMA) topology.

Ilipat ang TempDB sa isang nakalaang volume upang ihiwalay ang I/O nito:

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');

I-restart ang SQL Server serbisyo para magkabisa ang paglipat ng file.

6.2 Pagkabigo sa Pagsubok

Patunayan ang gawi ng failover bago ilipat ang cluster sa produksyon.

In Tagapamahala ng Kumpol ng Failover, i-right-click ang SQL Server Tungkulin at pagpili ng FCI Ilipat -> Piliin ang NodePiliin ang pangalawang node at i-click ang OK.
Maghintay hanggang sa lumabas ang status ng role Tumatakbo sa bagong node.
Mula sa isang client machine, kumonekta sa SQL Server gamit ang pangalan ng virtual network at kumpirmahin na matagumpay ang koneksyon nang hindi binabago ang string ng koneksyon.
Repasuhin ang SQL Server error log at Windows cluster event log para kumpirmahin ang isang malinis na failover sa loob ng iyong target na recovery time objective (RTO).

7. Pamamahala, Pinakamahuhusay na Kasanayan, at Pag-troubleshoot

7.1 Patakaran at Pagsubaybay sa Failover

In Tagapamahala ng Kumpol ng Failover, i-right-click ang SQL Server Tungkulin ng FCI -> Mga Katangian -> Pagkabigo para itakda ang antas ng kondisyon ng pagkabigo at timeout ng health check. Taasan ang timeout sa mga server na puno ng karga para maiwasan ang mga maling failover.
Subaybayan ang kalusugan ng kumpol sa pamamagitan ng Tagapamahala ng Kumpol ng Failover, Windows Event Viewer, ang SQL Server talaan ng error, at SQL Server Aktibo Monitor para sa real-time na kakayahang makita ang mapagkukunan at sesyon.
Pagkatapos ng anumang awtomatikong failover, suriin ang SQL Server mga diagnostic log (nakaimbak kasama ng error log) para sa estado ng component bago ang kaganapan. Gamitin SQL Server Mga Pinalawak na Kaganapan upang makuha ang detalyadong bakas ng kalusugan at mga kondisyon ng error ng mapagkukunan sa paligid ng failover window.

7.2 Pinakamahusay na Kasanayan

Gumamit ng mga static IP sa lahat ng node. Ang pag-expire ng lease ng Dynamic Host Configuration Protocol (DHCP) habang failover ay nagpapahaba sa downtime at nagpapakomplikado sa pagpaparehistro ng DNS.
Panatilihin ang kakaibang bilang ng mga boto ng korum sa lahat ng oras. Magdagdag ng saksi kung ang pagdaragdag ng node ay magpapapantay sa bilang.
Patakbuhin ang cluster validation pagkatapos ng anumang pagbabago sa hardware, pag-update ng driver, o malaking pagbabago sa configuration ng OS.
Magtalaga ng magkakaparehong drive letter sa lahat ng node bago SQL Server pag-install. Hinaharangan ng mga hindi pagtutugma ang Setup at mahirap ayusin pagkatapos.
Makipag-ugnayan sa iyong Active Directory administrator bago ang araw ng pag-install. Ang mga pahintulot sa paglikha ng computer object ang pinakakaraniwang humaharang bago ang pag-install.
Panatilihin ang isang nasubukan SQL Server backup estratehiya kahit na may FCI. Pinoprotektahan ng FCI ang node failure, hindi laban sa data corruption, aksidenteng pagbura, o pagkawala ng storage-level — ang regular na iskedyul ng backup at restore ang tanging pananggalang para sa mga sitwasyong iyon.

7.3 Mga Karaniwang Isyu at Pag-aayos

Mga error sa pahintulot sa Active Directory: Hilingin sa iyong Active Directory (AD) admin na i-pre-stage ang cluster computer object, o bigyan ng Gumawa ng mga Bagay sa Kompyuter at Basahin ang Lahat ng Ari-arian sa account ng pag-install.
Hindi nakikita ang nakabahaging imbakan sa mga node: I-restart ang iSCSI Target Server serbisyo sa storage host, pagkatapos ay muling kumonekta mula sa iSCSI initiator sa bawat node. I-verify ang LUN masking at zoning.
Mga babala sa pagpapatunay sa mga driver o antas ng pag-update: Ilapat ang pinakabagong pinagsama-samang update mula sa Windows Update sa lahat ng node bago muling patakbuhin ang pagpapatunay.
Nag-offline ang WSFC matapos ang pagkabigo ng node: Gamitin ang force quorum para mai-online ang mga nakaligtas na node, mabawi ang anumang mga database apektado ng pagkabigo, ibalik ang quorum, pagkatapos ay i-reconfigure bago bumalik sa produksyon. Patakbuhin DBCC CHECKDB sa bawat na-recover na database upang kumpirmahin ang integridad bago ipagpatuloy ang mga normal na workload.
Mga maling awtomatikong failover: Dagdagan ang timeout ng health check sa mga katangian ng role ng FCI. Suriin ang mga diagnostic log upang makilala ang isang tunay na pagkabigo mula sa isang transient resource spike.

8. Mga FAQ

T: Ano ang pinakamababang bilang ng mga node na kinakailangan para sa isang SQL Server kumpol ng failover?

A: Dalawang node ang pinakamababa. Isa ang gumaganap bilang aktibong node na nagpapatakbo ng SQL Server halimbawa; ang isa pa ay ang standby. Karamihan sa mga production deployment ay nagsisimula sa isang two-node Active/Passive configuration.

Q: Ba SQL Server Nangangailangan ba ang FCI ng shared storage?

A: Oo. Hindi tulad ng Always On Availability Groups, hinihiling ng isang FCI na ma-access ng lahat ng node ang parehong storage — alinman sa isang SAN (Fibre Channel o iSCSI), Storage Spaces Direct, o isang SMB file share. Ang shared storage ang siyang dahilan kung bakit naa-access ang parehong mga database file mula sa anumang node pagkatapos ng failover.

T: Ano SQL Server Sinusuportahan ba ng mga edisyon ang failover clustering?

A: SQL Server Sinusuportahan ng mga edisyong Standard at Enterprise ang FCI. Hindi naman sa mga edisyong Express at Developer. Sinusuportahan ng edisyong Enterprise ang mas maraming node at karagdagang mga tampok na may mataas na availability tulad ng mga operasyon sa online index habang nasa maintenance.

Q: Maaari SQL Server Gagamitin ba nang magkasama ang FCI at Always On Availability Groups?

A: Oo. Maaaring mag-host ang isang FCI node ng isang availability group replica, na magbibigay sa iyo ng parehong instance-level HA mula sa FCI at database-level DR mula sa availability group. Gayunpaman, hindi sinusuportahan ang awtomatikong failover ng availability group papunta o mula sa isang FCI-hosted replica — tanging manual failover lamang ang available sa configuration na iyon.

T: Gaano katagal ang isang SQL Server karaniwang nangyayari ang failover?

A: Ang oras ng failover ay nakadepende sa bilang ng mga maruruming pahina sa buffer cache na dapat isulat sa disk bago mag-restart ang instance sa bagong node. Kapag naka-enable ang mga indirect checkpoint (ang default ay mula sa SQL Server (mula 2012 pataas), ang mga maruruming pahina ay may limitasyon, at karamihan sa mga failover ay nakukumpleto sa loob ng wala pang 30 segundo. Ang iyong aktwal na RTO ay nakadepende sa workload, bilis ng storage, at oras ng pagbawi ng database.

T: Ano ang quorum, at bakit ito mahalaga?

A: Ang Quorum ay ang mekanismong ginagamit ng WSFC upang matukoy kung ang cluster ay may sapat na malulusog na miyembro upang manatiling online at maglingkod sa mga kahilingan. Pinipigilan nito ang isang split-brain scenario kung saan ang dalawang nakahiwalay na node group ay naniniwala na sila ang awtoritatibong may-ari ng SQL Server halimbawa. Kung mawala ang quorum, isasara ng WSFC ang cluster upang protektahan ang integridad ng data.

Q: Maaari SQL Server Mai-install ba ang FCI sa isang workgroup cluster (nang walang Active Directory)?

A: Hindi. SQL Server Kinakailangan ng FCI na ang lahat ng node ay maging miyembro ng iisang Active Directory domain. Ang mga workgroup cluster, multi-domain cluster, at mga cluster na may kasamang Read-Only Domain Controller ay hindi sinusuportahang mga configuration.

T: Ano ang nangyayari sa mga koneksyon ng kliyente kapag nagkaroon ng failover?

A: Mga aktibong koneksyon sa SQL Server Ang mga instance ay itatapon habang isinasagawa ang failover. Kapag online na ang instance sa bagong node, ang pangalan ng virtual network at virtual IP ay muling irerehistro doon, at ang mga client na gumagamit ng retry logic sa kanilang mga connection string ay awtomatikong muling kokonekta nang walang anumang pagbabago sa configuration.

T: Maaari ba akong magdagdag o mag-alis ng mga node mula sa isang umiiral na SQL Server kumpol ng failover?

A: Oo. Tumakbo SQL Server I-setup sa kahit anong node at piliin Magdagdag ng node sa isang SQL Server kumpol ng failover para magdagdag ng node, o Alisin ang node mula sa isang SQL Server kumpol ng failover para mag-alis ng isa. Ang pagdaragdag o pag-alis ng isang node ay hindi nangangailangan ng downtime para sa iba pang mga node sa cluster.

T: Ano ang pagkakaiba sa pagitan ng planadong failover at awtomatikong failover?

A: Ang isang nakaplanong failover ay manu-manong sinisimulan ng isang administrator — kadalasan para sa maintenance tulad ng patching o pagpapalit ng hardware. Pinapayagan nito SQL Server para i-flush ang mga maruruming pahina at malinis na isara bago ilipat ang pagmamay-ari, na magreresulta sa kaunting downtime. Isang awtomatikong failover ang nati-trigger ng WSFC kapag natukoy ng health monitoring na nabigo ang aktibong node, at ang oras ng pagbawi ay nakadepende sa dami ng kinakailangang pagbawi mula sa pag-crash.

T: Paano ko mababawi ang isang SQL Server failover cluster kung ang buong WSFC ay mag-offline?

A: Kung nawala ang quorum at hindi makapagsimula nang normal ang cluster, gamitin ang force quorum upang maibalik ang mga natitirang node sa online sa isang non-fault-tolerant state. Patakbuhin ang sumusunod na PowerShell command sa mga natitirang node: Start-ClusterNode -ForcQuorumKapag online na ang cluster, i-recover ang mga database, i-verify ang integridad ng data, at pagkatapos ay i-reconfigure ang quorum gamit ang mga natitirang node bago bumalik sa produksyon.

T: Dapat ko bang patakbuhin ang Cluster Validation Wizard bago ang bawat SQL Server pag-install?

A: Oo, at pagkatapos din ng anumang makabuluhang pagbabago sa hardware o configuration. Sinusuportahan lamang ng Microsoft ang mga configuration ng failover cluster na pumasa sa lahat ng mga pagsubok sa pagpapatunay nang walang mga error. Ang paglaktaw sa pagpapatunay ay nanganganib na magpatakbo ng isang hindi sinusuportahang configuration na maaaring kumilos nang hindi mahulaan sa ilalim ng mga kondisyon ng pagkabigo.

9. Konklusyon

SQL Server Ang failover clustering ay naghahatid ng transparent na instance-level high availability sa pamamagitan ng WSFC, na may awtomatikong failover at hindi kinakailangan ng client reconfiguration. Ito ang tamang pagpipilian kapag available ang shared storage at kailangan mong mag-fail over nang sama-sama ang bawat database sa instance bilang isang unit. Para sa mga environment na nangangailangan din ng disaster recovery o secondary read workloads, ipares ang FCI sa Always On Availability Groups upang masakop ang parehong senaryo.

Mga sanggunian

Opisyal na Dokumento ng Microsoft: Windows Server Failover Cluster na may SQL Server
Opisyal na Dokumento ng Microsoft: Mga Instance ng Palaging Naka-on na Failover Cluster
Opisyal na Dokumento ng Microsoft: Mag-install ng Failover Cluster Instance
Opisyal na Dokumento ng Microsoft: Mga Mode ng Quorum ng WSFC at Konpigurasyon ng Pagboto

Tungkol sa Author

Yuan Sheng ay isang senior database administrator (DBA) na may higit sa 10 taong karanasan sa SQL Server kapaligiran at pamamahala ng database ng enterprise. Matagumpay niyang nalutas ang daan-daang mga sitwasyon sa pagbawi ng database sa mga serbisyong pinansyal, pangangalaga sa kalusugan, at mga organisasyon sa pagmamanupaktura.

Dalubhasa si Yuan sa SQL Server pagbawi ng database, mga solusyon sa mataas na kakayahang magamit, at pag-optimize ng pagganap. Kasama sa kanyang malawak na karanasan sa hands-on ang pamamahala ng mga multi-terabyte na database, pagpapatupad ng Always On Availability Groups, at pagbuo ng mga automated na backup at mga diskarte sa pagbawi para sa mission-critical na mga sistema ng negosyo.

Sa pamamagitan ng kanyang teknikal na kadalubhasaan at praktikal na diskarte, nakatuon si Yuan sa paglikha ng mga komprehensibong gabay na tumutulong sa mga administrator ng database at mga propesyonal sa IT na malutas ang kumplikado SQL Server mga hamon nang mahusay. Nananatili siyang napapanahon sa pinakabago SQL Server mga release at mga umuunlad na teknolohiya ng database ng Microsoft, na regular na sumusubok sa mga senaryo sa pagbawi upang matiyak na ang kanyang mga rekomendasyon ay sumasalamin sa mga pinakamahusay na kagawian sa totoong mundo.

May mga katanungan tungkol sa SQL Server pagbawi o kailangan ng karagdagang gabay sa pag-troubleshoot ng database? bati ni Yuan puna at mungkahi para sa pagpapabuti ng mga teknikal na mapagkukunang ito.