SQL Server Failover Cluster: Kompletní průvodce pro DBA [2026]

SQL Server failover cluster je řešení s vysokou dostupností který udržuje SQL Server instance je funkční i v případě selhání serveru. Toho dosahuje spuštěním stejné instance na více fyzických serverech – nazývaných uzly – takže pokud jeden server selže, jiný server automaticky převezme jeho provoz bez nutnosti ručního zásahu nebo změn na straně klienta.

1.2 Klíčové komponenty a architektura

A SQL Server Instance failover clusteru je sestavena z pěti základních komponent, z nichž každá hraje odlišnou roli. Společně tvoří jednu logickou jednotku, se kterou klienti interagují, jako by se jednalo o jeden server.

Uzly: Fyzické servery, které se účastní clusteru. V daném okamžiku je aktivní právě jeden uzel, na kterém běží SQL Server instance; zbývající uzly jsou v pohotovostním režimu a monitorují stav aktivního uzlu.
Sdílené úložiště: Úložný svazek – SAN, iSCSI, Storage Spaces Direct nebo sdílená složka SMB – přístupný všem uzlům současně. Protože každý uzel čte ze stejného úložiště a zapisuje do stejného úložiště, není mezi uzly nutná replikace dat a stejné databázové soubory jsou okamžitě k dispozici bez ohledu na to, který uzel převezme kontrolu.
Název virtuální sítě a virtuální IP adresa: Stabilní identita, ke které se klienti vždy připojují bez ohledu na to, který fyzický uzel je aktuálně aktivní. V případě selhání se název virtuální sítě a IP adresa znovu zaregistrují na novém aktivním uzlu, čímž se přepnutí stane transparentním pro aplikace.
Clustering Windows Server Failover (WSFC): Základní platforma, která drží vše pohromadě. WSFC nepřetržitě monitoruje stav uzlů a zdrojů prostřednictvím sítě heartbeat, spravuje vlastnictví skupin zdrojů a orchestruje proces failoveru, když je detekována chyba.
Kvorum: Hlasovací mechanismus v rámci WSFC, který zabraňuje scénářům s rozděleným mozkem. Každý uzel hlasuje o stavu clusteru; svědecký disk nebo sdílená složka souborů poskytuje další hlas pro clustery sudých uzlů. Cluster zůstává online pouze tehdy, když je dosažitelná většina hlasů, což zajišťuje, že dvě izolované skupiny uzlů si nikdy nemohou současně nárokovat vlastnictví. SQL Server instance.

Tyto komponenty fungují v jasném harmonickém režimu.rarchy: WSFC spravuje uzly a vynucuje kvorum, uzly sdílejí přístup ke stejnému úložišti a název virtuální sítě poskytuje klientům konzistentní bod připojení napříč celým uzlem. Když uzel selže, WSFC detekuje ztrátu prezenčního signálu, potvrdí, že kvorum je stále platné, převede vlastnictví skupiny zdrojů – včetně názvu virtuální sítě, virtuální IP adresy a úložiště – na záložní uzel a přenese... SQL Server zpět online. Celá sekvence probíhá automaticky a bez nutnosti jakýchkoli změn na straně klienta.

1.3 Skupiny dostupnosti FCI vs. Always On

SQL Server nabízí dvě technologie Always On postavené na WSFC. Klíčové rozdíly:

Instance failover clusteru (FCI): Vysoká dostupnost (HA) na úrovni instance. Všechny databáze selhávají současně. Vyžaduje sdílené úložiště. Žádná replikace dat mezi uzly. Žádná vestavěná obnova po havárii (DR).
Skupiny dostupnosti Always On (AG): Vysoká dostupnost na úrovni databáze. Replikace na základě protokolů do sekundárních replik. Není vyžadováno žádné sdílené úložiště. Podporuje HA i DR.

Použijte FCI pro failover na úrovni instance se stávajícím sdíleným úložištěm. Zkombinujte FCI s AG, pokud je vyžadována také obnova po havárii nebo čitelné sekundární úložiště.

