SQL Server Skupiny dostupnosti Always On: Kompletní průvodce [2026]

1. Principy skupin dostupnosti Always On

1.1 Co to je a jak to funguje

Skupiny dostupnosti Always On (AG) jsou SQL Server Enterprise vysoká dostupnost a řešení pro zotavení po havárii, které funguje na úrovni databáze. Skupina dostupnosti seskupuje jednu nebo více uživatelských databází do jedné záložní jednotky a replikuje je až do osmi sekundárních replik prostřednictvím průběžného odesílání transakčních protokolů. Když primární replika selže, automaticky převezme řízení určená synchronní sekundární replika, která obnoví přístup během několika sekund bez sdíleného úložiště nebo ručního zásahu.

1.2 Skupiny dostupnosti Always On vs. instance failover clusteru

SQL Server Technologie Always On zahrnuje dvě odlišné technologie: skupiny dostupnosti (AG) a instance clusteru s podporou převzetí služeb při selhání (FCI):

	Vždy dostupné skupiny dostupnosti	Instance clusteru Always On Failover
Rozsah přepnutí při selhání	Na úrovni databáze	Úroveň instance (všechny databáze selhání převezmou současně)
Replikace dat	Replikace založená na protokolech do každého sekundárního serveru	Žádné – všechny uzly sdílejí stejné úložiště
Sdílené úložiště	Nevyžaduje se	Povinné (Storage Area Network (SAN), iSCSI, S2D nebo SMB)
Čitelné sekundární prvky	Ano	Ne
Zotavení po havárii	Vestavěné (asynchronní repliky napříč weby)	Není integrováno bez spárování s AG

Kdy použít každý z nich: Použijte FCI, pokud potřebujete failover na úrovni instance a již máte sdílenou úložnou infrastrukturu. Použijte AG, pokud potřebujete granularitu na úrovni databáze, čitelné sekundární úložiště nebo zotavení po havárii. Pro co nejúplnější ochranu zkombinujte obojí: spusťte každou repliku jako uzel FCI a propojte je v AG.

1.3 Výhody a omezení

Výhody:

• Automatické přepnutí při selhání s téměř nulovou dobou obnovy (RTO) pro synchronní repliky;
• nulová ztráta dat (cíl bodu obnovení (RPO) = 0) v režimu synchronního potvrzení;
• není vyžadováno žádné sdílené úložiště – každá replika používá nezávislé lokální úložiště;
• čitelné sekundární servery odlehčují primárnímu serveru pracovní zátěž v oblasti reportingu a zálohování;
• podporuje jak lokální vysokou dostupnost (HA), tak i cross-site Disaster Recovery (DR) v rámci jedné konfigurace.

Omezení:

• Vyžaduje clustering Windows Server Failover na všech replikách;
• Enterprise Edition pro plnou sadu funkcí (Standard Edition podporuje Basic AG s významnými omezeními);
• Režim synchronního potvrzení přidává latenci k operacím zápisu úměrnou době přenosu dat v síti;
• přihlášení, úlohy agenta SQL a propojené servery se v SQL Server 2019 a dříve (vyřešeno v SQL Server 2022 obsahoval skupiny dostupnosti).

2. Architektura skupin dostupnosti Always On

2.1 Základní komponenty a koncepty

2.1.1 Databáze dostupnosti

Databáze dostupnosti jsou uživatelské databáze, které se účastní skupiny dostupnosti. Tyto databáze musí splňovat specifické požadavky: musí používat model úplné obnovy, mít úplnou zálohu a před přidáním do skupiny dostupnosti musí existovat v primární replice.

Když se databáze připojí ke skupině dostupnosti, stane se součástí synchronizované sady, která se jako jednotka přepne do selhání. Všechny databáze ve skupině dostupnosti sdílejí stejný stav přepnutí do selhání, což znamená, že pokud selže primární replika, všechny databáze se současně přepnou do stejné sekundární repliky. To zajišťuje konzistenci pro aplikace, které se spoléhají na více souvisejících databází.

2.1.2 Repliky dostupnosti

Repliky dostupnosti jsou SQL Server instance, které hostují kopie databází dostupnosti. Každá replika si uchovává vlastní fyzickou kopii databází, synchronizovanou prostřednictvím odesílání záznamů transakčního protokolu. Skupina dostupnosti může obsahovat až devět replik: jednu primární repliku a až osm sekundárních replik.

2.1.3 Primární replika

Primární replika hostuje kopii databází dostupnosti pro čtení i zápis. Všechny úpravy dat (INSERT, UPDATE, DELETE) probíhají v primární replice. Klientské aplikace se připojují k primární replice pro všechny operace zápisu a ve výchozím nastavení i pro operace čtení.

2.1.4 Sekundární repliky

Sekundární repliky hostují kopie databází dostupnosti určené pouze pro čtení, které jsou udržovány prostřednictvím průběžného používání záznamů transakčního protokolu přijatých z primární repliky. Každá sekundární replika přijímá, posiluje a používá záznamy protokolu, aby udržovala své kopie databáze synchronizované s primární replikou.

2.2 Režimy dostupnosti

2.2.1 Režim synchronního potvrzení

Režim synchronního potvrzování transakcí poskytuje ochranu proti ztrátě dat tím, že vyžaduje, aby primární replika před potvrzením transakcí čekala na potvrzení, že záznamy transakčního protokolu byly na sekundární replice posíleny. Tento režim je nezbytný pro konfigurace s vysokou dostupností, kde je ztráta dat nepřijatelná.

2.2.2 Režim asynchronního potvrzení

