SQL Server Always On: Kompletný sprievodca pre DBA [2026]

SQL Server Always On je komplexné riešenie spoločnosti Microsoft pre vysokú dostupnosť a obnovu po havárii, ktoré bolo predstavené spolu s... SQL Server 2012. Predstavuje významný pokrok oproti predchádzajúcim technológiám, ako je zrkadlenie databáz a odosielanie protokolov, pričom zabezpečuje nepretržitý prístup k údajom a zároveň minimalizuje prestoje a stratu údajov.

1.2 Prečo firmy potrebujú neustále dostupné riešenia

V dnešnej digitálnej ekonomike sa prestoje databázy priamo premietajú doost príjmy, poškodená reputácia a problémy s dodržiavaním predpisov. Organizácie potrebujú riešenia s vysokou dostupnosťou, ktoré dokážu zaručiť takmer nepretržitú prevádzkyschopnosť a zároveň chrániť pred rôznymi scenármi zlyhania.

Tradičné postupy zálohovania a obnovy nie sú dostatočné pre moderné obchodné požiadavky. Keď zlyhá kritická databáza, firmy si nemôžu dovoliť hodiny potrebné na obnovu zo záloh. Riešenia Always On poskytujú automatizované prepnutie pri zlyhaní, ktoré dokáže obnoviť službu v priebehu niekoľkých sekúnd alebo minút namiesto hodín, čím dramaticky znižuje dopad zlyhaní systému.

Okrem základnej dostupnosti musia firmy odľahčiť produkčné databázy úlohami intenzívnym čítaním, vykonávať údržbu bez prestojov a chrániť sa pred katastrofami na úrovni lokality. SQL Server Always On rieši všetky tieto požiadavky prostredníctvom jednotnej architektúry, ktorá sa škáluje od malých nasadení až po globálne distribuované systémy.

1.3 Kľúčové pojmy: RTO, RPO, HA a DR

Cieľový čas zotavenia (RTO) definuje maximálne akceptovateľné trvanie prestoja po zlyhaní – ako rýchlo sa musí databáza opäť spustiť.

Cieľ bodu obnovy (RPO) definuje maximálnu prijateľnú stratu údajov meranú v čase – koľko nedávno potvrdených údajov si podnik môže dovoliť stratiť.

Vysoká dostupnosť (HA) sa zameriava na minimalizáciu prestojov spôsobených bežnými poruchami, ako sú poruchy hardvéru alebo softvérové havárie v rámci toho istého dátového centra.

Obnova po havárii (DR) rieši katastrofické udalosti, ktoré postihujú celé lokality, a uchováva kópie údajov na geograficky oddelených miestach. Zatiaľ čo vysoká dostupnosť sa zameriava na minimalizáciu prestojov, krízová obnova sa zameriava na zabezpečenie ochrany údajov a kontinuity podnikania počas závažných incidentov.

SQL Server Funkcia Always On podporuje HA aj DR v rámci jednej unifikovanej architektúry. Režim synchrónneho potvrdenia poskytuje RPO = 0 s automatickým prepnutím na záložný systém pre takmer nulové RTO; režim asynchrónneho potvrdenia akceptuje potenciálnu stratu údajov výmenou za nižší vplyv latencie na vzdialených lokalitách.

1.4 Riešenia vždy k dispozícii

SQL Server Always On ponúka tri možnosti nasadenia, pričom každá z nich je vhodná pre rôzne požiadavky na dostupnosť a infraštruktúru. Táto príručka pokrýva všetky tri:

Skupiny dostupnosti Always On (AG): Vysoká dostupnosť a obnova po havárii na úrovni databázy bez zdieľaného úložiska.
Inštancie klastra Always On Failover (FCI): Vysoká dostupnosť na úrovni inštancie s využitím zdieľaného úložiska.
Kombinácia AG + FCI: Dvojvrstvová ochrana, ktorá kombinuje záložné prepnutie na úrovni inštancie a databázy pre maximálnu odolnosť.