1.4 Výhody a omezení

Výhody:

Automatické přepnutí na záložní systém při selhání hardwaru, operačního systému nebo služby;
žádná rekonfigurace klienta;
předvídatelná doba přepnutí na záložní systém prostřednictvím nepřímých kontrolních bodů;
flexibilní možnosti sdíleného úložiště.

Omezení:

Sdílené úložiště je jediným bodem selhání, pokud samotné úložiště není redundantní;
Běží pouze jeden uzel SQL Server najednou, takže nedochází k vyvažování zátěže čtení;
Bez spárování s AG není k dispozici vestavěný DR.

2. Předpoklady a požadavky

2.1 Hardware a software

Minimálně dva fyzické servery se stejným nebo ekvivalentním hardwarem, 64bitovými procesory a řadiči úložišť certifikovanými pro failover clustering.
Windows Server 2016, 2019 nebo 2022 (Standard nebo Datacenter). Všechny uzly musí používat stejnou edici, verzi a úroveň kumulativní aktualizace operačního systému.
SQL Server Standardní nebo Enterprise edice. Všechny uzly musí běžet na stejném SQL Server verze a úroveň záplaty.

2.2 Požadavky na síť a doménu

Všechny uzly musí patřit do stejné domény služby Active Directory. Clustery pracovních skupin, clustery s více doménami a řadiče domény pouze pro čtení nejsou podporovány.
Přiřaďte statické IP adresy všem adaptérům. Vyhraďte alespoň jednu síťovou kartu (NIC) na uzel pro provoz prezenčního signálu clusteru. Nakonfigurujte systém DNS (Domain Name System) pro rozlišení názvů.
Instalační účet vyžaduje lokální administrátorská práva na všech uzlech a Vytváření počítačových objektů oprávnění v Active Directory.

2.3 Možnosti sdíleného úložiště

SQL Server Failover clustering podporuje několik technologií sdíleného úložiště. Vyberte si tu, která nejlépe vyhovuje vaší infrastruktuře a rozpočtu:

SAN (Fibre Channel nebo iSCSI): Most společné. Všechny uzly musí přistupovat ke stejným číslům logických jednotek (LUN). Použijte vícecestný I/O (MPIO), abyste se vyhnuli selháním jedné cesty.
Přímé úložné prostory (S2D): Lokálně připojený NVMe nebo SSD disk sdružený mezi uzly. Vyžaduje Windows Server 2016 Datacenter nebo novější.
Sdílené soubory protokolu SMB (Server Message Block) a sdílené svazky clusteru (CSV): Podporováno z SQL Server 2014 a dále.

Naformátujte všechny disky clusteru jako základní souborový systém NT (NTFS). Vyhněte se připojení svazků na uzlech clusteru.

3. Plánování klastru

Před instalací je třeba naplánovat typ konfigurace uzlu a nastavení kvora, které přímo ovlivňují spolehlivost clusteru a hardwarovou náročnost.ost:

3.1 Typy konfigurace

SQL Server Failover clustery podporují čtyři typy konfigurací uzlů, přičemž každý z nich nabízí kompromisy v jednoduchosti, hardwarových funkcích a...osta pohotovostní kapacitu odlišně.