Režim asynchronního potvrzování (commit) upřednostňuje výkon primární repliky tím, že umožňuje transakcím potvrzovat transakce bez čekání na potvrzení posílení protokolu sekundárními replikami. Tento režim je vhodný pro repliky pro zotavení po havárii nebo v případech, kdy je synchronní potvrzování kvůli latenci sítě nepraktické.

Nevýhodou je potenciální ztráta dat během failoveru. Pokud primární replika selže, některé potvrzené transakce se nemusí dostat k sekundární replikě. Množství potenciální ztráty dat závisí na šířce pásma sítě, výkonu sekundární repliky a načasování selhání. Organizace musí toto riziko akceptovat při používání asynchronního režimu.

2.3 Typy failoveru

2.3.1 Automatické přepnutí při selhání

Automatické přepnutí služeb při selhání umožňuje skupině dostupnosti detekovat selhání primární repliky a automaticky povýšit sekundární repliku na primární bez zásahu správce. Tato funkce minimalizuje dobu trvání (RTO) eliminací nutnosti ruční reakce na selhání.

Automatické převzetí služeb při selhání vyžaduje režim synchronního potvrzení, aby byla zajištěna nulová ztráta dat. Pokud je tato funkce povolena, skupina dostupnosti nepřetržitě monitoruje stav primární repliky. Pokud primární replika přestane reagovat nebo selže, cluster Windows Server Failover Cluster zahájí automatické převzetí služeb při selhání na určenou sekundární repliku.

2.3.2 Ruční záložní přepnutí

Ruční failover umožňuje správcům záměrně přepnout roli primární repliky na sekundární repliku, obvykle pro účely plánované údržby nebo testování. Na rozdíl od automatického failoveru vyžaduje ruční failover k zahájení explicitní zásah správce.

Pro repliky se synchronním potvrzením je k dispozici manuální převzetí služeb při selhání bez ztráty dat. Správce zahájí převzetí služeb při selhání prostřednictvím SQL Server Management Studio, Transact-SQL nebo PowerShell. Primární replika dokončí zpracování aktuálních transakcí, odešle všechny zbývající záznamy protokolu do cílové sekundární repliky a před přenosem primární role čeká na potvrzení.

Ruční failover může nastat i u replik s asynchronním potvrzováním, ale to vyžaduje vynucený failover s možnou ztrátou dat. Správci by měli používat vynucený ruční failover pouze během skutečných katastrofických scénářů, kdy primární replika není k dispozici a ztráta dat je přijatelná ve srovnání s prodlouženým výpadkem.

2.3.3 Vynucené přepnutí při selhání

Vynucené přepnutí služeb při selhání umožňuje přepnutí služeb při selhání na asynchronní sekundární repliku nebo na sekundární repliku, která není plně synchronizovaná, s explicitním potvrzením potenciální ztráty dat. Tato možnost slouží jako poslední možnost, když primární replika není k dispozici a neexistuje žádná synchronizovaná sekundární replika.

2.4 Synchronizace dat

2.4.1 Jak funguje synchronizace dat

Synchronizace dat ve skupinách dostupnosti Always On probíhá prostřednictvím průběžného odesílání záznamů transakčního protokolu z primární repliky do všech sekundárních replik. Tato synchronizace založená na protokolech zajišťuje konzistenci a zároveň umožňuje nezávislé úložiště pro každou repliku.

2.4.2 Záznamy transakčních protokolů a zabezpečení

Zpevnění transakčních protokolů je kritickým krokem, při kterém se záznamy protokolů zapisují do trvalého úložiště na sekundárních replikách. Zpevnění zajišťuje, že záznamy protokolů přežijí selhání sekundárních replik a lze je během obnovy znovu přehrát.

2.5 Sekundární repliky s možností čtení a čitelné sekundární repliky

2.5.1 Odlehčení úloh pouze pro čtení

Čitelné sekundární repliky umožňují organizacím odlehčit primární repliku od úloh náročných na čtení, což zlepšuje celkový výkon systému a využití zdrojů. Tato schopnost škálování čtení je jednou z klíčových výhod skupin dostupnosti oproti starším řešením s vysokou dostupností.

Organizace by měly při navrhování konfigurací skupin dostupnosti zvážit požadavky na pracovní zátěž pouze pro čtení. Více sekundárních serverů s možností čtení může rozdělit zátěž sestav mezi několik serverů. Směrovací seznamy pouze pro čtení definují pořadí, ve kterém sekundární servery přijímají připojení s úmyslem čtení, což umožňuje strategie vyvažování zátěže.

2.5.2 Zálohovací operace na sekundárních replikách

Spouštění záloh na sekundárních replikách snižuje zatížení vstupně/výstupních operací (I/O) a centrální procesorové jednotky (CPU) primární repliky, což jí umožňuje soustředit se na transakční úlohy. Tato funkce pomáhá organizacím splnit požadavky na zálohování bez ovlivnění produkčního výkonu.

SQL Server Podporuje úplné zálohy databáze, rozdílové zálohy a zálohy transakčních protokolů na sekundárních replikách. Předvolby zálohování lze nakonfigurovat tak, aby upřednostňovaly sekundární repliky, primární repliky, pouze sekundární repliky nebo libovolnou repliku. Zálohovací systém automaticky vybere vhodnou repliku na základě těchto předvoleb a aktuální dostupnosti.

Pro více informací o SQL Server zálohování, viz naše komplexní průvodce.

2.6 Posluchače skupin dostupnosti

2.6.1 Co je to posluchač?

Posluchač skupiny dostupnosti je název virtuální sítě (VNN) a IP adresa, které klientské aplikace používají k připojení k databázím skupin dostupnosti. Posluchač automaticky přesměrovává připojení na aktuální primární repliku, čímž eliminuje nutnost, aby aplikace sledovaly, který server je aktuálně primární.