2. Skupiny dostupnosti Always On

Skupiny dostupnosti Always On (AG) je riešenie pre vysokú dostupnosť a obnovu po havárii na úrovni databázy, ktoré replikuje sadu používateľských databáz až do ôsmich sekundárnych replík prostredníctvom nepretržitého odosielania transakčných protokolov.

Kľúčové vlastnosti 2.1

Zlyhanie na úrovni databázy: jednotlivé databázy alebo skupiny sa môžu zlyhať nezávisle od SQL Server inštancia;
až deväť replík (jedna primárna, osem sekundárnych) v Enterprise Edition;
režim synchrónneho potvrdenia pre nulovú stratu údajov; asynchrónne potvrdenie pre vzdialené repliky DR;
automatické prepnutie synchrónnych replik, keď sa primárna replika stane nedostupnou;
čitateľné sekundárne repliky na odľahčenie úloh súvisiacich s reportovaním a zálohovaním;
Listener skupiny dostupnosti poskytuje jeden koncový bod pripojenia, ktorý automaticky smeruje na aktuálny primárny server.

2.2 Kroky implementácie

Pripravte si účty služby Active Directory a nakonfigurujte povolenia na všetkých uzloch;
nainštalovať a overiť klastrovanie záložných systémov systému Windows Server na všetkých zúčastnených serveroch;
inštalovať SQL Server ako samostatná inštancia na každom uzle s použitím konzistentných ciest a nastavení;
povoliť funkciu Skupiny dostupnosti Always On prostredníctvom SQL Server Správca konfigurácie alebo PowerShell;
nastaviť databázy na model úplnej obnovy a vytvárať úplné zálohy a zálohy protokolov;
vytvoriť skupinu dostupnosti, pridať repliky a nakonfigurovať režimy dostupnosti a záložného prepnutia;
vytvárať sekundárne repliky pomocou automatického nasadzovania alebo manuálneho zálohovania a obnovy;
vytvoriť poslucháč skupiny dostupnosti a overiť pripojenie klienta.

Úplný podrobný návod nájdete v našom Kompletný sprievodca skupinami dostupnosti Always On.

2.3 Najlepšie pre

Kritické databázy vyžadujúce nulovú stratu údajov a automatické prepnutie na záložný systém;
pracovné zaťaženia, ktoré potrebujú čitateľné sekundárne dáta na účely reportovania alebo odľahčenia záloh;
nasadenia zahŕňajúce viacero lokalít pre obnovu po havárii;
prostredia bez existujúcej infraštruktúry zdieľaného úložiska.

2.4 Pros

Nie je potrebné žiadne zdieľané úložisko – každá replika používa nezávislé lokálne úložisko;
podporuje HA aj DR v jednej konfigurácii;
čitateľné sekundárne zložky znižujú pracovnú záťaž primárnych zložk;
Granularita na úrovni databázy umožňuje rôzne politiky prepnutia na záložné systémy pre každú skupinu databáz.

2.5 Nevýhody

Pre kompletnú sadu funkcií je potrebná Enterprise Edition (Standard podporuje Basic AG s výraznými obmedzeniami);
režim synchrónneho potvrdenia pridáva latenciu zápisu úmernú času prenosu údajov v sieti;
prihlásenia, úlohy agenta SQL a prepojené servery vyžadujú manuálnu synchronizáciu v SQL Server 2019 a skôr;
Všetky repliky sa musia nachádzať na uzloch toho istého záložného klastra Windows Server.

2.6 Referencie

Oficiálny dokument spoločnosti Microsoft: Čo je skupina dostupnosti Always On?
Oficiálny dokument spoločnosti Microsoft: Získanie Stars výkonnými skupinami dostupnosti Always On

3. Inštancie klastra Always On Failover

Inštancie klastra Always On Failover (FCI) poskytuje vysokú dostupnosť na úrovni inštancie spustením jediného SQL Server inštanciu na viacerých fyzických uzloch, ktoré zdieľajú rovnaké úložisko. Keď aktívny uzol zlyhá, SQL Server inštancia na pohotovostnom uzle sa automaticky resetujetarted, čím sa prechod stane transparentným pre klientske aplikácie.

