SQL Server Always On: Kompletní průvodce pro správce databází [2026]

SQL Server Always On je komplexní řešení pro vysokou dostupnost a obnovu po havárii od společnosti Microsoft, které bylo představeno s... SQL Server 2012. Představuje významný pokrok oproti předchozím technologiím, jako je zrcadlení databází a odesílání protokolů, a zajišťuje nepřetržitý přístup k datům a zároveň minimalizuje prostoje a ztrátu dat.

1.2 Proč firmy potřebují vždy dostupná řešení

V dnešní digitální ekonomice se výpadky databáze přímo promítají do ztráty příjmů, poškození reputace a problémů s dodržováním předpisů. Organizace vyžadují vysoce dostupná řešení, která mohou zaručit téměř nepřetržitou provozuschopnost a zároveň chránit před různými scénáři selhání.

Tradiční postupy zálohování a obnovy jsou pro moderní obchodní požadavky nedostatečné. Když selže kritická databáze, firmy si nemohou dovolit hodiny potřebné k obnově ze záloh. Řešení Always On poskytují automatizované přepnutí při selhání, které dokáže obnovit službu během několika sekund nebo minut namísto hodin, čímž dramaticky snižuje dopad selhání systému.

Kromě základní dostupnosti potřebují firmy odlehčit produkčním databázím úlohy náročné na čtení, provádět údržbu bez prostojů a chránit se před katastrofami na úrovni jednotlivých lokalit. SQL Server Always On řeší všechny tyto požadavky prostřednictvím jednotné architektury, která se škáluje od malých nasazení až po globálně distribuované systémy.

1.3 Klíčové pojmy: RTO, RPO, HA a DR

Cíl doby zotavení (RTO) definuje maximální přijatelnou dobu výpadku po selhání – jak rychle se musí databáze vrátit do provozu.

Cíl bodu zotavení (RPO) definuje maximální přijatelnou ztrátu dat měřenou v čase – kolik nedávno potvrzených dat si firma může dovolit ztratit.

Vysoká dostupnost (HA) zaměřuje se na minimalizaci prostojů způsobených rutinními poruchami, jako jsou poruchy hardwaru nebo softwarové havárie v rámci stejného datového centra.

Zotavení po havárii (DR) řeší katastrofické události, které postihují celé lokality, a udržuje kopie dat na geograficky oddělených místech. Zatímco vysoká dostupnost se zaměřuje na minimalizaci prostojů, DR se zaměřuje na zajištění ochrany dat a kontinuity provozu během závažných incidentů.

SQL Server Funkce Always On podporuje HA i DR v rámci jedné sjednocené architektury. Režim synchronního potvrzování dat nabízí RPO = 0 s automatickým přepnutím při selhání pro téměř nulové RTO; režim asynchronního potvrzování dat akceptuje potenciální ztrátu dat výměnou za nižší dopad latence napříč vzdálenými lokalitami.

1.4 Řešení vždy k dispozici

SQL Server Always On nabízí tři možnosti nasazení, z nichž každá je vhodná pro různé požadavky na dostupnost a infrastrukturu. Tato příručka pokrývá všechny tři:

Skupiny dostupnosti Always On (AG): Vysoká dostupnost a obnova po havárii na úrovni databáze bez sdíleného úložiště.
Instance clusteru Always On Failover (FCI): Vysoká dostupnost na úrovni instance s využitím sdíleného úložiště.
Kombinace AG + FCI: Dvouvrstvá ochrana, která kombinuje failover na úrovni instance a databáze pro maximální odolnost.

2. Skupiny dostupnosti Always On

Skupiny dostupnosti Always On (AG) je řešení pro vysokou dostupnost a zotavení po havárii na úrovni databáze, které replikuje sadu uživatelských databází až do osmi sekundárních replik prostřednictvím průběžného odesílání transakčních protokolů.

2.1 Klíčové vlastnosti