2.6.2 Směrování připojení klienta

Směrování připojení klienta prostřednictvím listeneru podporuje jak čtení i zápis, tak i připojení pouze pro čtení. Listener prozkoumá požadavek na připojení a směruje jej do příslušné repliky na základě záměru aplikace.

3. Předpoklady a požadavky

3.1 Failover Clustering systému Windows Server pro skupiny dostupnosti

3.1.1 Základy failover clusteringu Windows Serveru

Windows Server Failover Clustering (WSFC) poskytuje základ pro skupiny dostupnosti Always On Availability Groups správou členství v clusteru, monitorováním stavu a orchestrací převzetí služeb při selhání. Na rozdíl od instancí clusteru s podporou převzetí služeb při selhání používají skupiny dostupnosti WSFC pouze pro koordinaci clusteru, nikoli pro správu sdíleného úložiště.

Každý SQL Server Instance účastnící se skupiny dostupnosti musí být uzel v clusteru WSFC. Cluster spravuje hlasování kvora, detekci stavu uzlů a stav zdrojů skupiny dostupnosti. Když primární replika selže, WSFC koordinuje proces převzetí služeb při selhání a aktualizuje zdroje clusteru tak, aby odrážely novou primární repliku.

3.1.2 Konfigurace kvora clusteru

Kvorum clusteru určuje, které uzly mohou fungovat, když dojde k problémům s připojením k síti, čímž se zabraňuje scénářům s rozděleným mozkem, kdy se více uzlů nezávisle prohlašuje za primární. Konfigurace kvora definuje, co představuje většinový hlas pro rozhodnutí clusteru.

Pro skupiny dostupnosti je k dispozici několik režimů kvora:

• Většina uzlů používá pouze hlasy uzlů clusteru a funguje dobře pro clustery s lichým počtem uzlů.
• Většina uzlů a sdílených souborů přidává hlas svědka sdílení souborů, vhodný pro clustery uzlů se sudým číslem.
• Node and Disk Majority používá diskový svědek, ale je méně běžný pro skupiny dostupnosti, protože sdílené úložiště není vyžadováno.

3.1.3 Klastrování více podsítí

Clustering s více podsítěmi umožňuje replikám skupin dostupnosti rozprostírat se přes různé síťové podsítě, což podporuje geograficky distribuované nasazení napříč datovými centry. Tato funkce je nezbytná pro konfigurace pro zotavení po havárii, kde repliky existují na oddělených místech.

3.2 SQL Server Požadavky na vydání

3.2.1 Funkce Enterprise Edition

SQL Server Enterprise Edition nabízí plnou funkcionalitu skupin dostupnosti bez omezení. Enterprise Edition podporuje až osm sekundárních replik, čitelné sekundární repliky, automatické osazení, distribuované skupiny dostupnosti a všechny pokročilé funkce.

3.2.2 Funkce Standard Edition (základní skupiny dostupnosti)

SQL Server Standard edice 2016 a novější podporují základní skupiny dostupnosti s významnými omezeními. Základní skupiny dostupnosti poskytují základní funkce vysoké dostupnosti za nižší cenu, což je vhodné pro organizace s jednoduššími požadavky.

4. Konfigurace skupin dostupnosti Always On

4.1 Příprava prostředí

Před vytvořením skupiny dostupnosti musí být prostředí řádně připraveno s účty služby Active Directory, konfiguracemi serverů a síťovou infrastrukturou.

4.1.1 Nastavení řadiče domény

Řadič domény služby Active Directory musí být nakonfigurován tak, aby podporoval cluster skupin dostupnosti a SQL Server servisní účty.

1. Přihlaste se k řadiči domény s přihlašovacími údaji správce domény.
2. Otevřená Server manager a přejděte na Tools -> Uživatelé a počítače služby Active Directory.
3. Vytvořte organizační jednotku pro SQL Server objekty, pokud jeden neexistuje.
4. Ověřte, zda v adresáři Active Directory existují objekty počítačů pro všechny uzly clusteru.
5. Ujistěte se, že služby DNS (Domain Name System) jsou správně nakonfigurovány a že se všechny názvy serverů správně překládají.

4.1.2 Vytváření servisních účtů

Vytvořte vyhrazené účty služby Active Directory pro SQL Server služby na každém uzlu.

1. Otevřená Uživatelé a počítače služby Active Directory na řadiči domény.
2. Klikněte pravým tlačítkem myši na příslušnou organizační jednotku a vyberte Nový -> Uživatel.
3. Zadejte název servisního účtu (například svc_SQLServer) a nastavte Přihlašovací jméno uživatele.
4. klikněte další a zadejte silné heslo.
5. vybrat Uživatel nemůže změnit heslo a Heslo nikdy nevyprší.
6. klikněte další a pak úprava k vytvoření účtu.
7. Opakujte pro všechny potřebné další servisní účty (SQL Server Agent, SSRS atd.).

4.1.3 Konfigurace oprávnění správce

Servisní účty a účty používané ke konfiguraci SQL Server musí mít příslušná oprávnění na všech uzlech clusteru.

1. Přihlaste se ke každému serveru uzlu clusteru.
2. Otevřená Správa počítače z Home nabídku nebo Správce serveru.
3. Rozšířit Místní uživatelé a skupiny a zvolte Skupiny.
4. Klepněte pravým tlačítkem myši Správci a zvolte Nemovitosti.
5. klikněte přidat a zadejte název servisního účtu.
6. klikněte Zkontrolujte jména pro ověření účtu a poté klikněte na OK.
7. klikněte OK zavřete dialogové okno Vlastnosti pro správce.
8. Opakujte na všech uzlech clusteru.