Typ 1: Aktivní/Pohotovostní režim. 1 FCI, 2 uzly. Uzel 1 je aktivní; Uzel 2 je v pohotovostním režimu. Pohotovostní uzel nepřetržitě monitoruje srdeční tep aktivního uzlu a přebírá FCI, když aktivní uzel selže. Toto je nejjednodušší konfigurace a most běžné ve výrobě.
Typ 2: Aktivní/Aktivní. 2 FCI sdílející 2 fyzické uzly. Uzel 1 je aktivním uzlem pro FCI 1 a záložním uzlem pro FCI 2; uzel 2 je aktivním uzlem pro FCI 2 a záložním uzlem pro FCI 1. Tyto dva uzly jsou vzájemně záložními – oba nesou aktivní zátěž za normálního provozu. Pokud kterýkoli z uzlů selže, přeživší uzel převezme FCI porouchaného uzlu a zároveň bude pokračovat v provozu své vlastní. Každý uzel proto musí být dimenzován tak, aby zvládl kombinovanou zátěž obou FCI.
Typ 3: N+1. N FCI sdílejících N+1 uzlů. Každé FCI má jeden aktivní uzel; všech N FCI sdílí jeden společný záložní uzel. Sdílený záložní uzel musí být schopen nezávisle absorbovat plnou zátěž kteréhokoli selhavého aktivního uzlu.
Typ 4: N+M. N uzlů FCI sdílí N+M uzlů. Každé FCI má jeden aktivní uzel; všech N uzlů FCI sdílí M záložních uzlů. M záložních uzlů kolektivně pokrývají failover pro všech N aktivních uzlů, čímž rozdělují potenciální zátěž mezi větší záložní kapacitu a snižují hardwarové požadavky na uzel ve srovnání s N+1.

3.2 Pokyny pro kvórum

Kvorum určuje, zda má cluster dostatek zdravých členů, aby zůstal online. Při nastavování a udržování kvora mějte na paměti následující pokyny:

Nakonfigurujte lichý celkový počet hlasů pro kvorum, abyste zaručili většinu v případě rozdělení hlasů a zabránili rozdělení mozku.
Pro clustery se dvěma uzly použijte Většina uzlů a disků s diskem svědka jako třetím hlasem. Disk svědka nepotřebuje písmeno jednotky.
Pokud je kvorum lost zcela, vynutit kvorum jako poslední možnost k obnovení přeživších uzlů a poté je bezprostředně před návratem do produkčního režimu překonfigurovat.

4. Instalace clusteru Windows Server Failover (WSFC)

4.1 Příprava sdíleného úložiště

Před vytvořením clusteru připojte a nakonfigurujte veškeré sdílené úložiště.

Fyzicky připojte nebo zřiďte všechny úložné LUN ke každému uzlu clusteru.
Na pouze první uzel, otevřeno Správa disků, připojte každý disk online, inicializujte ho a vytvořte NTFS svazek s písmenem jednotky. Vytvořte malý svazek (1–2 GB) pro svědecký disk – písmeno jednotky není vyžadováno.
Na každém zbývajícím uzlu otevřete Správa disků a disky pouze přepněte do režimu online. Neprovádějte reinicializaci ani formátování. Pokud písmena jednotek neodpovídají prvnímu uzlu, přiřaďte je ručně.

4.2 Instalace funkce Failover Clustering a ověření

Nainstalujte funkci Failover Clustering na každý uzel a poté ji před vytvořením clusteru ověřte.

Na každém uzlu otevřete Server manager -> Přidat role a funkce -> Funkcevyberte Klastrování při selhání, a klepněte na tlačítko instalovatRestartujte, pokud budete vyzváni. Alternativa k PowerShellu:
```
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
```
Na libovolném uzlu otevřete Správce failover clusteru -> Ověření konfiguracePřidejte všechny uzly hostnázvy a spusťte všechny testy. Alternativa k PowerShellu:
```
Test-Cluster -Node Node1, Node2
```
Před pokračováním opravte všechny chyby v ověřovací zprávě. Varování Storage Spaces Direct lze ignorovat, pokud se S2D nepoužívá.

4.3 Vytvoření WSFC

Po úspěšném ověření vytvořte cluster a ověřte jeho konfiguraci.

In Správce failover clusteru, Klepněte na tlačítko Vytvořit Cluster, přidejte všechny uzly hostnázvy, zadejte název clusteru a statickou virtuální IP adresu a poté klikněte na dalšíAlternativa k PowerShellu:
```
New-Cluster -Name ClusterName -Node Node1, Node2 -StaticAddress x.x.x.x
```
Pokud jsou oprávnění domény omezena, požádejte správce služby Active Directory o předběžnou přípravu objektu počítače s názvem clusteru před spuštěním tohoto kroku.
Po vytvoření potvrďte kvorum Většina uzlů a disků s přiřazeným svědeckým diskem.
Pod Skladování -> Disky, přejmenujte každý disk clusteru tak, aby odrážel jeho roli (například SQL_DATA, SQL_LOG, SVĚDEK). Pod Sítě, přejmenujte každou síť clusteru tak, aby odrážela typ jejího provozu.