Převzetí služeb na úrovni databáze: jednotlivé databáze nebo skupiny se mohou převzít na failover nezávisle na SQL Server instance;
až devět replik (jedna primární, osm sekundárních) v Enterprise Edition;
synchronní režim potvrzování pro nulovou ztrátu dat; asynchronní potvrzování pro vzdálené repliky DR;
automatické přepnutí synchronních replik při selhání, když se primární server stane nedostupným;
čitelné sekundární repliky pro odlehčení úloh reportingu a zálohování;
Posluchač skupiny dostupnosti poskytuje jeden koncový bod připojení, který automaticky směruje na aktuální primární server.

2.2 Kroky implementace

Příprava účtů služby Active Directory a konfigurace oprávnění na všech uzlech;
nainstalujte a ověřte clustering Windows Server Failover na všech zúčastněných serverech;
instalovat SQL Server jako samostatná instance na každém uzlu s použitím konzistentních cest a nastavení;
povolte funkci Skupiny dostupnosti Always On prostřednictvím SQL Server Správce konfigurace nebo PowerShell;
nastavit databáze na model plné obnovy a provádět úplné zálohy a zálohy protokolů;
vytvořit skupinu dostupnosti, přidat repliky a nakonfigurovat režimy dostupnosti a failoveru;
vytvářet sekundární repliky pomocí automatického vyplňování nebo ručního zálohování a obnovování;
Vytvořte posluchač skupiny dostupnosti a ověřte připojení klienta.

Úplný podrobný návod najdete v našem Kompletní průvodce skupinami dostupnosti Always On.

2.3 Nejlepší pro

Kritické databáze vyžadující nulovou ztrátu dat a automatické přepnutí na záložní systém;
úlohy, které vyžadují čitelné sekundární servery pro vytváření sestav nebo odlehčení záloh;
nasazení zahrnující více lokalit pro zotavení po havárii;
prostředí bez existující sdílené úložné infrastruktury.

2.4 prof

Není vyžadováno žádné sdílené úložiště – každá replika používá nezávislé lokální úložiště;
podporuje HA i DR v jedné konfiguraci;
čitelné sekundární frameworky snižují pracovní zátěž primárních frameworků;
Granularita na úrovni databáze umožňuje různé zásady pro převzetí služeb při selhání pro každou skupinu databází.

2.5 Nevýhody

Vyžaduje Enterprise Edition pro plnou sadu funkcí (Standard podporuje Basic AG s významnými omezeními);
režim synchronního potvrzení přidává latenci zápisu úměrnou době přenosu dat v síti;
přihlášení, úlohy agenta SQL a propojené servery vyžadují ruční synchronizaci v SQL Server 2019 a dříve;
Všechny repliky se musí nacházet na uzlech stejného clusteru Windows Server Failover.

2.6 Reference

Oficiální dokument společnosti Microsoft: Co je to skupina dostupnosti Always On?
Oficiální dokument společnosti Microsoft: Začínáme se skupinami dostupnosti Always On

3. Instance clusteru Always On Failover

Instance clusteru Always On Failover (FCI) zajišťuje vysokou dostupnost na úrovni instance spuštěním jediného SQL Server instance napříč více fyzickými uzly, které sdílejí stejné úložiště. Když aktivní uzel selže, SQL Server Instance na pohotovostním uzlu se automaticky restartuje, čímž se přechod stane transparentním pro klientské aplikace.

3.1 Klíčové vlastnosti

Failover na úrovni instance: všechny databáze v instanci se failoverují společně jako jeden celek;
sdílené úložiště (SAN, iSCSI, Storage Spaces Direct nebo SMB) přístupné všem uzlům;
Název virtuální sítě a virtuální IP adresa poskytují stabilní koncový bod připojení bez ohledu na to, který uzel je aktivní;
Clustering Windows Server Failover Clustering spravuje monitorování stavu uzlů, kvorum a orchestraci převzetí služeb při selhání;
podporuje konfigurace uzlů typu Aktivní/Pohotovostní, Aktivní/Aktivní, N+1 a N+M.