4.2 Instalace a konfigurace WSFC

Před povolením skupin dostupnosti Always On musí být na všech uzlech nainstalována a nakonfigurována služba Windows Server Failover Clustering.

4.2.1 Instalace funkce Failover Clustering

Nainstalujte funkci Failover Clustering na každý server, který se bude účastnit skupiny dostupnosti.

1. Otevřená Server manager na prvním uzlu clusteru.
2. klikněte Řídit -> Přidat role a funkce.
3. klikněte další přes úvodní obrazovky.
4. vybrat Instalace založená na rolích nebo funkcích a klepněte na tlačítko další.
5. Vyberte lokální server a klikněte na další.
6. Přeskočte obrazovku Role a klikněte na další.
7. Na obrazovce Funkce vyberte Klastrování při selhání.
8. klikněte Přidejte funkce po zobrazení výzvy k zahrnutí nástrojů pro správu.
9. klikněte další a pak instalovat.
10. Počkejte na dokončení instalace a klikněte zavřít.
11. Opakujte na všech serverech, které se budou účastnit clusteru.

4.2.2 Vytvoření failover clusteru

Po instalaci funkce Failover Clustering na všechny uzly vytvořte cluster z jednoho uzlu.

1. Otevřená Správce failover clusteru od Server manager -> Tools.
2. klikněte Vytvořit Cluster v podokně Akce.
3. klikněte další na stránce Než začnete.
4. klikněte Procházet a přidejte všechny servery, které budou uzly clusteru.
5. klikněte další po přidání všech uzlů.
6. Dovolená Spustit všechny testy (doporučeno) vybrané a klikněte další.
7. Zkontrolujte výsledky ověřovacích testů a vyřešte případné chyby nebo varování.
8. klikněte úprava po úspěšném dokončení ověření.
9. Zadejte název clusteru a IP adresu.
10. Zrušte zaškrtnutí Přidat veškeré vhodné úložiště do clusteru protože sdílené úložiště není vyžadováno.
11. klikněte další a zkontrolujte potvrzení.
12. klikněte úprava k vytvoření clusteru.

4.2.3 Ověření konfigurace clusteru

Ověřte konfiguraci clusteru, abyste se ujistili, že všechny uzly mohou správně komunikovat a cluster správně funguje.

1. In Správce failover clusteru, klikněte pravým tlačítkem myši na název clusteru.
2. vybrat Ověření clusteru z menu.
3. klikněte další na stránce Než začnete.
4. vybrat Spustit všechny testy (doporučeno) a klepněte na tlačítko další.
5. klikněte další zahájit ověřovací testy.
6. Po dokončení testů zkontrolujte ověřovací zprávu.
7. Řešte všechny chyby nebo varování identifikované ve zprávě.
8. klikněte úprava zavřete průvodce.

NIKDY instalace SQL Server pro skupiny dostupnosti

instalovat SQL Server na každém uzlu, který se bude účastnit skupiny dostupnosti pomocí možnosti samostatné instalace.

1. Spusťte SQL Server instalační médium na prvním uzlu.
2. vybrat Nový SQL Server samostatná instalace.
3. Zadejte produktový klíč nebo vyberte zkušební verzi.
4. Přijměte licenční podmínky a klikněte další.
5. Dokončete kontroly předpokladů a vyřešte všechny problémy.
6. Na stránce Výběr funkcí vyberte Služby databázového stroje.
7. Nakonfigurujte název instance (použijte stejný název instance na všech uzlech).
8. Na stránce Konfigurace serveru zadejte přihlašovací údaje servisního účtu.
9. Konfigurace typů spouštění služeb jako Automatický.
10. Na stránce Konfigurace databázového stroje vyberte režim ověřování.
11. Přidejte účty správce.
12. Nakonfigurujte datové adresáře s použitím konzistentních cest napříč všemi uzly.
13. Dokončete instalaci a ověřte její úspěšnost.
14. Opakujte instalaci na všech ostatních uzlech clusteru se stejným nastavením.

4.4 Povolení funkce skupin dostupnosti Always On

Po instalaci SQL Server na všech uzlech povolte funkci Skupiny dostupnosti Always On na každé instanci.

4.4.1 Povolení přes SQL Server Správce konfigurace

Použijte SQL Server Správce konfigurace pro povolení skupin dostupnosti Always On prostřednictvím grafického rozhraní.

1. Otevřená SQL Server Správce konfigurace na prvním uzlu.
2. Rozšířit SQL Server Služby v levém podokně.
3. Klepněte pravým tlačítkem myši na ikonu SQL Server instanci a vyberte Nemovitosti.
4. Klepněte na tlačítko Vysoká dostupnost AlwaysOn Karta.
5. Kontrola Povolit skupiny dostupnosti AlwaysOn.
6. Ověřte, zda je název failover clusteru systému Windows správný.
7. klikněte OK pro uložení změn.
8. klikněte OK na varování, že je nutné službu restartovat.
9. Klepněte pravým tlačítkem myši na ikonu SQL Server službu a vyberte Restart.
10. Počkejte na úspěšné restartování služby.
11. Opakujte na všech uzlech clusteru.

4.4.2 Povolení pomocí PowerShellu

PowerShell poskytuje skriptovanou metodu pro povolení skupin dostupnosti Always On napříč více uzly.

1. Otevřete PowerShell jako správce na prvním uzlu.
2. Importujte SQL Server Modul PowerShellu:

   Import-Module SQLPS -DisableNameChecking

3. Povolit skupiny dostupnosti Always On:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Služba se při použití parametru Force automaticky restartuje.
5. Ověřte, zda je funkce povolena:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Opakujte pro každý uzel clusteru a nahraďte příslušné názvy serverů a instancí.