5. Instalace SQL Server Instance failover clusteru

5.1 Výběr metody instalace

SQL Server Instalační program nabízí dva přístupy k instalaci instance failover clusteru. Vyberte ten, který odpovídá vašemu prostředí.

Integrovaná instalace (Přidat uzel): Nainstalujte kompletní a funkční FCI na první uzel a poté přidejte každý další uzel pomocí Přidat uzel možnost. Jednodušší a doporučená pro most nasazení.
Pokročilá/podniková instalace: Běh Příprava failover clusteru nejprve na všech uzlech a poté spustit Kompletní failover cluster na uzlu, který vlastní sdílený disk. Tento přístup použijte pro rozsáhlé implementace s více uzly, kde chcete před potvrzením připravit všechny uzly paralelně.

5.2 Instalace prvního uzlu

Běh SQL Server Nastavení na prvním uzlu pro vytvoření FCI pomocí integrované metody.

Běh Setup.exe jako správce. Vyberte Instalace -> Nový SQL Server instalace failover clusteru.
On Výběr funkcízvolte Služby databázového stroje a Nástroje pro správu – základní.
On Konfigurace instance, zadejte SQL Server Název sítě – virtuální název, který klienti používají pro připojení.
On Skupina zdrojů klastru, zadejte popisný název skupiny.
On Výběr disku clusteru, vyberte sdílené disky pro data, protokoly a záložní soubory.
On Konfigurace sítě clusteru, přiřaďte IP adresu každé podsíti. Instalační program automaticky nastaví závislost OR pro clustery s více podsítěmi.
On Konfigurace serveru, nastavit servisní účty. Pro automatickou správu hesel použijte skupinový spravovaný servisní účet (gMSA); doménové účty použijte jako záložní řešení.
On Konfigurace databázového enginu, zvolte režim ověřování a nastavte cesty k adresářům s daty. Umístěte systémové databáze, uživatelské databáze, protokoly, zálohy a dočasnou databázi na samostatné disky.
Projděte si shrnutí a klikněte instalovat.

5.3 Přidání zbývajících uzlů

Po dokončení prvního uzlu přidejte do FCI každý další uzel.

Na dalším uzlu spusťte Setup.exe a zvolte Instalace -> Přidat uzel do SQL Server clusteru s podporou převzetí služeb při selhání.
On Konfigurace uzlů clusteru, vyberte existující instanci FCI.
On Konfigurace sítě clusteru, přiřaďte IP adresu pro podsíť tohoto uzlu.
On Servisní účty, ověřte, zda se hesla servisních účtů shodují s hesly nastavenými na prvním uzlu, a poté klikněte na instalovat.
Opakujte pro každý další uzel.

6 Post-Instalace: Konfigurace a testování

6.1 Essential SQL Server Nastavení

Tato nastavení použijte ihned po uvedení FCI do provozu.

sada maximální paměť serveru až do konce SQL Serverpaměť a ponechání prostoru pro operační systém a clusterové služby:
```
EXEC sp_configure 'show advanced options', 1; RECONFIGURE;
EXEC sp_configure 'max server memory', <value_in_MB>; RECONFIGURE;
```
sada maximální stupeň paralelismu (MAXDOP) na základě vaší topologie NUMA (Non-Uniform Memory Access).

Přesunutím databáze TempDB na vyhrazený svazek izolujete její I/O operace:

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

Restart SQL Server služba, aby se přesun souboru projevil.

6.2 Testovací failover

Před přesunutím clusteru do produkčního prostředí ověřte chování při failoveru.