Kľúčové vlastnosti 3.1

Zlyhanie na úrovni inštancie: všetky databázy na inštancii sa zlyhávajú spoločne ako jeden celok;
zdieľané úložisko (SAN, iSCSI, Storage Spaces Direct alebo SMB) prístupné všetkým uzlom;
názov virtuálnej siete a virtuálna IP adresa poskytujú stabilný koncový bod pripojenia bez ohľadu na to, ktorý uzol je aktívny;
Funkcia Windows Server Failover Clustering spravuje monitorovanie stavu uzlov, kvórum a orchestráciu záložného prepnutia;
podporuje konfigurácie uzlov Aktívny/Pohotovostný, Aktívny/Aktívny, N+1 a N+M.

3.2 Kroky implementácie

Poskytovanie a pripojenie zdieľaného úložiska ku všetkým uzlom klastra;
nainštalujte funkciu Failover Clustering a overte konfiguráciu klastra;
vytvoriť klaster záložných systémov Windows Server a nakonfigurovať kvórum;
spustiť SQL Server inštalácia s výberom možnosti záložného klastra a zadaním názvu virtuálnej siete a ciest zdieľaného úložiska;
pridať ďalšie uzly do SQL Server inštancia záložného klastra;
overte správanie pri zlyhaní testovaním manuálneho zlyhania medzi uzlami.

Úplný podrobný návod nájdete v našom SQL Server Kompletný sprievodca záložným klastrom.

3.3 Najlepšie pre

Prostredia s existujúcou infraštruktúrou zdieľaného úložiska (SAN alebo iSCSI);
aplikácie, ktoré vyžadujú záložné prepnutie na úrovni inštancie, kde sa musia všetky databázy prepnúť naraz;
scenáre, kde je transparentnosť klienta kritická a nie sú prijateľné žiadne zmeny na strane aplikácie;
organizácie, ktoré uprednostňujú jednoduchosť modelu záložného prepnutia s jednou inštanciou.

3.4 Pros

Automatické prepnutie na úroveň inštancie bez nutnosti rekonfigurácie klienta;
žiadne réžia replikácie dát – všetky uzly pristupujú k rovnakému úložisku;
predvídateľné správanie pri zlyhaní pre všetky databázy súčasne;
podporuje flexibilné konfigurácie uzlov (aktívny/aktívny, N+1, N+M) pre optimalizáciu využitia hardvéru.

3.5 Nevýhody

Zdieľané úložisko je potenciálnym jediným bodom zlyhania, pokiaľ samotné úložisko nie je redundantné;
beží iba jeden uzol SQL Server naraz – žiadne vyvažovanie záťaže čítania na sekundárnych uzloch;
žiadna vstavaná obnova po havárii bez spárovania so skupinou dostupnosti;
infraštruktúra zdieľaného úložiska pridáva cost a zložitosť v porovnaní s AG.

3.6 Referencie

Oficiálny dokument spoločnosti Microsoft: Inštancie klastra Always On Failover (SQL Server)

4. Kombinujte skupiny dostupnosti s inštanciami klastrov s podporou záložných zdrojov

Pre organizácie, ktoré vyžadujú ochranu na úrovni inštancie aj databázy, SQL Server podporuje hostvytváranie replík skupín dostupnosti na inštanciách záložných klastrov (FCI). V tejto konfigurácii každý uzol FCI funguje ako jedna replika dostupnosti, takže záložné prepnutie FCI je transparentné pre skupinu dostupnosti, zatiaľ čo záložné prepnutie AG poskytuje ochranu na úrovni databázy naprieč lokalitami. Táto kombinácia poskytuje...ost komplexné pokrytie vysokej dostupnosti a obnovy po havárii dostupné v SQL Server.

Kľúčové vlastnosti 4.1