4.4.3 Ověření, zda je funkce povolena

Před pokračováním v konfiguraci ověřte, zda jsou ve všech instancích povoleny skupiny dostupnosti Always On.

1. Připojte se ke každému SQL Server instance s použitím SQL Server Studio pro správu.
2. Otevřete nové okno dotazu a spusťte:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Ověřte, že výsledek je 1 (povoleno).
4. Zkontrolujte, zda SQL Server Instance se zobrazí ve Správci clusteru s podporou převzetí služeb při selhání v části role clusteru.
5. Ověřte existenci koncového bodu skupiny dostupnosti spuštěním:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Pokud koncový bod neexistuje, bude vytvořen během vytváření skupiny dostupnosti.

4.5 Příprava databází pro skupiny dostupnosti

Databáze musí před přidáním do skupiny dostupnosti splňovat specifické požadavky.

4.5.1 Požadavky na model obnovy databáze

Před přidáním primární repliky do skupiny dostupnosti změňte její model obnovy na PLNÝ.

1. Připojte se k primární replice pomocí SQL Server Studio pro správu.
2. Klikněte pravým tlačítkem myši na databázi a vyberte Nemovitosti.
3. Vybrat možnosti stránky.
4. Přeměna Model obnovy na Plný.
5. klikněte OK uložit změnu.
6. Alternativně použijte Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Vytváření úplných záloh databáze

Vytvořte úplnou zálohu databáze, abyste vytvořili řetězec záloh potřebný pro skupiny dostupnosti.

1. In SQL Server V aplikaci Management Studio klikněte pravým tlačítkem myši na databázi.
2. vybrat Úkoly -> zálohovat.
3. Ověřit si Typ zálohy je nastavena na hodnotu Plný.
4. Vyberte cíl zálohy nebo přidejte nový cíl.
5. klikněte OK provést zálohu.
6. Alternativně použijte Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Zálohování transakčních protokolů

Vytvořte zálohu transakčního protokolu, abyste se ujistili, že je řetězec protokolů nastaven a minimalizovali dobu inicializace.

1. In SQL Server V aplikaci Management Studio klikněte pravým tlačítkem myši na databázi.
2. vybrat Úkoly -> zálohovat.
3. Přeměna Typ zálohy na Protokol transakcí.
4. Vyberte cíl zálohy.
5. klikněte OK provést zálohu.
6. Alternativně použijte Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Vytvoření skupiny dostupnosti

Vytvořte skupinu dostupnosti pomocí jedné z několika dostupných metod v závislosti na vašich preferencích a požadavcích na automatizaci.

4.6.1 Použití Průvodce novou skupinou dostupnosti

Průvodce vytvořením skupiny dostupnosti poskytuje grafické rozhraní pro vytváření skupin dostupnosti.

1. In SQL Server Management Studio, připojte se k instanci, která bude hostovat primární repliku.
2. Rozšířit Vysoká dostupnost AlwaysOn v Průzkumníku objektů.
3. Klepněte pravým tlačítkem myši Skupiny dostupnosti a zvolte Průvodce novou skupinou dostupnosti.
   
4. klikněte další na úvodní stránce.
5. Zadejte název skupiny dostupnosti a klikněte na další.
6. Na stránce Vybrat databáze vyberte databáze, které chcete zahrnout.
7. Ověřte, zda databáze splňují všechny předpoklady, a klikněte na tlačítko další.
8. Na stránce Zadat repliky klikněte na Přidat repliku.
9. Připojte se ke každé instanci sekundární repliky.
10. Nakonfigurujte vlastnosti repliky pro každou instanci (režim dostupnosti, režim přepnutí služeb při selhání).
11. Klepněte na tlačítko Koncové body a zkontrolujte konfiguraci koncového bodu.
12. Klepněte na tlačítko Předvolby zálohování a nakonfigurujte priority zálohování.
13. Klepněte na tlačítko Posluchač a volitelně vytvořit posluchač.
14. klikněte další a vyberte metodu synchronizace dat.
15. Zkontrolujte výsledky validace a vyřešte případné problémy.
16. klikněte další a projděte si shrnutí.
17. klikněte úprava k vytvoření skupiny dostupnosti.
18. Sledujte průběh a ověřujte úspěšné vytvoření.

4.6.2 Používání jazyka Transact-SQL

Vytvořte skupiny dostupnosti pomocí Transact-SQL pro skriptovatelná a opakovatelná nasazení.

1. Vytvořte skupinu dostupnosti na primární replice:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Připojte sekundární repliku ke skupině dostupnosti:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Připojení k sekundární databázi:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Používání PowerShellu

PowerShell poskytuje skriptovací funkce pro vytváření a správu skupin dostupnosti.

1. Vytvořte objekt skupiny dostupnosti:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Přidat databáze:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Nakonfigurujte repliky s požadovanými vlastnostmi pomocí rutiny New-SqlAvailabilityReplica.
4. Připojte sekundární repliky pomocí rutiny Join-SqlAvailabilityGroup.

4.7 Přidání replik do skupiny dostupnosti

Nakonfigurujte vlastnosti specifické pro repliku, které řídí, jak se každá instance účastní skupiny dostupnosti.

4.7.1 Konfigurace vlastností repliky

Nastavte vlastnosti pro každou repliku, abyste definovali její roli a možnosti v rámci skupiny dostupnosti.

1. In SQL Server Management Studio, rozbalit Vysoká dostupnost AlwaysOn -> Skupiny dostupnosti.
2. Rozbalte skupinu dostupnosti a poté rozbalte Repliky dostupnosti.
   