In Správce failover clusteru, klepněte pravým tlačítkem na ikonu SQL Server Role a výběr FCI Pohyb -> Vyberte UzelVyberte sekundární uzel a klikněte na OK.
Počkejte, až se zobrazí stav role Běh na novém uzlu.
Z klientského počítače se připojte k SQL Server pomocí názvu virtuální sítě a potvrďte úspěšné připojení beze změny připojovacího řetězce.
Recenze SQL Server protokol chyb a protokol událostí clusteru Windows pro potvrzení čistého převzetí služeb při selhání ve vašem tarzískat cílovou dobu zotavení (RTO).

7. Řízení, osvědčené postupy a řešení problémů

7.1 Zásady a monitorování failoveru

In Správce failover clusteru, klepněte pravým tlačítkem na ikonu SQL Server Úloha FCI -> Nemovitosti -> Failover nastavit úroveň stavu selhání a časový limit kontroly stavu. Na silně zatížených serverech prodlužte časový limit, abyste předešli falešným přepnutím při selhání.
Monitorování stavu clusteru pomocí Správce failover clusteru, Windows Prohlížeč událostíse SQL Server protokol chyb a SQL Server Activity Monitor pro přehled o zdrojích a relacích v reálném čase.
Po jakémkoli automatickém přepnutí služeb při selhání zkontrolujte SQL Server diagnózaostprotokoly ic (uložené vedle protokolu chyb) pro stav komponenty předcházející události. Použijte SQL Server Rozšířené události zachytit podrobný záznam stavu zdrojů a chybových stavů v rámci okna přepnutí služeb při selhání.

7.2 osvědčených postupů

Používejte statické IP adresy na všech uzlech. Dynamická IP adresaost Vypršení platnosti pronájmu protokolu DHCP (Configuration Protocol) během failoveru prodlužuje dobu výpadku a komplikuje registraci DNS.
Vždy udržujte lichý počet hlasů pro kvórum. Pokud přidání uzlu vede k sudému počtu, přidejte svědka.
Spusťte ověření clusteru po jakékoli změně hardwaru, aktualizaci ovladače nebo významné změně konfigurace operačního systému.
Před přiřazením stejných písmen jednotek všem uzlům SQL Server instalace. Neshody blokují instalaci a je těžké je později opravit.
Před instalací se obraťte na správce služby Active Directory. Oprávnění k vytváření objektů v počítači jsou most běžný blokátor před instalací.
Udržujte otestovaný SQL Server zálohování strategie i s aktivním FCI. FCI chrání před selháním uzlu, nikoli před poškozením dat, náhodným smazáním nebo ztrátou úložiště – pravidelný plán zálohování a obnovy je pro tyto scénáře jedinou ochranou.

7.3 Běžné problémy a jejich řešení

Chyby oprávnění služby Active Directory: Požádejte správce služby Active Directory (AD) o předběžnou přípravu objektu počítače clusteru nebo o udělení Vytváření počítačových objektů a Přečíst všechny vlastnosti k instalačnímu účtu.
Sdílené úložiště není na uzlech viditelné: Restart iSCSI Tarzískat server služba na úložném prostoru hosta poté se znovu připojte z iniciátoru iSCSI na každém uzlu. Ověřte maskování a zónování LUN.
Varování ověření ovladačů nebo úrovní aktualizací: Použijte nejnovější kumulativní aktualizaci z Windows Update na všech uzlech před opětovným spuštěním ověření.
WSFC se po selhání uzlu přepne do režimu offline: Použijte vynucené kvorum k uvedení přeživších uzlů do provozu, obnovit jakékoli databáze postižené selháním, obnovte kvorum a poté proveďte novou konfiguraci před návratem do produkčního režimu. Spusťte DBCC CHECKDB u každé obnovené databáze pro ověření integrity před obnovením běžné pracovní zátěže.
Falešné automatické přepnutí při selhání: Prodlužte časový limit kontroly stavu ve vlastnostech role FCI. Zkontrolujte diagnostiku.ostprotokoly ic pro rozlišení skutečného selhání od dočasného nárůstu zdrojů.