Dvojvrstvové prepnutie na záložný systém: FCI rieši zlyhania uzlov na úrovni inštancie; AG rieši zlyhania na úrovni lokality alebo repliky;
každá FCI sa počíta ako jedna replika v rámci skupiny dostupnosti bez ohľadu na to, koľko uzlov FCI obsahuje;
FCI-hostrepliky stále vyžadujú zdieľané úložisko podľa štandardných požiadaviek FCI;
repliky AG hostFCI podporujú iba manuálne prepnutie pri zlyhaní – automatické prepnutie pri zlyhaní nie je k dispozícii pre FCI-hostrepliky;
Samostatné inštancie sa môžu zúčastňovať v rovnakej skupine dostupnosti spolu s FCI-hostrepliky.

4.2 Kroky implementácie

Nasadiť a overiť každú FCI nezávisle podľa štandardných postupov nastavenia FCI;
zabezpečiť, aby všetky uzly FCI a samostatné replikačné uzly patrili do rovnakého klastra Windows Server Failover;
povoliť funkciu Skupiny dostupnosti Always On v každej inštancii FCI;
overiť, či by žiadny jednotlivý uzol WSFC nemalost dve repliky tej istej skupiny dostupnosti po akomkoľvek možnom prepnutí FCI pri zlyhaní;
vytvoriť skupinu dostupnosti, označiť inštancie FCI ako repliky a nakonfigurovať manuálny režim záložného prepnutia pre všetky FCI-hostrepliky;
nastaviť sekundárne repliky a nakonfigurovať poslucháč skupiny dostupnosti.

Podrobnosti o nastavení FCI nájdete v našich SQL Server Kompletný sprievodca k klastru pre záložné zariadenia. Podrobnosti o nastavení AG nájdete v našom kompletnom sprievodcovi k skupinám dostupnosti Always On.

4.3 Najlepšie pre

Kritické prostredia vyžadujúce ochranu pred zlyhaniami jednotlivých uzlov aj pred katastrofami na úrovni lokality;
organizácie, ktoré už používajú FCI a potrebujú pridať obnovu po havárii medzi lokalitami;
regulované odvetvia, kde sú povinné SLA s maximálnou ochranou údajov a dostupnosťou;
rozsiahle nasadenia, kde musia koexistovať politiky prepnutia na úrovni inštancie a databázy.

4.4 Pros

Maximálna ochrana: zlyhania uzlov rieši FCI, zlyhania lokality rieši AG;
Záložné prepnutie FCI je transparentné pre skupinu dostupnosti – AG počas záložného prepnutia FCI nevidí žiadnu zmenu repliky;
flexibilná topológia: mix FCI-hosted a samostatné repliky v rovnakej skupine dostupnosti.

4.5 Nevýhody

FCI-hostrepliky ed podporujú iba manuálne prepnutie AG pri zlyhaní – automatické prepnutie AG pri zlyhaní nie je pre tieto repliky k dispozícii;
vyžaduje starostlivé plánovanie uzlov WSFC, aby sa zabránilo zlyhaniu jedného uzlaostvytvorenie dvoch replík tej istej AG po zlyhaní FCI;
vyššia infraštruktúra cost a prevádzkovú zložitosť ako samostatná AG alebo FCI;
Pre každý komponent FCI je stále potrebné zdieľané úložisko.

4.6 Referencie

Oficiálny dokument spoločnosti Microsoft: Klastrovanie pri zlyhaní a skupiny dostupnosti Always On (SQL Server)
Oficiálny dokument spoločnosti Microsoft: Čo je skupina dostupnosti Always On?
Oficiálny dokument spoločnosti Microsoft: Získanie Stars výkonnými skupinami dostupnosti Always On
Oficiálny dokument spoločnosti Microsoft: Inštancie klastra Always On Failover (SQL Server)

5. Porovnanie riešení Always On

5.1 Tabuľka porovnania funkcií