3. Klikněte pravým tlačítkem myši na repliku a vyberte Nemovitosti.
4. Zkontrolujte a upravte nastavení připojení pro primární a sekundární role.
5. V případě potřeby nakonfigurujte hodnoty časového limitu relace.
6. klikněte OK pro uložení změn.

4.7.2 Nastavení režimů dostupnosti

Nakonfigurujte režim dostupnosti pro řízení chování synchronizace mezi replikami.

1. Klikněte pravým tlačítkem myši na skupinu dostupnosti a vyberte Nemovitosti.
2. v obecně stránku, přejděte na Repliky dostupnosti sekce.
3. Pro každou repliku vyberte Synchronní potvrzení or Asynchronní potvrzení (commit) z rozevíracího seznamu.
4. Pro lokální repliky s vysokou dostupností použijte synchronní potvrzení (commit).
5. Pro geograficky vzdálené repliky zotavení po havárii použijte asynchronní potvrzení (commit).
6. klikněte OK pro uložení konfigurace.

4.7.3 Nastavení režimů failoveru

Nakonfigurujte režim převzetí služeb při selhání, abyste mohli řídit, jak dochází k převzetí služeb při selhání pro každou repliku.

1. Klikněte pravým tlačítkem myši na skupinu dostupnosti a vyberte Nemovitosti.
2. v obecně stránku, přejděte na Repliky dostupnosti sekce.
3. Pro synchronní repliky potvrzení vyberte Automatický or Manuál režim přepnutí při selhání.
4. Automatické převzetí služeb při selhání vyžaduje synchronní režim potvrzení a umožňuje bezobslužné převzetí služeb při selhání.
5. Pro asynchronní repliky potvrzení je k dispozici pouze ruční převzetí služeb při selhání.
6. Nakonfigurujte až tři repliky pro automatické převzetí služeb při selhání (jednu primární a dvě sekundární).
7. klikněte OK použít nastavení.

4.7.4 Konfigurace předvoleb zálohování

Nastavením předvoleb zálohování určete, kde by se měly zálohovací operace provádět.

1. Klikněte pravým tlačítkem myši na skupinu dostupnosti a vyberte Nemovitosti.
2. vybrat Předvolby zálohování v levém podokně.
3. Vyberte jednu z předvoleb zálohování:
   • Preferujte sekundárníZálohy na sekundární síti, pokud jsou k dispozici, jinak na primární.
   • Pouze sekundárníZálohy pouze na sekundárních replikách
   • PrimárníZálohy pouze na primární replice
   • Jakákoli replikaZálohy na jakékoli dostupné replice
4. Nastavte hodnoty priority zálohování pro každou repliku (0–100).
5. Vyšší hodnoty priority označují preferované cíle zálohování.
6. klikněte OK pro uložení preferencí.

4.8 Konfigurace posluchače skupiny dostupnosti

Vytvořte posluchač, který poskytne jeden bod připojení a automaticky přesměruje na aktuální primární repliku.

4.8.1 Vytvoření posluchače

Přidejte do skupiny dostupnosti posluchače pro správu připojení klientů.

1. In SQL Server V aplikaci Management Studio rozbalte skupinu dostupnosti.
2. Klepněte pravým tlačítkem myši Posluchače skupin dostupnosti a zvolte Přidat posluchače.
   
3. Zadejte název DNS pro listener (například AG_Listener).
4. Zadejte číslo portu (výchozí je 1433).
5. vybrat Static IP pro síťový režim.
6. klikněte přidat přidat IP adresu pro každou podsíť.
7. Zadejte IP adresu a vyberte podsíť.
8. klikněte OK k vytvoření posluchače.
9. Ověřte, zda se posluchač zobrazuje v Průzkumníku objektů a je online.

4.8.2 Konfigurace nastavení DNS a IP adresy

Ověřte registraci DNS a konfiguraci sítě pro listener.

1. Otevřete Správce DNS na řadiči domény.
2. Ověřte, zda byl název posluchače zaregistrován se všemi IP adresami.
3. Otestujte překlad DNS z klientských počítačů:

   nslookup ListenerName

4. Ověřte, zda jsou vráceny všechny nakonfigurované IP adresy.
5. Ve Správci clusteru s podporou převzetí služeb při selhání rozbalte Role a vyberte skupinu dostupnosti.
6. Ověřte, zda jsou zdroje IP adres online.
7. Zkontrolujte, zda je zdroj síťového názvu online.
   

4.8.3 Testování připojení posluchače

Ověřte, zda se klientské aplikace mohou připojit prostřednictvím listeneru.

1. Z klientského počítače otevřete SQL Server Studio pro správu.
2. Připojte se pomocí názvu listeneru namísto názvu serveru.
3. Spusťte dotaz pro ověření připojení k aktuální primární replice:

   SELECT @@SERVERNAME;

4. Otestujte směrování pro čtení přidáním ApplicationIntent=ReadOnly do připojovacího řetězce.
5. Ověřte, zda připojení přesměrovává na čitelnou sekundární repliku.
6. Otestujte převzetí služeb při selhání ručním převzetím skupiny dostupnosti a ověřením opětovného připojení.

4.9 Metody synchronizace dat

Vyberte metodu synchronizace dat pro inicializaci sekundárních replik s kopiemi databáze.

4.9.1 Automatické setí

Automatické seedování přenáší data databáze po síti bez nutnosti ručního zálohování a obnovování.

1. Během vytváření skupiny dostupnosti vyberte Automatické setí jako metoda synchronizace.
   