3.2 Kroky implementace

Zřizování a připojení sdíleného úložiště ke všem uzlům clusteru;
nainstalujte funkci Failover Clustering a ověřte konfiguraci clusteru;
vytvořit cluster Windows Server Failover a nakonfigurovat kvorum;
spusťte SQL Server instalace s výběrem možnosti failover clusteru a zadáním názvu virtuální sítě a cest ke sdílenému úložišti;
přidat další uzly do SQL Server instance failover clusteru;
Ověřte chování při failoveru testováním ručního failoveru mezi uzly.

Úplný podrobný návod najdete v našem SQL Server Kompletní průvodce failover clusterem.

3.3 Nejlepší pro

Prostředí se stávající sdílenou úložnou infrastrukturou (SAN nebo iSCSI);
aplikace, které vyžadují failover na úrovni instance, kde všechny databáze musí být failoverovány společně;
scénáře, kde je transparentnost klienta kritická a nejsou přijatelné žádné změny na straně aplikace;
organizace upřednostňující jednoduchost modelu failoveru s jednou instancí.

3.4 prof

Automatické přepnutí na selhání na úrovni instance bez nutnosti rekonfigurace klienta;
žádná režie replikace dat – všechny uzly přistupují ke stejnému úložišti;
předvídatelné chování při selhání pro všechny databáze současně;
podporuje flexibilní konfigurace uzlů (Aktivní/Aktivní, N+1, N+M) pro optimalizaci využití hardwaru.

3.5 Nevýhody

Sdílené úložiště je potenciálním jediným bodem selhání, pokud samotné úložiště není redundantní;
běží pouze jeden uzel SQL Server najednou – žádné vyvažování zátěže čtení na sekundárních uzlech;
žádná vestavěná obnova po havárii bez spárování se skupinou dostupnosti;
Sdílená úložná infrastruktura zvyšuje náklady a složitost ve srovnání s AG.

3.6 Reference

Oficiální dokument společnosti Microsoft: Instance clusteru Always On Failover (SQL Server)

4. Kombinace skupin dostupnosti s instancemi failover clusteru

Pro organizace, které vyžadují ochranu na úrovni instancí i databází, SQL Server podporuje hostování replik skupin dostupnosti na instancích clusteru Failover (FCI). V této konfiguraci každý uzel FCI funguje jako jedna replika dostupnosti, takže převzetí služeb FCI je transparentní pro skupinu dostupnosti, zatímco převzetí služeb AG poskytuje ochranu na úrovni databáze napříč lokalitami. Tato kombinace poskytuje nejkomplexnější pokrytí vysoké dostupnosti a zotavení po havárii, které je k dispozici v SQL Server.

4.1 Klíčové vlastnosti

Dvouvrstvé failover: FCI zpracovává selhání uzlů na úrovni instance; AG zpracovává selhání na úrovni lokality nebo repliky;
Každá FCI se počítá jako jedna replika v rámci skupiny dostupnosti bez ohledu na to, kolik uzlů FCI obsahuje;
Repliky hostované u FCI stále vyžadují sdílené úložiště dle standardních požadavků FCI;
Repliky AG hostované na FCI podporují pouze ruční přepnutí služeb při selhání – automatické přepnutí služeb při selhání není pro repliky hostované na FCI k dispozici.
Samostatné instance se mohou účastnit stejné skupiny dostupnosti spolu s replikami hostovanými v FCI.

4.2 Kroky implementace

Nasaďte a ověřte každou FCI nezávisle podle standardních postupů nastavení FCI;
zajistit, aby všechny uzly FCI a samostatné replikační uzly patřily do stejného clusteru Windows Server Failover;
Povolte funkci Skupiny dostupnosti Always On v každé instanci FCI;
Ověřte, zda žádný uzel WSFC nebude hostovat dvě repliky stejné skupiny dostupnosti po jakémkoli možném přepnutí FCI při selhání;
vytvořit skupinu dostupnosti, označit instance FCI jako repliky a nakonfigurovat ruční režim převzetí služeb při selhání pro všechny repliky hostované na FCI;
nakonfigurovat sekundární repliky a naslouchat skupinám dostupnosti.