Vlastnosti	Skupiny dostupnosti	Inštancie záložných klastrov	Kombinované AG + FCI
Rozsah záložného prepnutia	Na úrovni databázy	Na úrovni inštancie	Oba
Vyžaduje sa zdieľané úložisko	Nie	Áno	Áno (pre zložku FCI)
Replikácia údajov	Na základe protokolov pre každú repliku	Žiadne (zdieľané úložisko)	Založené na protokoloch medzi FCI
Automatické prepnutie pri zlyhaní	Áno (synchrónne repliky)	Áno	FCI: Áno; AG: Nie
Čitateľné sekundárne	Áno	Nie	Áno (AG komponent)
Zotavenie po havárii	Vstavaný	Nie je vstavaný	Vstavaný
Maximálny počet replík	9 (Podnik)	N / A	9 (Podnik)
Zložitosť infraštruktúry	stredná	stredná	vysoký
Náklady	Nižšia (nie je potrebná SAN)	Vyššia (vyžaduje sa SAN)	Najvyššia

5.2 Vyberte si svoje riešenie Always On

Stars vašou úložnou infraštruktúrou: ak nemáte žiadne existujúce zdieľané úložisko, skupiny dostupnosti sú prirodzenou voľbou a most cost-efektívna cesta k HA aj DR. Ak už prevádzkujete prostredie SAN a potrebujete záložný režim na úrovni inštancie, FCI je jednoduchšou možnosťou – ale ak je DR medzi lokalitami v budúcnosti požiadavkou, počítajte s pridaním AG neskôr.

Kombináciu AG + FCI zvoľte iba vtedy, ak skutočne potrebujete obe vrstvy ochrany a zároveň máte dostatočnú operačnú vyspelosť na zvládnutie zvýšenej komplexnosti. Kľúčovým obmedzením, ktoré treba mať na pamäti, je, že FCI-hostRepliky AG nepodporujú automatické prepnutie skupiny dostupnosti, takže táto topológia vyžaduje manuálny zásah pre prepnutia na úrovni skupiny dostupnosti.

Pre most pre nasadenia na zelenej lúke dnes sú odporúčanou voľbou skupiny dostupnosti Always OntarDôležité: pokrýva HA aj DR, nevyžaduje zdieľané úložisko a podporuje čitateľné sekundárne úložiská – funkcie, ktorým sa FCI samo o sebe nemôže porovnať.

6. Najlepšie postupy pre SQL Server Riešenia vždy k dispozícii

6.1 Plánovanie a dizajn

Pred výberom riešenia Always On definujte požiadavky na RTO a RPO – tieto tarpriamo určí, či je vhodný synchrónny alebo asynchrónny režim potvrdenia a či je možné automatické prepnutie na záložný systém.
Nastavte veľkosť sekundárnych replík tak, aby zvládli plnú primárnu záťaž počas udalosti prepnutia pri zlyhaní vrátane scenárov špičkovej záťaže.
V prípade nasadení AG umiestnite synchrónne repliky v rámci toho istého dátového centra alebo siete s nízkou latenciou, aby ste minimalizovali vplyv latencie zápisu. Pre geograficky vzdialené repliky DR rezervujte asynchrónny režim.
Navrhnite kvórum s nepárnym počtom hlasov. Pre klastre s dvoma uzlami pridajte zdieľanie súborov alebo cloudového svedka ako tretí hlas, aby ste predišli scenárom rozdelenia mozgu.
Pre nasadenie viacerých podsietí starostlivo naplánujte topológiu siete. Každá podsieť vyžaduje vlastnú IP adresu poslucháča a klienti musia mať v reťazcoch pripojenia nastavenú hodnotu MultiSubnetFailover=True.

6.2 Implementačné pokyny