2. Zajistěte síťové připojení a dostatečnou šířku pásma mezi replikami.
3. Primární replika automaticky streamuje data databáze do sekundárních replik.
4. Sledujte průběh zavádění pomocí řídicího panelu skupiny dostupnosti nebo DMV.
5. Automatické setí vyžaduje SQL Server 2016 nebo novější.
6. U velkých databází zvažte dopad na síť a naplánujte jejich spuštění během období s nízkým využitím.

4.9.2 Ruční nasazení (zálohování a obnovení)

Ruční osazení zahrnuje vytváření záloh na primárním serveru a jejich obnovení na sekundárních replikách.

1. Na primární replice proveďte úplnou zálohu:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Vytvořte zálohu transakčního protokolu:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Na každé sekundární replice obnovte úplnou zálohu:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Obnovení zálohy protokolu:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Připojte databázi ke skupině dostupnosti:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Ověřte, zda byla zahájena synchronizace a zda databáze dosáhla stavu SYNCHRONIZOVÁNO.

4.9.3 Soubory snímků databáze

Použijte soubory snímků databáze k inicializaci sekundárních replik z existujících souborů databáze.

1. Odpojte nebo zálohujte databázi na primární replice.
2. Zkopírujte soubory databáze do každé sekundární repliky pomocí stejných cest k souborům.
3. V sekundárních replikách připojte databázi nebo ji obnovte bez obnovení.
4. Ujistěte se, že je databáze ve stavu OBNOVENÍ.
5. Připojte databázi ke skupině dostupnosti.
6. Tato metoda je užitečná pro velmi rozsáhlé databáze, kde by byl síťový přenos nepraktický.

5. Nejčastější dotazy

5.1 Obecné otázky

Otázka: Jaký je rozdíl mezi Always On FCI a Always On AG?

A: Instance clusteru Always On Failover poskytují vysokou dostupnost na úrovni instance s využitím sdíleného úložiště, zatímco skupiny dostupnosti Always On poskytují vysokou dostupnost na úrovni databáze bez sdíleného úložiště. AG nabízí čitelné sekundární servery a flexibilnější geografickou distribuci.

Otázka: Mohu používat skupiny dostupnosti Always On s SQL Server Standardní edice?

A: Ano, SQL Server Standard Edition 2016 a novější podporují základní skupiny dostupnosti s omezeními, jako je jedna databáze na skupinu dostupnosti, maximálně dvě repliky a žádná podpora čitelných sekundárních databází.

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

A: Ne, skupiny dostupnosti nevyžadují sdílené úložiště. Každá replika uchovává nezávislé kopie databází na lokálním úložišti, synchronizované prostřednictvím odesílání transakčních protokolů.

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 podporovat až 18 replik ve dvou skupinách dostupnosti.

5.2 Otázky týkající se konfigurace

Otázka: Jak si mohu vybrat mezi synchronním a asynchronním režimem potvrzení?

A: Pro nulové ztráty dat v rámci stejného datového centra nebo sítí s nízkou latencí použijte synchronní potvrzení. Pro vzdálené repliky pro zotavení po havárii, kde by synchronní potvrzení ovlivnilo výkon, použijte asynchronní potvrzení.

Otázka: Mohu ve stejné skupině dostupnosti kombinovat synchronní a asynchronní repliky?

A: Ano, skupiny dostupnosti podporují smíšené konfigurace se synchronními i asynchronními replikami. To umožňuje lokální vysokou dostupnost se synchronními replikami a vzdálenou obnovu po havárii s asynchronními replikami.

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

A: Stávající připojení jsou při failoveru ukončena. Aplikace s logikou opakování připojení se automaticky znovu připojí k novému primárnímu serveru prostřednictvím listeneru. Proces failoveru je obvykle dokončen během několika sekund až minut.

Otázka: Musím synchronizovat přihlašovací údaje a úlohy napříč replikami?

Odpověď: V SQL Server 2019 a starší verze, ano – přihlášení, úlohy SQL Agentu a propojené servery je nutné synchronizovat ručně. SQL Server Verze 2022 zavádí skupiny omezené dostupnosti, které tyto objekty automaticky zahrnují.

5.3 Otázky managementu

Otázka: Mohu spouštět zálohy na sekundárních replikách?

A: Ano, sekundární repliky podporují úplné, rozdílové a transakční zálohy. Nakonfigurujte předvolby zálohování tak, aby se zálohy odlehčily od primární repliky a snížilo se využití jejích zdrojů.

Otázka: Jak mohu provést záplatu SQL Server s minimálními prostoji?

A: Postupné aktualizace se provádějí tak, že se nejprve opraví sekundární repliky, poté se provede ruční přepnutí na opravený sekundární server a nakonec se opravou provede předchozí primární server. Tím se minimalizuje doba výpadku na dobu trvání přepnutí na záložní server.

Otázka: Mohu přidat databáze do existující skupiny dostupnosti?

A: Ano, databáze lze přidat do spuštěných skupin dostupnosti. Databáze musí být v modelu úplné obnovy s plnou zálohou a sekundární repliky musí být nasazovány automaticky nebo manuálně.

Otázka: Co je automatické setí a měl bych ho používat?

A: Automatické osazení přenáší data databáze po síti a inicializuje sekundární repliky bez ručního zálohování. Použijte ho pro menší databáze nebo v případě, že je dostatečná šířka pásma sítě. U velmi velkých databází může být ruční osazení rychlejší.

Otázka: Kde mám ve skupině dostupnosti spustit příkaz DBCC CHECKDB?

A: Pro snížení zátěže primární repliky byste měli spustit příkaz DBCC CHECKDB na sekundárních replikách. Kontroly konzistence databáze lze provádět na sekundárních databázích, aniž by to ovlivnilo výkon primární repliky.