8. Časté dotazy

Otázka: Jaký je minimální počet uzlů potřebných pro SQL Server cluster s podporou převzetí služeb při selhání?

A: Dva uzly jsou minimum. Jeden funguje jako aktivní uzel, na kterém běží SQL Server například; druhý je pohotovostní režim. Most produkční nasazenítars dvouuzlovou aktivní/pasivní konfigurací.

Otázka: Ano SQL Server Vyžaduje FCI sdílené úložiště?

A: Ano. Na rozdíl od skupin dostupnosti Always On vyžaduje FCI, aby všechny uzly přistupovaly ke stejnému úložišti – buď k síti SAN (Fibre Channel nebo iSCSI), Storage Spaces Direct nebo ke sdílené složce SMB. Sdílené úložiště umožňuje přístup ke stejným souborům databáze z libovolného uzlu po přepnutí služeb při selhání.

Q: Co SQL Server Podporují edice failover clustering?

A: SQL Server Edice Standard a Enterprise podporují FCI. Edice Express a Developer nikoli. Edice Enterprise podporuje více uzlů a další funkce s vysokou dostupností, jako jsou online operace s indexy během údržby.

Otázka: Může SQL Server Lze FCI a skupiny dostupnosti Always On používat společně?

A: Ano. Uzel FCI může mítost replika skupiny dostupnosti, která vám poskytne jak vysokou dostupnost (HA) na úrovni instance z FCI, tak i DR na úrovni databáze ze skupiny dostupnosti. Automatické přepnutí skupiny dostupnosti do nebo z FCI-h však může vést k failoveru.ostReplika ed není podporována – v této konfiguraci je k dispozici pouze ruční převzetí služeb při selhání.

Otázka: Jak dlouho trvá SQL Server Jaké je typické trvání failoveru?