Používajte konzistentne SQL Server úrovne verzií, edícií a kumulatívnych aktualizácií vo všetkých replikách. Zmiešané úrovne opráv môžu spôsobiť neočakávané správanie počas núdzového prepnutia.
Nakonfigurujte vyhradené sieťové rozhrania pre prevádzku klastra s prezenčným signálom, oddelene od prevádzky aplikácií.
Povoliť automatické nasadenie pre počiatočnú synchronizáciu databázy v SQL Server 2016 a novšie – eliminuje potrebu manuálneho kopírovania záloh do sekundárnych replík pre most scenáre.
V prípade topológií AG + FCI overte po každej zmene konfigurácie uzla FCI, či sa žiadny uzol WSFC nedokáže dostať do stavu h.ostvytvorenie dvoch replík tej istej skupiny dostupnosti.
Vždy používajte SQL Server Management Studio alebo Transact-SQL na správu záložných prepnutí skupín dostupnosti – nikdy nepoužívajte Failover Cluster Manager priamo, pretože si nie je vedomý stavu synchronizácie AG a môže spôsobiť dlhší výpadok alebo stratu údajov.

6.3 Monitorovanie a údržba

Pravidelne monitorujte stav synchronizácie, front odoslania a front opakovania pomocou panela skupiny dostupnosti v SQL Server Management Studio alebo Dynamic Management Views (DMV). Rastúci front opakovaní na sekundárnom serveri indikuje úzke miesto I/O, ktoré oneskorí obnovu po zlyhaní.
Spustite príkaz DBCC CHECKDB na sekundárnych replikách, aby ste odľahčili kontroly integrity z primárnej repliky. Pozrite si naše Sprievodca DBCC CHECKDB podrobnosti.
Aplikovať SQL Server záplaty pomocou postupných aktualizácií: najprv sa opravia sekundárne repliky, potom sa vykoná plánované manuálne prepnutie na opravenú sekundárnu zálohu a potom sa opraví predchádzajúca primárna záloha. Tým sa obmedzí prestoj na trvanie jedného prepnutia.
Pravidelne testujte záložné prepnutie v neprodukčnom prostredí. Automatické záložné prepnutie, ktoré nebolo nikdy testované, nie je spoľahlivou stratégiou obnovy.
Konfigurácia upozornení na zmeny stavu skupiny dostupnosti, prechody rolí repliky a zlyhania synchronizácie pomocou SQL Server Agent alebo špecializovaný monitorovací nástroj, ako napríklad SQL Server sledovanie výkonu.

7. Najčastejšie otázky

Otázka: Čo je to? SQL Server Vždy zapnuté?

A: SQL Server Always On je platforma spoločnosti Microsoft pre vysokú dostupnosť a obnovu po havárii, ktorá bola predstavená v roku SQL Server 2012. Zahŕňa dve technológie – skupiny dostupnosti Always On a inštancie klastrov Always On Failover – ktoré poskytujú automatizované prepnutie pri zlyhaní, redundanciu údajov a nepretržitý prístup k databázam v prípade zlyhania hardvéru, softvéru alebo lokality.

Otázka: Aký je rozdiel medzi skupinami dostupnosti Always On a inštanciami klastrov Failover?

A: Skupiny dostupnosti fungujú na úrovni databázy, replikujú údaje do nezávislých sekundárnych replík prostredníctvom odosielania protokolov a nevyžadujú žiadne zdieľané úložisko. Inštancie klastrov s prepínaním medzi službami fungujú na úrovni inštancie, vyžadujú zdieľané úložisko prístupné všetkým uzlom a prepínajú všetky databázy spolu ako jeden celok. AG podporuje čitateľné sekundárne databázy a vstavané DR; FCI nie.

Otázka: Potrebujem zdieľané úložisko pre skupiny dostupnosti Always On?

A: Nie. Každá replika AG si uchováva vlastnú nezávislú kópiu databáz v lokálnom úložisku. Zdieľané úložisko je potrebné iba v prípade, že na h používate inštancie záložného klastra.ost AG repliky.

Otázka: Môžem používať funkciu Vždy zapnuté s SQL Server Štandardná edícia?