Více informací o DBCC CHECKDB naleznete v našich komplexní průvodce.

5.4 Otázky k řešení problémů

Otázka: Proč je moje databáze ve stavu NESYNCHRONIZUJE SE?

A: Mezi běžné příčiny patří problémy s připojením k síti, pozastavený přesun dat, nedostatek místa na disku v sekundárních replikách nebo problémy s koncovými body. Zkontrolujte popis stavu synchronizace a SQL Server protokoly chyb pro konkrétní podrobnosti. Pokud sekundární databáze vstoupila do stav zotavení nebo ukazuje čeká na vymáhání, podívejte se na propojené průvodce s cílenými opravami.

Otázka: Jak vynutím failover, když primární server není k dispozici?

A: Připojte se k sekundární replice a spusťte příkaz ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Tím se potvrdí potenciální ztráta dat a okamžitě se sekundární replika povýší na primární.

Otázka: Proč se klienti nemohou připojit k mému listeneru?

A: Ověřte, zda je posluchač online ve Správci clusteru s podporou převzetí služeb při selhání, zda byla registrace DNS úspěšná, zda jsou všechny IP adresy posluchače dostupné z klientů a zda pravidla brány firewall povolují provoz na portu posluchače.

Otázka: Co znamená velká fronta pro opakování?

A: Velká fronta opakování znamená, že sekundární replika nemůže aplikovat záznamy protokolu tak rychle, jak dorazí. To může naznačovat úzká hrdla diskového I/O, omezení CPU nebo blokování dotazů pouze pro čtení na sekundární replikaci.

Otázka: Co mám dělat, když havárie postihne všechny repliky a mé zálohy jsou také poškozené?

A: Tento nejhorší scénář, i když je extrémně vzácný, může nastat v důsledku útoků ransomwaru, rozsáhlých selhání úložišť nebo kaskádových katastrof. Vaší primární obranou je prevence: udržujte geograficky rozptýlené repliky, ukládejte zálohy na oddělená místa a
pravidelně testujte postupy pro zotavení z havárie. Pokud selžou všechny standardní možnosti obnovy, je nutné využít specializovaného Nástroj pro obnovu dat SQL se může pokusit extrahovat data z poškozených souborů MDF jako nouzové opatření.

5.5 Otázky týkající se licencování a nákladů

Otázka: Jak se licencují skupiny dostupnosti Always On?

A: SQL Server Licencování závisí na edici a modelu nasazení. Skupiny dostupnosti Enterprise Edition vyžadují licence Enterprise na všech replikách. Pasivní sekundární repliky mohou za určitých podmínek získat nárok na bezplatnou licenci.

Otázka: Mohu použít SQL Server Verze pro vývojáře pro skupiny dostupnosti?

A: Ano, Developer Edition obsahuje všechny funkce Enterprise Edition včetně plné podpory skupin dostupnosti. Je však licencována pouze pro vývoj a testování, nikoli pro produkční použití.

Otázka: Vyžadují čitelné sekundární soubory další licence?

A: Licencování závisí na scénáři. Pasivní sekundární servery pro zotavení po havárii obvykle nevyžadují licence. Aktivní sekundární servery obsluhující úlohy pouze pro čtení obvykle licence vyžadují, i když se konkrétní podmínky liší.

Otázka: Existuje bezplatný způsob, jak dosáhnout vysoké dostupnosti s SQL Server?

A: SQL Server Express Edition nepodporuje skupiny dostupnosti. SQL Server Standardní edice podporuje základní skupiny dostupnosti počínaje SQL Server 2016, poskytující základní vysokou dostupnost za licenční náklady Standard Edition.

Otázka: Co jsou distribuované skupiny dostupnosti?

A: Distribuované skupiny dostupnosti jsou speciálním typem skupiny dostupnosti, která zahrnuje dvě samostatné skupiny dostupnosti a umožňuje scénáře, které překračují možnosti tradičních skupin dostupnosti. Představeno v SQL Server V roce 2016 řeší distribuované skupiny dostupnosti požadavky na škálování a geografické rozložení.

6. závěr

6.1 Shrnutí klíčových bodů

SQL Server Skupiny dostupnosti Always On představují přední řešení společnosti Microsoft pro vysokou dostupnost a zotavení po havárii pro kriticky důležité databáze. Poskytují převzetí služeb na úrovni databáze bez požadavků na sdílené úložiště, čitelné sekundární repliky pro odlehčení pracovní zátěže a flexibilní geografickou distribuci pro komplexní ochranu dat. Pro organizace, které stále používají řešení, jako jsou přeprava klád or replikaceSkupiny dostupnosti nabízejí robustnější a provozně jednodušší cestu k upgradu.

6.2 Kdy použít skupiny dostupnosti Always On

Zvolte skupiny dostupnosti, pokud požadujete vysokou dostupnost na úrovni databáze s automatickým přepnutím při selhání. Organizace, které potřebují ochranu před nulovou ztrátou dat pro kritické databáze, těží ze synchronních replik potvrzení s automatickým přepnutím při selhání. Aplikace vyžadující možnosti škálování pro čtení využívají čitelné sekundární repliky k distribuci úloh dotazů.

6.3 Začínáme s implementací

Začněte plánování skupin dostupnosti posouzením obchodních požadavků, včetně RTO, RPO a rozpočtových omezení. Zdokumentujte aktuální databázovou infrastrukturu, závislosti aplikací a mezery ve vysoké dostupnosti. Navrhněte architekturu skupin dostupnosti, která řeší požadavky a zároveň zůstává v mezích omezených zdrojů.

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
• Oficiální dokument společnosti Microsoft: Distribuované skupiny dostupnosti

---

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