Podrobnosti o nastavení FCI naleznete v našich SQL Server Kompletní průvodce pro Failover Cluster. Podrobnosti o nastavení AG naleznete v našem kompletním průvodci pro skupiny dostupnosti Always On.

4.3 Nejlepší pro

Kritická prostředí vyžadující ochranu jak před selháním jednotlivých uzlů, tak před katastrofami na úrovni lokality;
organizace, které již používají FCI a potřebují přidat obnovu po havárii napříč pracovišti;
regulovaná odvětví, kde jsou povinné SLA s maximální ochranou dat a dostupností;
rozsáhlá nasazení, kde musí koexistovat zásady pro převzetí služeb při selhání na úrovni instance a databáze.

4.4 prof

Maximální ochrana: selhání uzlů řeší FCI, selhání lokality řeší AG;
Přepnutí FCI při selhání je pro skupinu dostupnosti transparentní – AG během přepnutí FCI nevidí žádnou změnu repliky;
flexibilní topologie: kombinujte repliky hostované na FCI a samostatné repliky ve stejné skupině dostupnosti.

4.5 Nevýhody

Repliky hostované na FCI podporují pouze ruční přepnutí služeb AG – automatické přepnutí služeb AG není pro tyto repliky k dispozici;
vyžaduje pečlivé plánování uzlů WSFC, aby se zabránilo tomu, aby jeden uzel hostoval dvě repliky stejné AG po failoveru FCI;
vyšší náklady na infrastrukturu a provozní složitost než u samostatných AG nebo FCI;
Pro každou komponentu FCI je stále vyžadováno sdílené úložiště.

4.6 Reference

Oficiální dokument společnosti Microsoft: Failover Clustering a skupiny dostupnosti Always On (SQL Server)
Oficiální dokument společnosti Microsoft: Co je to skupina dostupnosti Always On?
Oficiální dokument společnosti Microsoft: Začínáme se skupinami dostupnosti Always On
Oficiální dokument společnosti Microsoft: Instance clusteru Always On Failover (SQL Server)

5. Porovnání řešení Always On

5.1 Tabulka porovnání funkcí

vlastnost	Skupiny dostupnosti	Instance failover clusteru	Kombinace AG + FCI
Rozsah přepnutí při selhání	Na úrovni databáze	Na úrovni instance	Oba
Vyžaduje se sdílené úložiště	Ne	Ano	Ano (pro složku FCI)
Replikace dat	Na základě protokolů pro každou repliku	Žádné (sdílené úložiště)	Založené na protokolech mezi FCI
Automatické převzetí služeb při selhání	Ano (synchronní repliky)	Ano	FCI: Ano; AG: Ne
Čitelné sekundární prvky	Ano	Ne	Ano (složka AG)
Zotavení po havárii	Vestavěný	Není vestavěný	Vestavěný
Maximální počet replik	9 (Podnik)	N / A	9 (Podnik)
Složitost infrastruktury	Střední	Střední	Vysoký
Stát	Nižší (není potřeba SAN)	Vyšší (vyžaduje se SAN)	Nejvyšší

5.2 Vyberte si své řešení Always On

Začněte s úložnou infrastrukturou: pokud nemáte žádné stávající sdílené úložiště, jsou skupiny dostupnosti přirozenou volbou a nákladově nejefektivnější cestou k HA i DR. Pokud již provozujete prostředí SAN a potřebujete failover na úrovni instancí, je FCI jednodušší možností – ale pokud je DR napříč pracovišti v budoucnu vyžadován, plánujte pozdější přidání skupiny dostupnosti.

