1. Úvod do SQL Server Vysoká dostupnost
Vysoká dostupnost v SQL Server označuje schopnost systému zůstat v provozu s minimálními prostoji v případě selhání hardwaru, problémů se softwarem nebo plánované údržby. Důležitost vysoké dostupnosti nelze přeceňovat. Když se databáze stanou nedostupnými, organizace čelí okamžitým důsledkům, včetně...ost příjmy, snížená produktivita a nespokojenost zákazníků.
Ačkoli se pojmy vysoká dostupnost (HA) a zotavení po havárii (DR) často používají zaměnitelně, řeší různé scénáře selhání. HA se zaměřuje na minimalizaci prostojů způsobených lokalizovanými selháními, jako jsou havárie serveru nebo instance, zatímco DR je navrženo pro zotavení z rozsáhlých katastrof, které postihují celé datové centrum nebo region.
Plánování HA se řídí dvěma kritickými metrikami:
- Cílový čas obnovy (RTO) definuje maximální přijatelnou dobu prostoje po selhání
- Objektivní bod obnovy (RPO) určuje maximální tolerovatelnou ztrátu dat.
Dostupnost se běžně měří v „devítkách“: 99.9 % (tři devítky) umožňuje 8.76 hodiny prostojů ročně, 99.99 % (čtyři devítky) umožňuje 52.6 minut a 99.999 % (pět devítek) omezuje prostoje na pouhých 5.26 minut ročně.
2. SQL Server Přehled řešení s vysokou dostupností
2.1 Kategorie řešení HA
SQL Server Řešení s vysokou dostupností lze rozdělit do několika kategorií:
- Ochrana na úrovni instance vs. databáze: Ochrana na úrovni instance, jako jsou instance Failover Clusteru, chrání celé instance včetně všech databází a serverových objektů, zatímco ochrana na úrovni databáze, jako jsou skupiny dostupnosti Always On, chrání konkrétní databáze.
- Synchronní vs. asynchronní přesun dat: Synchronní přesun dat zajišťuje nulovou ztrátu dat, ale může způsobit latenci, zatímco asynchronní přesun optimalizuje výkon, ale akceptuje možnou ztrátu dat.
- Automatické vs. manuální přepnutí služeb při selhání: Automatické přepnutí služeb při selhání minimalizuje prostoje bez ručního zásahu, zatímco manuální přepnutí služeb při selhání poskytuje větší kontrolu, ale vyžaduje zásah správce.
2.2 Běžná řešení vysoké dostupnosti
SQL Server nabízí osm primárních řešení s vysokou dostupností, z nichž každé se zabývá specifickými scénáři:
- Vždy dostupné skupiny dostupnosti
- Uzavřené skupiny dostupnosti
- Distribuované skupiny dostupnosti
- Instance failover clusteru
- SQL Server replikace
- Přeprava klád
- Zrcadlení databáze
- Propojení spravované instance
3. Skupiny dostupnosti Always On
Skupiny dostupnosti Always On představují SQL ServerPřední řešení pro vysokou dostupnost a obnovu po havárii na úrovni databází, představené v roce SQL Server 2012. Umožňuje skupinám databází převzít služby při selhání společně jako jeden celek a zároveň poskytuje čitelné sekundární repliky pro odlehčení dotazů.
KLÍČOVÉ VLASTNOSTI
- Podpora až 9 replik celkem (1 primární + 8 sekundárních)
- Až 5 replik v režimu synchronního potvrzování (1 primární + 4 sekundární)
- Automatické přepnutí na záložní systém s nulovou ztrátou dat v synchronním režimu
- Čitelné sekundární repliky pro odlehčení dotazů
- Přesun záloh do sekundárních replik
- Posluchač skupiny dostupnosti pro automatické směrování připojení
- Směrování pouze pro čtení pro dotazy na čtení s vyrovnáváním zátěže
- Více databází selháním převezme společně jako skupina
Kroky implementace
- Konfigurace clusteru Windows Server Failover Clustering (WSFC) nebo Linux Pacemaker
- Povolit funkci Skupiny dostupnosti Always On na všech SQL Server instance
- Zajistěte, aby databáze používaly model úplné obnovy a měly úplné zálohy.
- Vytvořte koncové body zrcadlení databáze na každé replice
- Vytvoření skupiny dostupnosti a přidání databází
- Konfigurace primárních a sekundárních replik s požadovanými režimy
- Vytvoření a konfigurace listeneru skupiny dostupnosti
- Konfigurace směrování pouze pro čtení, pokud používáte čitelné sekundární servery
- Otestujte procedury failoveru a ověřte připojení aplikace
nejlepší
- Kritické databáze vyžadující maximální provozuschopnost
- Organizace, které potřebují lokální vysokou dostupnost (HA) i geografické DR
- Prostředí vyžadující možnosti škálování čtení
- Aplikace, které těží z odlehčení dotazů na reporty
- Databáze vyžadující ochranu proti nulové ztrátě dat
- Multidatabázové aplikace vyžadující koordinované failovery
Klady
- Nulová ztráta dat díky režimu synchronního potvrzování
- Automatické přepnutí při selhání minimalizuje prostoje (obvykle sekundy)
- Čitelné sekundární vlákna snižují zátěž primárního vlákna
- Bez požadavku na sdílené úložiště
- Podporuje platformy Windows i Linux
- Geografické rozložení pro zotavení z havárie
- Záložní operace lze přesunout na sekundární servery.
- Řetězce připojení aplikace zůstávají po převzetí služeb beze změny.
Nevýhody
- Pro plnou funkčnost je vyžadována Enterprise Edition
- Standardní edice omezená na Basic AG (1 databáze, 1 sekundární databáze, žádná čitelná sekundární databáze)
- Komplexní konfigurace a správa
- Vyžaduje clusterovací infrastrukturu (WSFC nebo Pacemaker).
- Objekty na úrovni instance (přihlášení, úlohy) vyžadují ruční synchronizaci.
- Synchronní režim může způsobit latenci transakcí.
- Licenční costpro více serverů
Reference
- SQL Server Skupiny dostupnosti Always On: Kompletní průvodce
- Oficiální dokument společnosti Microsoft: Přehled skupin dostupnosti Always On (SQL Server)
4. Uzavřené skupiny dostupnosti
Uzavřené skupiny dostupnosti, zavedené v SQL Server 2022 rozšiřují tradiční skupiny dostupnosti Always On automatickou synchronizací objektů na úrovni instance napříč replikami, čímž eliminují potřebu ruční replikace přihlášení, úloh a dalších objektů na úrovni serveru.
KLÍČOVÉ VLASTNOSTI
- Automatická synchronizace objektů na úrovni instance (přihlášení, uživatelé, role)
- SQL Server Úlohy agentů replikované napříč všemi replikami
- Oprávnění databáze se synchronizují automaticky
- Všechny funkce Always On AG jsou zahrnuty
- Zjednodušené failover s kompletní replikací prostředí
- Podpora pro platformy Windows i Linux
Kroky implementace
- Zajistit SQL Server 2022 nebo později ve všech případech
- Konfigurace infrastruktury clusteru WSFC nebo Pacemaker
- Povolit funkci Vždy zapnuto ve všech instancích
- Vytvořit uzavřenou skupinu dostupnosti s možností CONTAINED
- Přidat databáze do obsažené AG
- Vytváření přihlašovacích údajů a úloh v kontextu AG
- Konfigurace listeneru a testování failoveru
nejlepší
- Organizace, které chtějí zjednodušenou administrativu AG
- Prostředí s častým testováním nebo provozem failoveru
- Aplikace vyžadující mnoho objektů na úrovni instance
- Nový SQL Server Nasazení v roce 2022 a více
- Týmy usilující o snížení cenyost-konfigurace failoveru
Klady
- Eliminuje ruční synchronizaci přihlášení a úloh
- Rychlejší a spolehlivější failover
- Snížená administrativní režie
- Aplikace fungují ihned po failoveru
- Zjednodušené postupy pro zotavení po havárii
- Všechny tradiční výhody AG jsou zahrnuty
Nevýhody
- Vyžaduje SQL Server 2022 nebo novější
- Pro plnou funkčnost je vyžadována Enterprise Edition
- Nelze převést stávající tradiční AG na uzavřené AG.
- Všechny repliky musí podporovat funkci obsažené AG.
- Vyšší složitost ve srovnání s tradičními AG
Reference
5. Distribuované skupiny dostupnosti
Distribuované skupiny dostupnosti, představené v SQL Server 2016 umožňují architekturu „skupin dostupnosti skupin dostupnosti“, která propojuje dvě nezávislé skupiny dostupnosti napříč samostatnými clustery pro pokročilé scénáře obnovy po havárii a migrace.
KLÍČOVÉ VLASTNOSTI
- Propojuje dvě nezávislé skupiny dostupnosti
- Každá AG si udržuje svůj vlastní nezávislý cluster.
- Podpora napříč platformami (Windows až Linux)
- Replikace mezi clustery bez sdíleného členství v clusteru
- Jeden AG slouží jako primární, druhý jako sekundární
- Podporuje synchronní i asynchronní režimy
- Geografické rozšíření napříč regiony nebo kontinenty
Kroky implementace
- Vytvoření a konfigurace první skupiny dostupnosti (primární DAG)
- Vytvoření a konfigurace druhé skupiny dostupnosti (sekundární DAG)
- Vytvořte distribuovanou AG propojující obě AG
- Konfigurace synchronizace dat mezi AG
- Nastavení listeneru na každé AG pro připojení aplikací
- Konfigurace zásad pro failover a testovacích postupů
- Ověření komunikace a replikace mezi clustery
nejlepší
- Obnova po havárii ve více regionech zahrnující nezávislá datová centra
- Migrace mezi platformami z Windows na Linux a naopak
- Hybridní cloudové scénáře propojující místní prostředí s Azure
- Aktualizace hlavních verzí vyžadující prodloužené migrační časy
- Organizace s více nezávislými failover clustery
- Globální podniky potřebují replikaci napříč kontinenty
Klady
- Odděluje závislosti clusterů mezi weby
- Umožňuje skutečné geografické rozložení
- Podporuje multiplatformní scénáře
- Každá AG se může přepnout na záložní systém nezávisle
- Ideální pro komplexní migrační projekty
- Není vyžadována žádná sdílená infrastruktura clusteru
- Může zahrnovat různé domény Windows nebo distribuce Linuxu
Nevýhody
- Vyžaduje Enterprise Edition
- Vysoká složitost konfigurace a správy
- Vyžaduje hlubokou znalost technologií clusteringu i AG.
- Obtížnější řešení problémů než u standardních AG
- Dodatečná latence pro scénáře napříč regiony
- Vyžaduje pečlivé plánování procedur pro přepnutí na záložní systém
Reference
6. Instance failover clusteru (FCI)
Instance failover clusteru poskytují vysokou dostupnost na úrovni instance pomocí sdíleného úložiště a failover clusteru systému Windows Server, což umožňuje automatické failover celého systému. SQL Server instance zahrnující všechny databáze a objekty na úrovni serveru.
KLÍČOVÉ VLASTNOSTI
- Ochrana na úrovni instance (všechny databáze selhávají společně)
- Aktivně-pasivní konfigurace se sdíleným úložištěm
- Název virtuální sítě (VNN) pro transparentní failover
- Automatické přepnutí na záložní systém při selhání aktivního uzlu
- Nulová ztráta dat (jedna kopie dat)
- Objekty na úrovni serveru zahrnuty (přihlášení, úlohy, propojené servery)
- Podporuje všechny SQL Server modely obnovy
Kroky implementace
- Konfigurace clusteru Windows Server Failover (WSFC)
- Nastavení sdíleného úložiště (SAN, SMB, Storage Spaces Direct)
- Konfigurace nastavení kvora clusteru
- instalovat SQL Server jako instance clusteru s podporou převzetí služeb při selhání na prvním uzlu
- Přidání dalších uzlů do FCI
- Konfigurace názvu a IP adresy virtuální sítě
- Testování failoveru mezi uzly clusteru
- Konfigurace klientských aplikací pro použití VNN
nejlepší
- Organizace se stávající infrastrukturou sdíleného úložiště
- Prostředí vyžadující ochranu na úrovni instance
- Lokální vysoká dostupnost v rámci jednoho datového centra
- Aplikace vyžadující společné selhání všech databází
- Scénáře, kde je nutné chránit objekty na úrovni serveru
- Prostředí pouze pro Windows (Linux není pro FCI podporován)
Klady
- Kompletní ochrana na úrovni instance
- Garance nulové ztráty dat
- Funkce automatického přepnutí na záložní systém
- Není třeba synchronizovat přihlašovací údaje ani úlohy
- Jedna kopie dat snižuje úložné kapacityosts
- Podporuje všechny modely obnovy
- Řetězce připojení aplikace nezměněny po převzetí služeb při selhání
Nevýhody
- Vyžaduje drahou infrastrukturu sdíleného úložiště
- Sdílené úložiště je jediným bodem selhání
- Žádná možnost škálování čtení (pouze jeden aktivní uzel)
- Omezené geografické rozšíření kvůli omezením úložiště
- Standardní edice omezena na 2 uzly
- Pouze pro Windows (bez podpory pro Linux)
- Delší doba přepnutí při selhání ve srovnání s AG (obvykle minuty)
- Komplexní konfigurace a správa úložiště
Reference
- SQL Server Failover Cluster: Kompletní průvodce pro DBA
- Oficiální dokument společnosti Microsoft: Instance clusteru Always On failover (SQL Server)
7. SQL Server replikace
SQL Server Replikace je technologie distribuce dat, která kopíruje a distribuuje data mezi více servery a podporuje různé topologie od jednoduché jednosměrné distribuce až po složité konfigurace s více mastery. Primárně se však používá spíše pro reporting než jako čistě vysoce dostupné řešení.
KLÍČOVÉ VLASTNOSTI
- Čtyři typy replikace: Snapshot, Transakční, Merge, Peer-to-Peer
- Výběr podrobných dat (konkrétní tabulky, sloupce, řádky)
- Podpora pro více odběratelů od jednoho vydavatele
- K dispozici jsou obousměrné a multimaster topologie
- Flexibilní možnosti plánování a synchronizace
- Řešení konfliktů pro slučovací replikaci
- Možnosti filtrování s predikáty WHERE
Kroky implementace
- Konfigurace distribučního serveru (může být samostatný nebo stejný jako vydavatel)
- Vytvořit publikaci v databázi Publisher
- Vyberte typ replikace na základě požadavků
- Vyberte články (tabulky, zobrazení, uložené procedury) k replikaci
- V případě potřeby nakonfigurujte filtrování a transformaci dat
- Nastavení databází odběratelů
- Vytváření odběrů (push nebo pull)
- Inicializace předplatného pomocí snímku
- Monitorování replikačních agentů a latence
nejlepší
- Distribuce dat na více serverů pro tvorbu sestav
- Scénáře škálování čtení s úlohami vytváření sestav
- Částečná distribuce dat na vzdálená pracoviště
- Konsolidace dat z více zdrojů
- Občas propojené scénáře (replikace sloučením)
- Podpůrná role ve strategii obnovy po havárii
Klady
- Granulární kontrola nad replikovanými daty
- Podpora více odběratelů
- Flexibilní možnosti topologie
- Může replikovat konkrétní tabulky nebo sloupce
- Filtrování snižuje síťový provoz
- Podporuje heterogenní replikaci (SQL Server na Oracle)
- Funguje se standardní edicí
Nevýhody
- Žádná funkce automatického přepnutí na záložní systém
- Komplexní konfigurace a správa
- Potenciál konfliktů replikace (slučování a peer-to-peer)
- Latence při synchronizaci dat
- Změny schématu vyžadují pečlivou koordinaci
- Není navrženo jako primární řešení HA
- Řešení problémů může být náročné
- Peer-to-Peer vyžaduje Enterprise Edition
Reference
- SQL Server Replikace: Kompletní průvodce pro správce databází
- Oficiální dokument společnosti Microsoft: SQL Server replikace
8. Přeprava klád
Log Shipping poskytuje řešení pro zotavení z havárie v teplém pohotovostním režimu a vysokou dostupnost prostřednictvím automatizovaných procesů zálohování, kopírování a obnovy transakčních protokolů, což nabízí jednoduché a cost-efektivní přístup k údržbě synchronizovaných sekundárních databází.
KLÍČOVÉ VLASTNOSTI
- Automatizované úlohy zálohování, kopírování a obnovy pomocí SQL Agenta
- Podpora více sekundárních serverů
- Konfigurovatelné intervaly zálohování a obnovy
- POHOTOVOSTNÍ režim umožňuje přístup pouze pro čtení k sekundárním
- Zpožděná obnova protokolu pro ochranu před chybami
- Monitorovací server pro centralizované monitorování
- Podpora komprese transakčních protokolů
Kroky implementace
- Zajistěte, aby primární databáze používala model úplné obnovy.
- Vytvořit úplnou zálohu primární databáze
- Obnovení zálohy na sekundárním serveru pomocí NORECOVERY
- Konfigurace odesílání protokolů v primární databázi
- Určete sdílenou složku záloh, která bude přístupná všem serverům
- Konfigurace plánu úloh zálohování na primárním serveru
- Konfigurace úloh kopírování a obnovy na sekundární
- Volitelně konfigurovat monitorovací server
- Testovací postupy pro failover
nejlepší
- Cost- efektivní řešení pro obnovu po havárii
- Organizace s licencí Standard Edition
- Scénáře tolerující minuty ztráty dat
- Prostředí s manuálním přepnutím na záložní systém
- Zpožděná obnova z důvodu ochrany před chybami
- Hlášení úloh pomocí pohotovostního režimu
- Jednoduché požadavky na DR bez složité infrastruktury
Klady
- Jednoduchá konfigurace a ovládání
- Nízké cost (Podpora standardní edice)
- Podpora více sekundárních serverů
- Konfigurovatelné zpoždění chrání před logickými chybami
- Hlášení pouze pro čtení v pohotovostním režimu
- Toleruje vysokou síťovou latenci
- Minimální dopad na primární server
- Osvědčená a zavedená technologie
Nevýhody
- Žádná funkce automatického přepnutí na záložní systém
- Nutná konfigurace zvlášť pro každou databázi
- Zpoždění synchronizace (minuty až hodiny)
- Potenciální ztráta dat na základě intervalu zálohování
- Ruční failover zvyšuje RTO
- Vyžaduje SQL Server Agent spuštěný na všech serverech
- Sekundární databáze nejsou během obnovy protokolů přístupné.
- Aplikace vyžadují změny připojovacího řetězce po failoveru
Reference
- SQL Server Doprava protokolů: Kompletní průvodce pro správce databází
- Oficiální dokument společnosti Microsoft: O odesílání protokolů (SQL Server)
9. Zrcadlení databáze
Zrcadlení databáze je zastaralé řešení vysoké dostupnosti na úrovni databáze, které od té doby neprošlo žádnými vylepšeními. SQL Server 2012, ačkoli je stále k dispozici v aktuálních verzích. Společnost Microsoft důrazně doporučuje migraci na skupiny dostupnosti Always On pro všechna nová nasazení.
KLÍČOVÉ VLASTNOSTI
- Architektura hlavního a zrcadlového serveru
- Volitelný server svědků pro automatické přepnutí služeb při selhání
- Dva provozní režimy: Vysoká bezpečnost a Vysoký výkon
- Podpora synchronního a asynchronního provozu
- Možnost automatické opravy stránek
- Ochrana na úrovni databáze
- Podpora šifrování pro přenos dat
Kroky implementace
- Zajistěte, aby databáze používala model úplné obnovy.
- Vytvořte úplnou zálohu a obnovení na zrcadlový server pomocí NORECOVERY
- Vytvoření zrcadlených koncových bodů na principu a zrcadle
- Konfigurace certifikátů pro ověřování
- Navázání zrcadlení mezi servery
- Volitelně nakonfigurujte server svědka pro automatické přepnutí služeb při selhání
- Nastavení provozního režimu (Vysoká bezpečnost nebo Vysoký výkon)
- Testovací postupy pro failover
nejlepší
- Starší systémy, které již používají zrcadlení databáze
- Zachování stávajících konfigurací, dokud nebude možná migrace
- Žádné další doporučené scénáře (funkce je zastaralá)
Klady
- Rychlé automatické přepnutí na záložní systém v režimu vysoké bezpečnosti se svědkem
- Nulová ztráta dat v režimu vysoké bezpečnosti
- Automatická oprava stránek od partnera
- Jednodušší než skupiny dostupnosti pro jednu databázi
- Podporuje šifrování pro přenos
- Postupné upgrady s minimálními prostoji
Nevýhody
- Zastaralé od SQL Server 2012 (může být odstraněno)
- Konfigurace a failover pro jednotlivé databáze
- Žádné čitelné zrcadlo (bez možnosti čtení v měřítku)
- Každá databáze selháním převezme nezávisle
- Aktualizace připojovacího řetězce vyžadované po převzetí služeb při selhání
- Omezeno na dva servery (hlavní a zrcadlový)
- Žádná vylepšení ani nové funkce
- Společnost Microsoft doporučuje migraci na systém Always On AG.
Reference
10. Propojení spravované instance
Propojení spravované instance vytváří hybridní připojení mezi SQL Server a spravovanou instanci Azure SQL s využitím technologie distribuovaných skupin dostupnosti, což umožňuje replikaci dat téměř v reálném čase pro scénáře zotavení po havárii, migrace a integrace do cloudu.
KLÍČOVÉ VLASTNOSTI
- Replikace téměř v reálném čase s využitím technologie distribuované AG
- Jednosměrná replikace (SQL Server 2016–2019 do Azure)
- Obousměrná replikace s failbackem (SQL Server 2022 +)
- Jedna databáze na odkaz (podporováno více odkazů)
- Čitelné repliky ve spravované instanci Azure SQL
- Možnost pasivní replikace DR bez licence
- Online migrace s minimálními prostoji
Kroky implementace
- Připravit SQL Server prostředí (VPN nebo ExpressRoute do Azure)
- Konfigurace spravované instance Azure SQL
- Povolit funkci Always On AG SQL Server
- Vytvoření koncového bodu zrcadlení databáze
- Výměna certifikátů mezi SQL Server a MI
- Vytvoření propojení spravované instance pomocí SSMS nebo skriptů
- Ověření replikace a synchronizace
- Nakonfigurujte směrování pouze pro čtení, pokud jej používáte pro škálování čtení.
- Testovací postupy pro failover
nejlepší
- Hybridní zotavení z havárie s cloudovým sekundárním úložištěm
- Online migrace do spravované instance Azure SQL
- Přesun analytických nástrojů a reportů do Azure
- Organizace zavádějící hybridní cloudovou strategii
- Scénáře vyžadující integraci služeb Azure
- Cost optimalizace s bezlicenčním pasivním DR
Klady
- Most výkonná migrace do Azure s minimálními prostoji
- Skutečná online migrace na úroveň Business Critical
- Obousměrné failover s SQL Server 2022+
- Pasivní replika DR bez licence snižuje costs
- Integrace se službami Azure bez úplné migrace
- Možnost škálování čtení pomocí replik Azure
- Automatizované zálohy na straně Azure
- Geografické rozšíření do regionů Azure
Nevýhody
- Omezení jedné databáze na odkaz
- Nelze použít se skupinami pro převzetí služeb při selhání na MI
- Systémové databáze nebyly replikovány
- Objekty na úrovni instance vyžadují ruční synchronizaci.
- SQL Server 2016–2019 pouze jednosměrný provoz (bez záložního systému)
- Azure costs pro spravovanou instanci
- Požadavky na síťové připojení (VPN/ExpressRoute)
- Omezení funkcí (tabulky souborů, datové proudy souborů nejsou podporovány)
Reference
11. Porovnání řešení s vysokou dostupností
11.1 Tabulka porovnání funkcí
| vlastnost | Vždy na AG | Obsažené AG | Distribuovaná AG | FCI | replikace | Přeprava klád | Zrcadlení | MI Link |
|---|---|---|---|---|---|---|---|---|
| vydání | Ent/Std | Ent/Std | Ent | Ent/Std | Ent/Std | Ent/Std | Ent/Std | Ent/Std |
| Protection Level | Databáze | Databáze+Instance | Databáze | Instance | Databáze/Objekty | Databáze | Databáze | Databáze |
| Synchronizace dat | Synchronizace/asynchronizace | Synchronizace/asynchronizace | Synchronizace/asynchronizace | Společná | Async | Async | Synchronizace/asynchronizace | Async |
| Automatické přepnutí při selhání | Ano | Ano | Ano | Ano | Ne | Ne | Ano | Ne |
| Měřítko čtení | Ano | Ano | Ano | Ne | Ano | Omezený | Ne | Ano |
| RTO | Sekundy | Sekundy | Sekundy | Minuty | Manuál | Manuál | Sekundy | Manuál |
| RPO | Nula/min | Nula/min | Nula/min | Nulu | Minimální | Minuty | Nula/min | Minimální |
| Stav podpory | Aktivní | Aktivní | Aktivní | Aktivní | Aktivní | Aktivní | Zastaralé | Aktivní |
11.2 Výběr řešení HA
Při výběru řešení zvažte následující faktory:
- Rozpočtové aspekty významně ovlivňují výběr řešení: Požadavky na edici Enterprise ovlivňují licencováníosts, zatímco potřeby infrastruktury se liší od drahého sdíleného úložiště pro FCI až po komoditní servery pro skupiny dostupnosti.
- Složitost se podstatně liší: Doprava protokolů nabízí nejjednodušší implementaci, zatímco distribuované skupiny dostupnosti vyžadují rozsáhlé odborné znalosti.
- Požadavky RTO ovlivňují výběr technologií. Vyžadují sekundy prostojů. Skupiny dostupnosti Always On nebo FCI s automatickým přepnutím při selhání. Tolerance minut umožňuje ruční přepnutí při selhání, jako je například odesílání protokolů.
- Požadavky na RPO jsou stejně důležité: nulová ztráta dat vyžaduje synchronní řešení, zatímco tolerance v minutách umožňuje odesílání protokolů.
- Omezení infrastruktury, potřeby škálování čtení, požadavky na geografické rozložení a hybridní cloudové scénáře – to vše ovlivňuje optimální výběr řešení.
12. Nejlepší postupy pro SQL Server Vysoká dostupnost
12.1 Plánování a návrh
Posuďte obchodní požadavky pečlivou analýzou RTO a RPO pro každou databázi. Vyberte vhodná řešení odpovídající požadavkům, spíše než se řídit výchozími hodnotami.ost sofistikované možnosti. Naplánujte lokální vysokou dostupnost i geografickou obnovu po havárii s využitím vícevrstvých přístupů. Komplexně zdokumentujte architekturu včetně síťových diagramů, procedur pro převzetí služeb při selhání a runbooků pro obnovu.
12.2 Implementační pokyny
Pravidelně testujte postupy failoveru prostřednictvím plánovaných testů a simulovaných selhání pro ověření SQL Server řešení s vysokou dostupností a připravenost týmu. Neustále monitorujte stav a výkon pomocí SQL Servervestavěné nástroje jako SQL Server profil a DMV. Nakonfigurujte komplexní upozornění na zpoždění synchronizace, události přepnutí při selhání a zhoršení stavu. Udržujte SQL Server zálohovací strategie i přes implementaci HA, protože zálohy zůstávají poslední linií obrany proti logickému poškození a nechtěnému smazání. Udržujte systémy aktuální pomocí kumulativních aktualizací, bezpečnostních záplat a aktualizací firmwaru. Pravidelně ověřujte postupy obnovy prostřednictvím skutečných obnov a testování aplikací a znajte, jak řešit scénáře, jako je databáze uvízlé v režimu obnovy.
12.3 Monitorování a údržba
Používejte nástroje jako SQL Server Activity Monitor, SQL Server Performance Monitora dynamické pohledy pro správu rozsáhle pro monitorování stavu a spouštění DBCC CHECKDB pravidelně ověřujte integritu databáze. Využijte řídicí panel Always On Dashboard pro vizuální posouzení stavu skupin dostupnosti. Pečlivě sledujte zpoždění synchronizace, zejména u asynchronních replik a odesílání protokolů. Pečlivě sledujte události přepnutí při selhání pomocí SQL Server Rozšířené události a analyzovat příčiny daných vzorců. Stanovit základní hodnoty výkonu pro běžný provoz a sledovat odchylky, které naznačují potenciální problémy. Provádět pravidelné kontroly plánování kapacity a zajistit, aby infrastruktura podporovala rostoucí pracovní zátěž.
13. Nejčastější dotazy
Otázka: Jaký je rozdíl mezi vysokou dostupností a obnovou po havárii v SQL Server?
A: Vysoká dostupnost minimalizuje prostoje způsobené lokálními selháními v datovém centru, obvykle s automatickým failoverem a RTO během několika sekund nebo minut. Obnova po havárii chrání před regionálními katastrofami, obvykle s manuálním failoverem a delšími RTO, ale zahrnuje události ovlivňující celá zařízení.
Otázka: Jaký je rozdíl mezi řešeními s vysokou dostupností (HA) a řešeními s možností škálování čtení?
A: Řešení s vysokou dostupností zajišťují, že databáze zůstanou přístupné i během selhání, se zaměřením na provozuschopnost a automatické funkce failoveru. Řešení Read-Scale zlepšují výkon dotazů distribucí úloh pouze pro čtení mezi více replik databází se zaměřením na propustnost a doby odezvy. I když tyto řešení slouží různým účelům, stejná technologie, jako jsou skupiny dostupnosti Always On, může poskytnout obě výhody současně: čitelné sekundární repliky nabízejí funkce škálování pro čtení a zároveň slouží jako funkce failoveru. tarzískává pro vysokou dostupnost.
Q: Které SQL Server Je řešení s vysokou dostupností nejlepší pro mé potřeby?
A: Nejlepší řešení závisí na RTO a RPO. tarzískává, rozpočet, dostupnost edice, infrastrukturu a odborné znalosti. Skupiny dostupnosti Always On vyhovují most podnikové scénáře, zatímco odesílání protokolů funguje dobře pro cost-citlivá prostředí. Vyhodnoťte požadavky podle srovnávací tabulky.
Otázka: Vyžadují skupiny dostupnosti Always On Enterprise Edition?
A: Standard Edition podporuje základní skupiny dostupnosti s významnými omezeními: jedna databáze na skupinu, jedna sekundární replika a žádná čitelná sekundární databáze. Plná funkčnost včetně více databází, osmi sekundárních databází a čitelných replik vyžaduje Enterprise Edition.
Otázka: Mohu použít službu Log Shipping s SQL Server Standardní edice?
A: Ano, přeprava protokolů je ve Standardní verzi plně podporována, což z ní činí atraktivní možnost.ost-efektivní řešení pro zotavení po havárii pro organizace bez licence Enterprise Edition.
Otázka: Jaký je rozdíl mezi skupinami dostupnosti Always On a zrcadlením databáze?
A: Zrcadlení databáze je zastaralé a funguje na úrovni jednotlivých databází bez čitelného sekundárního přístupu. Skupiny dostupnosti Always On podporují skupiny databází, až osm sekundárních databází, čitelné repliky a vylepšené monitorování. Společnost Microsoft doporučuje migraci na Always On.
Otázka: Jak si mohu vybrat mezi instancemi clusteru s podporou převzetí služeb při selhání a skupinami dostupnosti?
A: Pro ochranu na úrovni instancí se sdílenou úložnou infrastrukturou zvolte FCI. Pro ochranu na úrovni databáze, možnosti škálování pro čtení a geografickou distribuci bez sdíleného úložiště zvolte skupiny dostupnosti. Organizace často kombinují obojí pro komplexní ochranu.
Otázka: Mohu kombinovat více SQL Server řešení s vysokou dostupností?
A: Ano, kombinování řešení je běžné. FCI mohou sloužit jako repliky skupin dostupnosti a poskytovat lokální vysokou dostupnost na úrovni instance a geografické pohotovostní zabezpečení na úrovni databáze. Dodávání protokolů může doplňovat skupiny dostupnosti pro dodatečnou vzdálenou ochranu. Kombinované konfigurace důkladně otestujte.
Otázka: Jaký je rozdíl mezi synchronní a asynchronní replikací?
A: Synchronní replikace čeká na sekundární potvrzení před potvrzením, což zaručuje nulovou ztrátu dat, ale potenciálně způsobuje latenci. Asynchronní replikace probíhá bez čekání, optimalizuje výkon, ale vytváří možnost ztráty dat během failoveru.
Otázka: Potřebuji stále zálohy, pokud mám SQL Server Je nakonfigurována vysoká dostupnost?
A: Rozhodně ano. Vysoká dostupnost chrání před selháním hardwaru, ale nemůže ochránit před logickým poškozením, náhodným smazáním nebo škodlivými akcemi, které se replikují do všech kopií. Zálohy zůstávají nezbytné pro obnovu v daném okamžiku a pro dodržování předpisů.
Otázka: Potřebuji stále zálohy, pokud mám SQL Server Je nakonfigurována vysoká dostupnost?
A: Rozhodně ano. Vysoká dostupnost chrání před selháním hardwaru, ale nemůže ochránit před poškozením databáze, náhodným smazáním nebo škodlivými akcemi. Zálohy zůstávají nezbytné pro obnovu v daném okamžiku a pro dodržování předpisů. V případech, kdy dojde k poškození souborů databáze a zálohy nejsou k dispozici nebo jsou také poškozeny, je třeba použít specializované Software pro opravu SQL databáze může pomoci obnovit data z poškozených MDF, NDF a záložních souborů.
Otázka: Co je to uzavřená skupina dostupnosti a jak se liší od běžné skupiny dostupnosti?
A: Uzavřené skupiny dostupnosti, zavedené v SQL Server 2022 automaticky synchronizuje objekty na úrovni instance, jako jsou přihlašovací údaje, úlohy a metadata. Běžné skupiny dostupnosti synchronizují pouze objekty databáze, což vyžaduje ruční replikaci objektů instance.
Otázka: Mohu replikovat data z SQL Server do spravované instance Azure SQL?
A: Ano, Managed Instance Link poskytuje hybridní replikaci mezi SQL Server a Azure. SQL Server 2016-2019 podporuje jednosměrnou replikaci, zatímco SQL Server Verze 2022+ umožňuje obousměrnou replikaci s funkcí failback pro zotavení po havárii, migraci a hybridní scénáře.
Otázka: Co se stane s SQL Server Úlohy agenta během failoveru?
A: U tradičních skupin dostupnosti je nutné úlohy na sekundárních replikách vytvářet ručně. Obsažené skupiny dostupnosti (SQL Server 2022+) automaticky synchronizují úlohy. Instance clusteru s podporou převzetí služeb při selhání zahrnují úlohy jako součást ochrany na úrovni instance.
14. závěr
SQL Server poskytuje komplexní řešení s vysokou dostupností, která splňují rozmanité požadavky od databází jednotlivých oddělení až po kritické podnikové systémy. Každé řešení nabízí specifické funkce a kompromisy, které musí správci databází znát, aby se mohli informovaně rozhodovat.
Skupiny dostupnosti Always On představují vlajkovou loď technologií pro moderní nasazení, přičemž skupiny dostupnosti Contained Availability Groups zjednodušují správu a distribuované skupiny dostupnosti umožňují sofistikované scénáře napříč platformami. Instance clusteru s podporou převzetí služeb při selhání nadále slouží potřebám ochrany na úrovni instancí, zatímco odesílání protokolů zůstává relevantní pro…ost-citlivé scénáře. Propojení spravovaných instancí otevírá možnosti hybridního cloudu propojením s místními prostředími. SQL Server s Azure.
Přizpůsobení řešení specifickým obchodním potřebám představuje kritický faktor úspěchu. Neexistuje univerzální přístup. Organizace musí pečlivě vyhodnotit požadavky na RTO a RPO, rozpočtová omezení, možnosti infrastruktury a administrativní odbornost. Nejlepší architektura často kombinuje více řešení pro komplexní ochranu. Zvažte, jak vaše strategie HA odpovídá širším plánům na přijetí cloudu, a podrobné pokyny k implementaci naleznete v specializovaných článcích, abyste zajistili, že vaše SQL Server infrastruktura poskytuje spolehlivost, kterou vaše podnikání vyžaduje.
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ů.