A: SQL Server Štandardná edícia podporuje základné skupiny dostupnostitarting s SQL Server 2016, ale s výraznými obmedzeniami: jedna databáza na skupinu AG, maximálne dve repliky a žiadna podpora čitateľných sekundárnych databáz. FCI je k dispozícii v Standard Edition bez týchto obmedzení. Pre plnú funkčnosť Always On je potrebná Enterprise Edition.

Otázka: Aký je maximálny počet replík v skupine dostupnosti?

A: SQL Server Enterprise Edition podporuje až deväť replík: jednu primárnu a osem sekundárnych. Distribuované skupiny dostupnosti môžu tento počet rozšíriť na 18 replík v dvoch samostatných skupinách dostupnosti.

Otázka: Môže FCI-hostPoužívajú repliky ed automatické prepnutie na záložný systém AG?

A: Nie. Keď je replika dostupnosti hostna inštancii klastra pre záložné prepnutie, automatické záložné prepnutie skupiny dostupnosti nie je pre túto repliku podporované. Všetky záložné prepnutia skupiny dostupnosti zahŕňajúce FCI-hostVytvorené repliky vyžadujú manuálny zásah.

Otázka: Aký je rozdiel medzi synchrónnym a asynchrónnym režimom potvrdenia?

A: Režim synchrónneho potvrdenia vyžaduje, aby primárny server počkal, kým sekundárny server sprístupní záznamy protokolov pred potvrdením, čím sa zabezpečí nulová strata údajov (RPO = 0) v čase cost zvýšenou latenciou zápisu. Asynchrónny režim potvrdzovania umožňuje primárnemu serveru potvrdzovať zmeny bez čakania, čím sa znižuje latencia, ale riskuje sa strata údajov, ak primárny server zlyhá skôr, ako sekundárny server dostane všetky záznamy protokolu. Synchrónny režim použite pre lokálne repliky vysokej dostupnosti (HA) a asynchrónny režim pre vzdialené repliky DR.

Otázka: Ako dlho trvá SQL Server Vždy zapnuté záložné prepnutie?

A: Automatické prepnutie synchrónnej repliky AG sa za normálnych podmienok zvyčajne dokončí za menej ako 30 sekúnd. Prepnutie FCI zvyčajne trvá 20 – 60 sekúnd v závislosti od času obnovy databázy. Skutočné trvanie závisí od pracovného zaťaženia, veľkosti databázy a nastavení časového limitu kontroly stavu nakonfigurovaných vo WSFC.

Otázka: Čo sa stane s pripojeniami klientov počas záložného prepnutia?

A: Existujúce pripojenia sa po zlyhaní zrušia. Aplikácie, ktoré používajú listener skupiny dostupnosti a zahŕňajú logiku opakovania pripojenia, sa po dokončení zlyhania automaticky znova pripoja k novému primárnemu modulu. Pridanie MultiSubnetFailover=True do reťazcov pripojenia zvyšuje rýchlosť opätovného pripojenia v nasadeniach s viacerými podsieťami.

Otázka: Ako môžem požiadať SQL Server záplaty s minimálnym prestojom v prostredí Always On?

A: Používajte priebežné aktualizácie: najprv opravte sekundárne repliky, potom vykonajte plánované manuálne prepnutie na opravený sekundárny server a nakoniec opravte predchádzajúci primárny server. Tým sa obmedzí prestoj na trvanie jedného plánovaného prepnutia – zvyčajne menej ako minútu.

Otázka: Môžem kombinovať skupiny dostupnosti Always On s inštanciami klastrov Failover?

A: Áno. Môžete host Repliky AG na inštanciách FCI na dosiahnutie ochrany pred zlyhaním na úrovni inštancie aj databázy. Každá FCI sa počíta ako jedna replika AG. Táto topológia vyžaduje starostlivé plánovanie uzlov WSFC, aby sa zabezpečilo, že žiadny jednotlivý uzol nebude maťostdve repliky tej istej AG po akomkoľvek možnom zlyhaní FCI.

Otázka: Čo mám robiť, ak sa moja databáza poškodí v prostredí Always On?