Kombinaci AG + FCI zvolte pouze tehdy, pokud skutečně potřebujete obě vrstvy ochrany a zároveň máte dostatečnou provozní vyspělost pro zvládnutí zvýšené složitosti. Klíčovým omezením, které je třeba mít na paměti, je, že repliky AG hostované na FCI nepodporují automatické převzetí služeb při selhání AG, takže tato topologie vyžaduje ruční zásah pro převzetí služeb při selhání na úrovni skupiny dostupnosti.

Pro většinu dnešních nasazení na zelené louce jsou doporučeným výchozím bodem skupiny dostupnosti Always On: zahrnují HA i DR, nevyžadují žádné sdílené úložiště a podporují čitelné sekundární úložiště – funkce, kterým se FCI sama o sobě nemůže rovnat.

6. Nejlepší postupy pro SQL Server Vždy k dispozici řešení

6.1 Plánování a návrh

Před výběrem řešení Always On definujte požadavky na RTO a RPO – tyto cíle přímo určují, zda je vhodný synchronní nebo asynchronní režim potvrzení a zda je proveditelné automatické přepnutí při selhání.
Upravte velikost sekundárních replik tak, aby zvládly plnou primární zátěž během události převzetí služeb při selhání, včetně scénářů špičkového zatížení.
V případě nasazení AG umístěte synchronní repliky do stejného datového centra nebo sítě s nízkou latencí, abyste minimalizovali dopad latence zápisu. Asynchronní režim rezervujte pro geograficky vzdálené repliky DR.
Navrhněte kvórum s lichým počtem hlasů. U clusterů se dvěma uzly přidejte sdílenou složku nebo cloudového svědka jako třetí hlas, abyste předešli scénářům s rozděleným mozkem.
Pro nasazení s více podsítěmi pečlivě naplánujte topologii sítě. Každá podsíť vyžaduje vlastní IP adresu listeneru a klienti potřebují ve svých připojovacích řetězcích nastavit hodnotu MultiSubnetFailover=True.

6.2 Implementační pokyny

Používejte konzistentně SQL Server verze, edice a kumulativní úrovně aktualizací napříč všemi replikami. Smíšené úrovně oprav mohou způsobit neočekávané chování během převzetí služeb při selhání.
Nakonfigurujte vyhrazená síťová rozhraní pro provoz prezenčního signálu clusteru odděleně od provozu aplikací.
Povolit automatické osazení pro počáteční synchronizaci databáze v SQL Server 2016 a novější – ve většině scénářů eliminuje nutnost ručního kopírování záloh do sekundárních replik.
U topologií AG + FCI ověřte po každé změně konfigurace uzlu FCI, že žádný uzel WSFC nemůže hostovat dvě repliky stejné skupiny dostupnosti.
Vždy používejte SQL Server Management Studio nebo Transact-SQL pro správu převzetí služeb při selhání skupin dostupnosti – nikdy nepoužívejte Správce clusteru s převzetím služeb při selhání přímo, protože si není vědom stavu synchronizace AG a může způsobit delší výpadky nebo ztrátu dat.

6.3 Monitorování a údržba

Pravidelně sledujte stav synchronizace, frontu odesílání a frontu opakování pomocí řídicího panelu skupiny dostupnosti v SQL Server Management Studio nebo Dynamic Management Views (DMV). Rostoucí fronta opakování na sekundárním serveru indikuje úzké hrdlo I/O, které zpozdí zotavení po selhání.
Spuštěním příkazu DBCC CHECKDB na sekundárních replikách odlehčíte kontrolu integrity od primární repliky. Viz naše Průvodce DBCC CHECKDB Podrobnosti.
Přihláška SQL Server Záplaty využívající průběžné aktualizace: nejprve záplatujte sekundární repliky, proveďte plánované ruční přepnutí služeb při selhání na záplatovanou sekundární repliku a poté záplatujte předchozí primární repliku. Tím se omezí doba výpadku na dobu trvání jednoho přepnutí služeb při selhání.
Pravidelně testujte failover v neprodukčním prostředí. Automatický failover, který nebyl nikdy testován, není spolehlivou strategií obnovy.
Konfigurace upozornění na změny stavu skupin dostupnosti, přechody rolí replik a selhání synchronizace pomocí SQL Server Agent nebo specializovaný monitorovací nástroj, jako například SQL Server Performance Monitor.