A: Doba failoveru závisí na počtu nečistých stránek v mezipaměti vyrovnávací paměti, které musí být zapsány na disk před obnovením instance.tarts na novém uzlu. S povolenými nepřímými kontrolními body (výchozí hodnota z SQL Server (od roku 2012) jsou nečisté stránky ohraničené a most Failovery se dokončí za méně než 30 sekund. Skutečná doba obnovení (RTO) závisí na pracovní zátěži, rychlosti úložiště a době obnovy databáze.

Otázka: Co je kvorum a proč je důležité?

A: Kvorum je mechanismus, který WSFC používá k určení, zda má cluster dostatek zdravých členů, aby zůstal online a obsluhoval požadavky. Zabraňuje scénáři rozděleného mozku, kdy se dvě izolované skupiny uzlů domnívají, že jsou autoritativními vlastníky. SQL Server například. Pokud je kvorum lostWSFC přepne cluster do offline režimu, aby ochránil integritu dat.

Otázka: Může SQL Server Lze FCI nainstalovat na cluster pracovní skupiny (bez služby Active Directory)?

A: Ne. SQL Server FCI vyžaduje, aby všechny uzly byly členy stejné domény služby Active Directory. Clustery pracovních skupin, clustery s více doménami a clustery, které obsahují řadiče domény jen pro čtení, nejsou podporovány.

Otázka: Co se stane s připojením klientů, když dojde k převzetí služeb při selhání?

A: Aktivní připojení k SQL Server Instance jsou během failoveru zahozeny. Poté, co se instance na novém uzlu přepne do režimu online, se tam znovu zaregistruje název virtuální sítě a virtuální IP adresa a klienti, kteří ve svých připojovacích řetězcích používají logiku opakování, se automaticky znovu připojí bez jakékoli změny konfigurace.

Otázka: Mohu přidat nebo odebrat uzly z existujícího SQL Server cluster s podporou převzetí služeb při selhání?

A: Ano. Běh. SQL Server Nastavení na libovolném uzlu a výběr Přidat uzel do SQL Server clusteru s podporou převzetí služeb při selhání přidat uzel, nebo Odebrat uzel z SQL Server clusteru s podporou převzetí služeb při selhání odebrat jeden. Přidání nebo odebrání uzlu nevyžaduje prostoje pro ostatní uzly v clusteru.

Otázka: Jaký je rozdíl mezi plánovaným failoverem a automatickým failoverem?

A: Plánované přepnutí služeb při selhání je ručně iniciováno správcem – obvykle pro údržbu, jako je oprava nebo výměna hardwaru. Umožňuje SQL Server vyprázdnit „dirty“ stránky a čistě ukončit systém před převodem vlastnictví, což má za následek minimální prostoje. WSFC spustí automatické přepnutí při selhání, když monitorování stavu zjistí selhání aktivního uzlu, a doba obnovy závisí na rozsahu potřebném pro zotavení po havárii.

Otázka: Jak mohu obnovit SQL Server cluster s podporou převzetí služeb při selhání, pokud se celý WSFC přepne do režimu offline?

A: Pokud je kvorum lost a cluster nemůže starObvykle se k uvedení přeživších uzlů do stavu bez odolnosti vůči chybám používá vynucené kvorum. Na přeživším uzlu spusťte následující příkaz PowerShellu: Start-ClusterNode -ForcQuorumPo přepnutí clusteru do online režimu obnovte databáze, ověřte integritu dat a poté před návratem do produkčního prostředí znovu nakonfigurujte kvorum se zbývajícími uzly.

Otázka: Mám spustit Průvodce ověřením clusteru před každým SQL Server instalace?

A: Ano, a také po jakékoli významné změně hardwaru nebo konfigurace. Společnost Microsoft podporuje pouze konfigurace failover clusterů, které projdou všemi ověřovacími testy bez chyb. Vynechání ověření riskuje spuštění nepodporované konfigurace, která se může za podmínek selhání chovat nepředvídatelně.

9. závěr

SQL Server Failover clustering poskytuje transparentní vysokou dostupnost na úrovni instance prostřednictvím WSFC s automatickým failoverem a bez nutnosti rekonfigurace klienta. Je to správná volba, když je k dispozici sdílené úložiště a potřebujete, aby se každá databáze v instanci failoverovala společně jako celek. Pro prostředí, která také vyžadují zotavení po havárii nebo sekundární úlohy čtení, spárujte FCI se skupinami dostupnosti Always On, abyste pokryli oba scénáře.

Reference

Oficiální dokument společnosti Microsoft: Cluster Windows Server Failover s SQL Server
Oficiální dokument společnosti Microsoft: Instance clusteru Always On Failover
Oficiální dokument společnosti Microsoft: Instalace instance failover clusteru
Oficiální dokument společnosti Microsoft: Režimy kvora WSFC a konfigurace hlasování

O autorovi

Yuan Sheng je seniorní správce databází (DBA) s více než 10 lety zkušeností v SQL Server prostředí a správu podnikových databází. Úspěšně vyřešil stovky scénářů obnovy databází ve finančních službách, zdravotnictví a výrobních organizacích.

Yuan se specializuje na SQL Server obnova databází, řešení pro vysokou dostupnost a optimalizace výkonu. Jeho rozsáhlé praktické zkušenosti zahrnují správu databází o velikosti více terabajtů, implementaci skupin dostupnosti Always On a vývoj automatizovaných strategií zálohování a obnovy pro kritické podnikové systémy.

Díky svým technickým znalostem a praktickému přístupu se Yuan zaměřuje na vytváření komplexních průvodců, které pomáhají správcům databází a IT profesionálům řešit složité SQL Server efektivně zvládá výzvy. Udržuje si přehled o nejnovějších SQL Server vydání a vyvíjející se databázové technologie společnosti Microsoft a pravidelně testuje scénáře obnovy, aby zajistil, že jeho doporučení odrážejí osvědčené postupy z reálného světa.

Máte otázky ohledně SQL Server potřebujete další pokyny k odstraňování problémů s databází? Yuan vítá zpětnou vazbu a návrhy pro vylepšení těchto technických zdrojů.