A: Najprv skontrolujte, či je poškodenie prítomné na všetkých replikách alebo iba na primárnej. Ak existuje zdravá sekundárna replika, okamžite na ňu prepnite. V prípade poškodenia všetkých replikácií vykonajte obnovu z čistej zálohy. Pravidelne spúšťajte príkaz DBCC CHECKDB na sekundárnych replikách, aby ste včas odhalili poškodenie. Ak sú postihnuté aj zálohy, špecializovaný nástroj... SQL Server nástroj na obnovu dát sa môže ako posledná možnosť pokúsiť extrahovať dáta z poškodených súborov MDF.

Otázka: Ako sa skupiny dostupnosti Always On porovnávajú so staršími verziami SQL Server Riešenia vysokej kvality?

A: AG nahrádza staršie technológie, ako napríklad lodná doprava denníka a replikácieOdosielanie protokolov vyžaduje manuálne prepnutie pri zlyhaní a nemá automatický prechod rolí; replikácia je navrhnutá skôr na distribúciu údajov než na vysokú dostupnosť. Agencia zabezpečená (AG) poskytuje automatizované prepnutie pri zlyhaní, nulovú stratu údajov so synchrónnym potvrdením a čitateľné sekundárne súbory – funkcie, ktorým sa tieto technológie nemôžu porovnať.

8. Záver

SQL Server Always On poskytuje flexibilnú platformu podnikovej úrovne pre vysokú dostupnosť a obnovu po havárii. Skupiny dostupnosti Always On sú tou správnou voľbou pre...ost moderné nasadenia: eliminuje potrebu zdieľaného úložiska, podporuje čitateľné sekundárne úložiská a spracováva lokálnu vysokú dostupnosť (HA) aj DR medzi lokalitami v jednej konfigurácii. Inštancie klastrov s prepínaním na záložné zdroje (Failover Cluster) zostávajú solídnou možnosťou, keď sú primárnymi požiadavkami prepínanie na úrovni inštancie a existujúca infraštruktúra zdieľaného úložiska. Kombinácia oboch technológií poskytuje najhlbšiu dostupnú ochranu – na úrovni cost väčších investícií do infraštruktúry a prevádzkovej zložitosti.

Bez ohľadu na to, ktoré riešenie si vyberiete, základy sú rovnaké: najprv definujte požiadavky na RTO a RPO a navrhnite topológiu okolo nich. tarpravidelne testovať a prepínať pri zlyhaní. Dobre implementované riešenie Always On, ktoré bolo dôkladne otestované, sa predvídateľne obnoví, keď dôjde k zlyhaniu produkcie.

O autorovi

Yuan Sheng je seniorný správca databáz (DBA) s viac ako 10-ročnými skúsenosťami v SQL Server prostredia a správa podnikových databáz. Úspešne vyriešil stovky scenárov obnovy databáz vo finančných službách, zdravotníctve a výrobných organizáciách.

Yuan sa špecializuje na SQL Server obnova databáz, riešenia vysokej dostupnosti a optimalizácia výkonu. Jeho rozsiahle praktické skúsenosti zahŕňajú správu databáz s veľkosťou viac terabajtov, implementáciu skupín dostupnosti Always On a vývoj automatizovaných stratégií zálohovania a obnovy pre kritické obchodné systémy.

Vďaka svojim technickým znalostiam a praktickému prístupu sa Yuan zameriava na vytváranie komplexných príručiek, ktoré pomáhajú správcom databáz a IT profesionálom riešiť zložité SQL Server efektívne zvláda výzvy. Udržiava si prehľad o najnovších SQL Server vydania a vyvíjajúce sa databázové technológie spoločnosti Microsoft, pričom pravidelne testuje scenáre obnovy, aby sa zabezpečilo, že jeho odporúčania odrážajú osvedčené postupy z reálneho sveta.

Máte otázky o SQL Server obnovenie alebo potrebujete ďalšie pokyny na riešenie problémov s databázou? Yuan víta spätnú väzbu a návrhy na zlepšenie týchto technických zdrojov.