7. Nejčastější dotazy

Co je SQL Server Vždy zapnuto?

A: SQL Server Always On je platforma společnosti Microsoft pro vysokou dostupnost a zotavení po havárii, která byla představena v roce SQL Server 2012. Zahrnuje dvě technologie – skupiny dostupnosti Always On a instance clusteru Always On Failover – které poskytují automatizované přepnutí služeb při selhání, redundanci dat a nepřetržitý přístup k databázím v případě selhání hardwaru, softwaru nebo lokality.

Otázka: Jaký je rozdíl mezi skupinami dostupnosti Always On a instancemi clusteru s podporou převzetí služeb při selhání?

A: Skupiny dostupnosti fungují na úrovni databáze, replikují data do nezávislých sekundárních replik prostřednictvím odesílání protokolů a nevyžadují žádné sdílené úložiště. Instance clusteru s podporou převzetí služeb při selhání fungují na úrovni instance, vyžadují sdílené úložiště přístupné všem uzlům a přebírají služby při selhání pro všechny databáze společně jako jeden celek. AG podporuje čitelné sekundární databáze a vestavěné DR; FCI nikoli.

Otázka: Potřebuji sdílené úložiště pro skupiny dostupnosti Always On?

A: Ne. Každá replika AG si uchovává vlastní nezávislou kopii databází na lokálním úložišti. Sdílené úložiště je vyžadováno pouze v případě, že k hostování replik AG používáte instance clusteru s podporou převzetí služeb při selhání.

Otázka: Mohu používat funkci Vždy zapnuto s SQL Server Standardní edice?

A: SQL Server Standardní edice podporuje základní skupiny dostupnosti počínaje SQL Server 2016, ale s významnými omezeními: jedna databáze na skupinu AG, maximálně dvě repliky a žádná podpora čitelných sekundárních databází. FCI je k dispozici ve Standard Edition bez těchto omezení. Pro plnou funkčnost Always On je vyžadována Enterprise Edition.

Otázka: Jaký je maximální počet replik ve skupině dostupnosti?

A: SQL Server Enterprise Edition podporuje až devět replik: jednu primární a osm sekundárních. Distribuované skupiny dostupnosti mohou tento počet rozšířit na 18 replik napříč dvěma samostatnými skupinami dostupnosti.

Otázka: Mohou repliky hostované v FCI používat automatické přepnutí služeb při selhání?

A: Ne. Pokud je replika dostupnosti hostována na instanci clusteru s podporou převzetí služeb při selhání, není pro tuto repliku podporováno automatické převzetí služeb skupiny dostupnosti. Všechny převzetí služeb skupiny dostupnosti zahrnující repliky hostované na FCI vyžadují ruční zásah.

Otázka: Jaký je rozdíl mezi synchronním a asynchronním režimem potvrzení?

A: Režim synchronního potvrzování vyžaduje, aby primární server počkal, až sekundární server zabezpečí záznamy protokolu před potvrzením, čímž se zajistí nulová ztráta dat (RPO = 0) za cenu zvýšené latence zápisu. Asynchronní režim potvrzování umožňuje primárnímu serveru potvrzovat data bez čekání, čímž se snižuje latence, ale riskuje ztrátu dat, pokud primární server selže dříve, než sekundární server obdrží všechny záznamy protokolu. Synchronní režim použijte pro lokální repliky HA a asynchronní pro vzdálené repliky DR.

Otázka: Jak dlouho trvá SQL Server Vždy zapnuté převzetí služeb při selhání?

A: Automatické převzetí služeb při selhání pro synchronní repliku AG se za normálních podmínek obvykle dokončí za méně než 30 sekund. Převzetí služeb FCI obvykle trvá 20–60 sekund v závislosti na době obnovy databáze. Skutečná doba trvání závisí na pracovní zátěži, velikosti databáze a nastavení časového limitu kontroly stavu nakonfigurovaného ve WSFC.

Otázka: Co se stane s připojením klientů během failoveru?

A: Stávající připojení jsou při failoveru zahozena. Aplikace, které používají listener skupiny dostupnosti a zahrnují logiku opakování připojení, se po dokončení failoveru automaticky znovu připojí k nové primární síti. Přidání MultiSubnetFailover=True do připojovacích řetězců zvyšuje rychlost opětovného připojení v nasazeních s více podsítěmi.

Otázka: Jak se mohu přihlásit SQL Server záplaty s minimálními prostoji v prostředí Always On?

A: Používejte průběžné aktualizace: nejprve opravte sekundární repliky, poté proveďte plánované ruční přepnutí služeb při selhání na opravenou sekundární repliku a nakonec opravte předchozí primární repliku. Tím se omezí doba výpadku na dobu trvání jednoho plánovaného přepnutí služeb při selhání – obvykle pod minutu.

Otázka: Mohu kombinovat skupiny dostupnosti Always On s instancemi clusteru s podporou převzetí služeb při selhání?

A: Ano. Repliky AG můžete hostovat na instancích FCI, abyste dosáhli ochrany před selháním na úrovni instance i databáze. Každá FCI se počítá jako jedna replika AG. Tato topologie vyžaduje pečlivé plánování uzlů WSFC, aby se zajistilo, že žádný uzel nebude hostovat dvě repliky stejné AG po jakémkoli možném selhání FCI.

Otázka: Co mám dělat, když se moje databáze v prostředí Always On poškodí?

A: Nejprve zkontrolujte, zda je poškození existováno na všech replikách, nebo pouze na primární. Pokud existuje v pořádku sekundární replika, okamžitě na ni přepněte zálohu. V případě poškození všech replik proveďte obnovu z čisté zálohy. Pravidelně spusťte příkaz DBCC CHECKDB na sekundárních replikách, abyste včas odhalili poškození. Pokud jsou ovlivněny i zálohy, je nutné provést specializovaný postup. SQL Server nástroj pro obnovu dat se může jako poslední možnost pokusit extrahovat data z poškozených souborů MDF.

Otázka: Jak si skupiny dostupnosti Always On stojí v porovnání se staršími verzemi? SQL Server Řešení HA?

A: AG nahrazuje starší technologie, jako například přeprava klád a replikaceOdesílání protokolů vyžaduje manuální failover a nemá automatický přechod rolí; replikace je navržena pro distribuci dat, nikoli pro vysokou dostupnost. Agencivně zabezpečená databáze (AG) poskytuje automatizovaný failover, nulovou ztrátu dat se synchronním potvrzením a čitelné sekundární databáze – funkce, kterým se tyto technologie nemohou rovnat.

8. závěr

SQL Server Always On poskytuje flexibilní platformu podnikové úrovně pro vysokou dostupnost a zotavení po havárii. Skupiny dostupnosti Always On jsou tou správnou volbou pro většinu moderních nasazení: eliminují potřebu sdíleného úložiště, podporují čitelné sekundární úložiště a zpracovávají lokální vysokou dostupnost i zotavení po havárii napříč pracovišti v jedné konfiguraci. Instance clusteru s podporou převzetí služeb při selhání zůstávají solidní volbou, pokud jsou primárním požadavkem převzetí služeb na úrovni instance a stávající infrastruktura sdíleného úložiště. Kombinace obou technologií poskytuje nejhlubší dostupnou ochranu – za cenu vyšších investic do infrastruktury a provozní složitosti.

Ať už si zvolíte jakékoli řešení, základy jsou stejné: nejprve definujte požadavky na RTO a RPO, navrhněte topologii s ohledem na tyto cíle a pravidelně testujte failover. Dobře implementované a důkladně otestované řešení Always On se předvídatelně obnoví, když dojde k selhání produkce.

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ů.