Provozní kontinuita a obnovení databáze – SQL Server

platí pro: SQL Server 2016 (13.x) a novější verze

Tento článek obsahuje přehled řešení provozní kontinuity pro zajištění vysoké dostupnosti a zotavení po havárii na SQL Serveru ve Windows a Linuxu.

Každý, kdo nasadí SQL Server, musí zajistit, aby všechny důležité instance SQL Serveru a databáze v nich byly k dispozici, když je firma a koncoví uživatelé potřebují, ať už je tato dostupnost v pravidelných pracovních hodinách nebo nepřetržitě. Cílem je udržet firmu v provozu s minimálním nebo žádným přerušením. Tento koncept se také označuje jako kontinuita podnikových procesů.

SQL Server 2017 (14.x) a novější verze zavedly funkce a vylepšení pro dostupnost. Největší přidání je podpora SQL Serveru v linuxových distribucích. Úplný seznam nových funkcí sql Serveru najdete v následujících článcích:

Version	Operační systém
Novinky v SQL Serveru 2025 (17.x)	Windows | Linux
Novinky v SQL Serveru 2022 (16.x)	Windows | Linux
Novinky v SQL Serveru 2019 (15.x)	Windows | Linux
Novinky v SQL Serveru 2017 (14.x)	Windows | Linux

Tento článek se zaměřuje na scénáře dostupnosti v SQL Serveru 2017 (14.x) a novějších verzích a také na nové a vylepšené funkce dostupnosti. Mezi scénáře patří hybridní scénáře, které mohou zahrnovat nasazení SQL Serveru na Windows Serveru i Linuxu, a scénáře, které můžou zvýšit počet čitelných kopií databáze.

I když tento článek nepokrývá možnosti dostupnosti externí pro SQL Server (například virtualizaci), všechno, co je zde popsáno, platí pro instalace SQL Serveru uvnitř hostovaného virtuálního počítače, ať už ve veřejném cloudu nebo hostovaném místním serverem hypervisoru.

Scénáře SQL Serveru, které používají funkce dostupnosti

Skupiny dostupnosti AlwaysOn, instance clusteru s podporou převzetí služeb při selhání a přesouvání protokolů můžete používat různými způsoby, nejen pro dostupnost. Funkce dostupnosti můžete používat čtyřmi hlavními způsoby:

• Vysoká dostupnost
• Zotavení po havárii
• Migrace a upgrady
• Horizontální navýšení kapacity čitelných kopií jedné nebo více databází

Následující části popisují relevantní funkce pro jednotlivé scénáře. Jednou z funkcí, které nejsou pokryté, je replikace SQL Serveru. I když replikace SQL Serveru není oficiálně označena jako funkce dostupnosti v rámci deštníku Always On, často se používá pro zajištění redundance dat v určitých scénářích. Replikace sloučení není pro SQL Server v Linuxu podporovaná. Další informace najdete v tématu Replikace SQL Serveru v Linuxu.

Důležité

Funkce dostupnosti SQL Serveru nenahrazuje požadavek na robustní, dobře otestovanou strategii zálohování a obnovení. Strategie zálohování a obnovení je nejzákladnější stavební blok jakéhokoli řešení dostupnosti.

Vysoká dostupnost

Je důležité zajistit, aby instance nebo databáze SQL Serveru byly k dispozici, pokud dojde k problému, který je místní pro datové centrum nebo jednu oblast v cloudu. Tato část vysvětluje, jak vám můžou pomoct funkce dostupnosti SQL Serveru. Všechny popsané funkce jsou k dispozici na Windows Serveru i v Linuxu.

Skupiny dostupnosti

Skupiny dostupnosti (AG) poskytují ochranu na úrovni databáze odesláním každé transakce databáze do jiné instance nebo repliky, která obsahuje kopii této databáze ve speciálním stavu. Skupinu dostupnosti (AG) můžete nasadit v edicích Standard nebo Enterprise. Instance, které se účastní skupiny dostupnosti, můžou být buď samostatné instance, nebo instance clusteru s podporou převzetí služeb při selhání (FCI, popsané v další části). Vzhledem k tomu, že se transakce odesílají do repliky, doporučují se skupiny dostupnosti (AGs) tam, kde jsou požadavky na nižší cíle bodu obnovení a času obnovení. Přesun dat mezi replikami může být synchronní nebo asynchronní a edice Enterprise umožňuje mít až tři repliky (včetně primární) jako synchronní. Skupina dostupnosti obsahuje jednu plně čitelnou/zapisovatelnou kopii databáze, která je na primární replice, zatímco všechny sekundární repliky nemohou přijímat transakce přímo od koncových uživatelů nebo aplikací.

Poznámka:

AlwaysOn je zastřešující termín pro funkce dostupnosti v SQL Serveru a zahrnuje skupiny AG i FCI. Funkce AlwaysOn není název funkce skupiny dostupnosti.

Před SQL Serverem 2022 (16.x) skupiny dostupnosti zajišťovaly ochranu pouze na úrovni databáze, nikoli ochranu na úrovni instance. Pro každou sekundární repliku se musí ručně synchronizovat všechno, co není zachyceno v transakčním protokolu nebo nakonfigurované v databázi. Některé příklady objektů, které je potřeba synchronizovat ručně, jsou přihlášení na úrovni instance, propojených serverů a úloh agenta SQL Serveru.

V SYSTÉMU SQL Server 2022 (16.x) a novějších verzích můžete kromě úrovně instance spravovat objekty metadat, včetně uživatelů, přihlášení, oprávnění a úloh agenta SQL Serveru. Další informace najdete v tématu Co je obsažená skupina dostupnosti?

Skupina dostupnosti má také další komponentu označovanou jako naslouchací proces, který umožňuje aplikacím a koncovým uživatelům připojit se, aniž by museli vědět, která instance SQL Serveru je hostitelem primární repliky. Každá skupina dostupnosti má vlastní naslouchací komponentu. I když se implementace naslouchacího procesu mírně liší ve Windows Serveru oproti Linuxu, poskytují stejné funkce i použitelnost. Diagram znázorňuje skupinu dostupnosti (AG) založenou na Windows Serveru, která používá cluster Windows Server pro převzetí služeb při selhání (WSFC). Základní cluster ve vrstvě operačního systému se vyžaduje pro dostupnost bez ohledu na to, jestli je v Linuxu nebo Windows Serveru. Příklad ukazuje jednoduchou konfiguraci se dvěma servery nebo uzly s WSFC jako základním clusterem.

Edice Standard a Enterprise mají různé limity pro repliky. Skupina dostupnosti v edici Standard, označovaná jako základní skupina dostupnosti, podporuje dvě repliky (jednu primární a jednu sekundární) s jedinou databází ve skupině dostupnosti. Edice Enterprise umožňuje nejen konfigurovat několik databází v jedné skupině dostupnosti (Availability Group), ale také může obsahovat až devět replik celkem (jednu primární a osm sekundárních). Edice Enterprise také poskytuje další volitelné výhody, jako jsou čitelné sekundární repliky, možnost zálohování ze sekundární repliky a další.

Poznámka:

Zrcadlení databáze, které bylo zastaralé v SQL Serveru 2012 (11.x), není k dispozici ve verzi SQL Serveru s Linuxem ani není přidáno. Zákazníci, kteří stále používají zrcadlení databáze, by měli naplánovat migraci na skupiny AG, což je náhrada za zrcadlení databáze.

Pokud jde o dostupnost, můžou skupiny AG poskytovat automatické nebo ruční převzetí služeb při selhání. K automatickému převzetí služeb při selhání může dojít, pokud je nakonfigurované synchronní přesun dat a databáze v primární a sekundární replice je v synchronizovaném stavu. Pokud se používá naslouchací proces a aplikace používá podporovanou verzi rozhraní .NET Framework (3.5 s aktualizací Service Pack 1 nebo 4.6.2 a novější verze), převzetí služeb při selhání by mělo být zpracováno s minimálním až žádným účinkem na koncové uživatele, pokud se využívá naslouchací proces. Převzetí role na sekundární replikou, aby se stala novou primární replikou, lze nakonfigurovat jako automatické nebo ruční, a obvykle se měří v sekundách.

Následující seznam uvádí některé rozdíly mezi skupinami AG ve Windows Serveru a Linuxem:

Vzhledem ke způsobu, jakým základní cluster funguje na Linuxu a Windows Serveru, se všechna převzetí služeb při selhání AG (ruční nebo automatická) provádějí prostřednictvím clusteru na Linuxu. V nasazeních AG založených na Windows Serveru je potřeba provést ruční převzetí služeb při selhání prostřednictvím SQL Serveru. Automatické převzetí služeb při selhání zpracovává základní cluster na Windows Serveru i Linuxu.

• Pro SQL Server v Linuxu byste měli nakonfigurovat skupinu dostupnosti s minimálně třemi replikami, a to z důvodu fungování základního clusteringu.

• V Linuxu je běžný název používaný jednotlivými naslouchacími procesy definovaný v DNS a ne v clusteru, jako je na Windows Serveru.

SQL Server 2017 (14.x) zavedl následující funkce a vylepšení skupin dostupnosti:

• Typy clusterů
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Vylepšená podpora DTC (Microsoft Distributor Transaction Coordinator) pro konfigurace založené na Windows Serveru
• Další scénáře horizontálního navýšení kapacity pro databáze jen pro čtení (popsané dále v tomto článku)

Typy clusterů skupin dostupnosti

Integrovaná forma dostupnosti clusteringu ve Windows Serveru je povolena prostřednictvím funkce zvané Převzetí služeb při selhání. Umožňuje vytvořit WSFC, který se bude používat s AG nebo FCI. SQL Server dodává knihovny DLL prostředků pracující s clustery, které poskytují integraci skupin AG a FCI.

SQL Server v Linuxu podporuje více technologií clusteringu. Microsoft podporuje komponenty SQL Serveru, zatímco naši partneři podporují příslušnou technologii clusteringu. SQL Server na Linuxu například podporuje HPE Serviceguard a DH2i DxEnterprise jako řešení clusteru.

Cluster s podporou převzetí služeb při selhání se systémem Windows a řešení clusteru s Linuxem jsou více podobné než jiné. Oba poskytují způsob, jak přijímat jednotlivé servery a kombinovat je v konfiguraci, aby poskytovaly dostupnost, a mají koncepty věcí, jako jsou prostředky, omezení (i když jsou implementována odlišně), převzetí služeb při selhání atd.

Například pro podporu Pacemakeru pro konfigurace skupiny dostupnosti (AG) a FCI, včetně funkcí jako automatické převzetí služeb při selhání, poskytuje Microsoft mssql-server-ha balíček, který je podobný, ale ne úplně stejný jako knihovny DLL prostředků ve Windows Server Failover Clustering (WSFC) pro Pacemaker. Jedním z rozdílů mezi WSFC a Pacemaker je, že v Pacemakeru není žádný prostředek pro síťová jména, což je komponenta, která pomáhá zprostředkovat název posluchače (nebo název FCI) ve WSFC. Použijte DNS k překladu názvů v Linuxu.

Vzhledem k rozdílu v zásobníku clusteru musí skupiny AG v SQL Serveru 2017 (14.x) a novějších verzích zpracovávat některá metadata, která jsou nativně zpracována WSFC. Existují například tři typy clusterů pro skupinu dostupnosti, které jsou uloženy v sys.availability_groups ve cluster_type a cluster_type_desc sloupcích.

• WSFC
• Externí
• Žádné

Všechny AG, které potřebují vysokou dostupnost, musí používat základní cluster, což v případě SQL Server 2017 (14.x) a novější verze znamená WSFC nebo Linuxový clusteringový agent. Pro skupiny AG založené na Windows Serveru, které používají základní WSFC, je výchozí typ clusteru WSFC a nemusíte ho nastavovat. Pro Linuxové AG musíte při vytváření nastavit typ clusteru na "Externí". Integrace s externím clusterovým řešením v Linuxu se nakonfiguruje po vytvoření skupiny dostupnosti, zatímco ve WSFC se to provádí již při jejím vytváření.

Typ clusteru žádný se dá použít s AG skupinami na Windows Serveru i Linuxu. Nastavení typu clusteru na None znamená, že AG nevyžaduje základní cluster. To znamená, že SQL Server 2017 (14.x) je první verze SQL Serveru, která podporuje skupiny dostupnosti bez clusteru, ale nevýhodou je, že tato konfigurace není podporovaná jako řešení s vysokou dostupností.

Důležité

V SQL Serveru 2017 (14.x) a novějších verzích nemůžete po vytvoření skupiny dostupnosti změnit typ clusteru. Toto omezení znamená, že skupinu dostupnosti (AG) nelze přepnout z None na External nebo WSFC, a naopak.

Pokud chcete přidat jenom další kopie databáze jen pro čtení nebo pokud chcete, aby skupina dostupnosti poskytovala migraci a upgrady, ale nechcete se zabývat složitostí základního clusteru nebo dokonce replikací, zvažte nastavení skupiny dostupnosti s typem clusteru Žádné. Další informace najdete v částech Migrace a upgrady a škálování pro čtení.

Následující snímek obrazovky ukazuje podporu různých typů clusterů v aplikaci SQL Server Management Studio (SSMS). Musíte mít verzi 17.1 nebo novější. Následující snímek obrazovky pochází z verze 17.2:

POŽADOVANÉ_SOUPRAVENÉ_SEKUNDÁRY_K_POTVRZENÍ

SQL Server 2016 (13.x) zvýšil podporu počtu synchronních replik ze dvou na tři v edici Enterprise. Pokud je ale jedna sekundární replika synchronizovaná, ale druhá replika má problém, neexistuje způsob, jak řídit chování primárního serveru, aby buď čekal na špatnou repliku, nebo aby mohla pokračovat. V tomto scénáři může primární replika stále přijímat zápisové operace, i když sekundární replika není v synchronizovaném stavu, což vede ke ztrátě dat na sekundární replice.

V SQL Serveru 2017 (14.x) a novějších verzích můžete řídit chování toho, co se stane, když jsou synchronní repliky s REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Tato možnost funguje takto:

• Existují tři možné hodnoty: 0, 1a 2.
• Hodnota je počet sekundárních replik, které je nutné synchronizovat. To ovlivňuje ztrátu dat, dostupnost skupiny dostupnosti (AG) a převzetí služeb při selhání.
• Pro WSFCs a typ clusteru None je výchozí hodnota 0a můžete ji ručně nastavit na 1 nebo 2.
• U typu externího clusteru mechanismus clusteru ve výchozím nastavení nastaví tuto hodnotu a můžete ji přepsat ručně. Pro tři synchronní repliky je 1výchozí hodnota .

Na Linuxu nakonfigurujete hodnotu pro prostředek AG v clusteru. Ve Windows ho nastavíte prostřednictvím jazyka Transact-SQL.

Hodnota, která je vyšší, než 0 zajišťuje vyšší ochranu dat, protože pokud není k dispozici požadovaný počet sekundárních replik, primární není k dispozici, dokud se tato podmínka nevyřeší. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT také ovlivňuje chování převzetí služeb při selhání, protože automatické převzetí služeb při selhání nemůže proběhnout, pokud správný počet sekundárních replik není v odpovídajícím stavu. Na Linuxu hodnota 0 nepovoluje automatický failover, takže při použití synchronního režimu s automatickým failoverem na Linuxu musíte nastavit hodnotu vyšší než 0, aby se dosáhlo automatického failoveru. 0 ve Windows Serveru odpovídá chování SQL Serveru verzi 2016 (13.x) a starším verzím.

Vylepšená podpora koordinátoru distribuovaných transakcí Od Microsoftu

Před SQL Serverem 2016 (13.x) byl jediný způsob, jak získat dostupnost v SQL Serveru pro aplikace, které vyžadují distribuované transakce, které používají DTC pod kryty, bylo nasazení FCI. Distribuovanou transakci je možné provést jedním ze dvou způsobů:

• Transakce, která zahrnuje více než jednu databázi ve stejné instanci SQL Serveru.
• Transakce, která zahrnuje více než jednu instanci SQL Serveru nebo může zahrnovat zdroj dat mimo SQL Server.

SQL Server 2016 (13.x) zavedl částečnou podporu DTC s AG, který pokrýval druhý scénář. SQL Server 2017 (14.x) dokončuje příběh podporou obou scénářů pomocí DTC.

V SQL Serveru 2017 (14.x) a novějších verzích můžete přidat podporu DTC do skupiny dostupnosti poté, co je vytvořena. V SQL Serveru 2016 (13.x) můžete povolit podporu DTC pouze při vytváření skupiny dostupnosti.

Instance clusteru pro převzetí služeb při selhání

Instance clusteru pro převzetí služeb při selhání (FCI) poskytují dostupnost pro celou instalaci SQL Serveru, známou jako instance. Pokud u FCI dojde k problému základního serveru, přesune se všechno uvnitř instance na jiný server, včetně databází, úloh agenta SQL Serveru, propojených serverů a dalších. Všechny FCIs vyžadují určité sdílené úložiště, i když je definováno sítí. V daném okamžiku může jeden uzel spouštět a vlastnit prostředky FCI. V následujícím diagramu první uzel clusteru vlastní FCI. Vlastní také sdílené prostředky úložiště, které jsou s ním spojeny a které označuje souvislá čára ke skladovacímu zařízení.

Po převzetí služeb při selhání se vlastnictví změní, jak je znázorněno v následujícím diagramu.

FCI má nulovou ztrátu dat, ale základní sdílené úložiště je kritickým bodem selhání, protože existuje jedna kopie dat. Pokud chcete mít redundantní kopie databází, zkombinujte FCI s jinou metodou dostupnosti, jako je skupina dostupnosti (AG) nebo přenášení protokolů. Druhá metoda musí používat fyzicky oddělené úložiště od FCI. Když služba FCI převezme služby při selhání na jiný uzel, zastaví se na jednom uzlu a spustí se na jiném. Tento proces se podobá vypnutí serveru a jeho zapnutí.

FCI prochází normálním procesem obnovení. Postoupí všechny transakce, které je potřeba dokončit, a zruší všechny neúplné transakce. Proto je databáze konzistentní od určitého stavu dat až do chvíle selhání nebo ručního přepnutí, takže nedojde ke ztrátě dat. Databáze jsou k dispozici až po dokončení obnovení. Doba obnovení závisí na mnoha faktorech a obecně je delší než přepnutí na skupinu dostupnosti. Kompromisem je, že když převezmete služby při selhání skupiny dostupnosti, můžou být potřeba další úlohy potřebné k tomu, aby byla databáze použitelná, například povolení úlohy agenta SQL Serveru.

Poznámka:

Zrychlené obnovení databáze (ADR) může zmírnit dobu obnovení. Další informace najdete v tématu Zrychlené obnovení databáze.

Podobně jako AG, FCIs abstrahuje uzel základního clusteru, který ji hostuje. FCI vždy uchovává stejný název. Aplikace a koncoví uživatelé se nikdy nepřipojí k uzlům. Místo toho používají jedinečný název přiřazený FCI. FCI se může účastnit skupiny dostupnosti jako jedna z instancí, která hostí buď primární, nebo sekundární repliku.

Následující seznam uvádí některé rozdíly mezi FCI ve Windows Serveru a Linuxem:

• Ve Windows Serveru je součástí procesu instalace FCI. Po instalaci SQL Serveru nakonfigurujete FCI v Linuxu.
• Linux podporuje pouze jednu instalaci SQL Serveru na hostitele, takže všechny FCI jsou výchozí instancí. Windows Server podporuje až 25 FCI na WSFC.
• Běžný název používaný FCIs v Linuxu je definován v DNS a měl by být stejný jako prostředek, který je vytvořen pro FCI.

Přenášení protokolových souborů

Pokud jsou cíle bodu obnovení a doby obnovení flexibilnější nebo databáze nejsou vysoce důležité, je log shipping další ověřenou funkcí dostupnosti v SQL Serveru. Na základě nativních záloh SQL Serveru proces přepravy protokolů automaticky generuje zálohy transakčních protokolů, zkopíruje je do jedné nebo více instancí, které se označují jako zahřívací záložní režim, a automaticky použije tyto zálohy transakčních protokolů na tento zahřívací záložní režim. Přeprava protokolů využívá úlohy agenta SQL Server k automatizaci procesu zálohování, kopírování a použití záloh transakčních protokolů.

Největší výhodou používání log shipping je, že dokáže zohlednit lidské chyby, protože můžete odložit aplikaci transakčních protokolů. Pokud například někdo vydá UPDATE bez klauzule WHERE, záložní systém nemusí mít tuto změnu, takže na něj můžete přepnout při opravě primárního systému. I když je přesouvání protokolů snadné, přepnutí z primárního na teplý pohotovostní režim, označovaný jako změna role, je vždy ruční. Změnu role zahájíte pomocí Transact-SQL a podobně jako u AG musíte ručně synchronizovat všechny objekty, které nejsou zachyceny v transakčním protokolu. Potřebujete nakonfigurovat log shipping pro každou databázi, přičemž jedna skupina dostupnosti může obsahovat více databází.

Na rozdíl od AG nebo FCI nemá log shipping žádnou abstrakci pro změnu role, kterou aplikace musí umět zpracovat. Je možné použít techniky, jako je alias DNS (CNAME), ale existují výhody a nevýhody, například doba potřebnou k aktualizaci DNS po přepnutí.

Zotavení po havárii

Když vaše primární lokalita dostupnosti zaznamená katastrofickou událost, jako je zemětřesení nebo záplava, musí být firma připravená, aby její systémy byly online jinde. Tato část popisuje, jak můžou funkce dostupnosti SQL Serveru pomoct s provozní kontinuitou.

Skupiny dostupnosti

Jednou z výhod skupin AG je konfigurace vysoké dostupnosti i zotavení po havárii pomocí jedné funkce. Bez požadavku na zajištění vysoké dostupnosti sdíleného úložiště je mnohem jednodušší mít repliky, které jsou místní v jednom datovém centru pro zajištění vysoké dostupnosti, a vzdálené repliky v jiných datových centrech pro zotavení po havárii s odděleným úložištěm. Další kopie databáze jsou kompromisem pro zajištění redundance. Příklad skupiny dostupnosti, která zahrnuje více datových center, je znázorněno v následujícím diagramu. Jedna primární replika zodpovídá za synchronizaci všech sekundárních replik.

Mimo skupinu dostupnosti s typem clusteru "None" vyžaduje skupina dostupnosti, aby všechny repliky byly součástí stejného základního clusteru, ať už se jedná o WSFC nebo externí clusterové řešení. V předchozím diagramu je WSFC roztažený tak, aby fungoval ve dvou různých datových centrech, což zvyšuje složitost bez ohledu na platformu (Windows Server nebo Linux). Rozšíření shluků přes vzdálenost zvyšuje složitost.

Představeno v SQL Serveru 2016 (13.x), distribuovaná skupina dostupnosti umožňuje skupině dostupnosti pokrýt skupiny dostupnosti nakonfigurované v různých clusterech. Distribuované skupiny dostupnosti (AG) oddělují požadavek, aby byly uzly součástí stejného clusteru, což výrazně usnadňuje konfiguraci obnovení po havárii. Další informace o distribuovaných skupinách dostupnosti najdete v tématu Distribuované skupiny dostupnosti.

Instance clusteru pro převzetí služeb při selhání

FcI můžete použít k zotavení po havárii. Stejně jako u normální skupiny dostupnosti musíte rozšířit základní clusterový mechanismus na všechna umístění, což zvyšuje složitost. U FCI je také potřeba zvážit sdílené úložiště. Primární a sekundární lokality potřebují přístup ke stejným diskům. Pokud chcete zajistit, aby úložiště používané FCI existovalo v obou lokalitách, použijte externí metodu, například funkce poskytované dodavatelem úložiště na hardwarové vrstvě. Případně použijte repliku úložiště ve Windows Serveru.

Přenášení protokolových souborů

Jedna z nejstarších metod pro zajištění zotavení po havárii pro databáze SQL Serveru je log shipping. Přesouvání protokolů se často používá se skupinami AG a FCI k zajištění nákladově efektivního a jednoduššího zotavení po havárii, kde můžou být kvůli životnímu prostředí, administrativním dovednostem nebo rozpočtu náročné další možnosti. Podobně jako u scénáře vysoké dostupnosti pro log shipping, mnoho prostředí zpozdí načítání transakčního protokolu, aby zohlednilo lidskou chybu.

Migrace a upgrady

Když organizace nasadí nové instance nebo upgrady starých instancí, nemůže tolerovat dlouhé výpadky. Tato část popisuje, jak lze pomocí funkcí dostupnosti SQL Serveru minimalizovat výpadky v plánované změně architektury, přepínači serveru, změně platformy (například Windows Server na Linux nebo naopak) nebo během oprav.

Poznámka:

Pro migrace a upgrady můžete také použít jiné metody, jako jsou zálohy a obnovení. Tento článek tyto metody neprobírá.

Skupiny dostupnosti

Existující instanci, která obsahuje jednu nebo více platných skupin dostupnosti (AG), můžete upgradovat na novější verze SQL Serveru. I když tento upgrade vyžaduje určitý výpadek, je možné ho minimalizovat se správným množstvím plánování.

Pokud chcete migrovat na nové servery beze změny konfigurace (včetně operačního systému nebo verze SQL Serveru), přidejte tyto servery jako uzly do existujícího základního clusteru a pak je přidejte do skupiny dostupnosti. Jakmile jsou replika nebo repliky ve správném stavu, ručně proveďte převzetí služeb při selhání na nový server. Potom odeberte staré servery ze skupiny dostupnosti a vyřaďte je z provozu.

Distribuované dostupnostní skupiny (AG) jsou také dalším způsobem migrace na novou konfiguraci nebo upgrade SQL Serveru. Vzhledem k tomu, že distribuovaná skupina dostupnosti podporuje různé základní skupiny dostupnosti v různých architekturách, můžete změnit sql Server 2019 (15.x) běžící na Windows Serveru 2019 na SQL Server 2025 (17.x) běžící na Windows Serveru 2025.

Skupiny AG s typem clusteru None jsou užitečné pro migraci nebo upgrade. V typické konfiguraci AG nemůžete kombinovat a kombinovat různé typy clusterů, takže všechny repliky musí být typu none. Distribuovanou skupinu dostupnosti je možné použít k propojení skupin dostupnosti nakonfigurovaných s různými typy clusterů. Tato metoda se podporuje také na různých platformách operačního systému.

Všechny varianty skupin AG pro migrace a upgrady umožňují synchronizaci dat, která je nejvíce časově náročnou částí práce, rozložit v průběhu času. Pokud nastane čas zahájit přepnutí na novou konfiguraci, je krátký výpadek na rozdíl od jednoho dlouhého výpadku, kdy musí být dokončena veškerá práce, včetně synchronizace dat.

Skupiny dostupnosti (AG) mohou během oprav základního operačního systému poskytovat minimální prostoje tím, že během oprav ručně přepnou primární repliku na sekundární repliku. Z hlediska operačního systému je to běžnější na Windows Serveru, protože údržba základního operačního systému může vyžadovat restartování. Opravy Linuxu někdy potřebují restartování, ale je méně běžné.

Dalším způsobem, jak minimalizovat výpadky, je opravit instance SQL Serveru, které se účastní skupiny dostupnosti, v závislosti na tom, jak složitá je architektura skupiny dostupnosti. Nejprve opravíte sekundární repliku. Jakmile je opraven správný počet replik, ručně převeďte primární repliku na jiný uzel pro provedení upgradu. V tomto okamžiku upgradujte všechny zbývající sekundární repliky.

Instance clusteru pro převzetí služeb při selhání

FCIs samy o sobě nejsou schopny podporovat tradiční migraci nebo upgrade. Musíte nakonfigurovat dostupnostní skupiny nebo přepravu protokolů pro databáze v instanci FCI a zohlednit všechny ostatní objekty. FcI v systému Windows Server jsou ale stále oblíbenou možností, pokud potřebujete opravit základní servery Windows. Když zahájíte ruční převzetí služeb při selhání, krátký výpadek nahradí delší nedostupnost instance, ke které by došlo během opravování serveru Windows.

FCI můžete upgradovat na novější verze SQL Serveru. Další informace najdete v tématu Upgrade instance clusteru s podporou převzetí služeb při selhání.

Přenášení protokolových souborů

Log shipping je stále oblíbenou možností pro migraci i aktualizaci databází. Podobně jako skupiny AG, ale tentokrát pomocí transakčního logu jako metody synchronizace lze šíření dat spustit ještě před přepnutím serveru. V okamžiku přepnutí, jakmile je veškerý provoz na zdroji zastaven, bude potřeba vzít, zkopírovat a použít konečný transakční protokol pro novou konfiguraci. V tomto okamžiku je možné databázi převést do režimu online.

Přesouvání protokolů je často tolerantnější vůči pomalejším sítím a zatímco přepnutí může být o něco delší než při použití skupiny dostupnosti nebo distribuované skupiny dostupnosti, obvykle se měří v minutách, ne hodinách, dnech nebo týdnech.

Podobně jako AG může přeprava protokolu poskytnout způsob, jak během okna údržby přepnout na jiný server.

Další metody nasazení a dostupnost SQL Serveru

Pro SQL Server v Linuxu existují dvě další metody nasazení: kontejnery a použití Azure (nebo jiného poskytovatele veřejného cloudu). Obecná potřeba dostupnosti existuje bez ohledu na to, jak je SQL Server nasazený. Tyto dvě metody mají určité zvláštní aspekty při zajištění vysoké dostupnosti SQL Serveru.

Kontejnery SQL Serveru a možnosti zotavení po havárii

Nasazení kontejneru SQL Serveru je způsob, jak zjednodušit zřizování, škálování a správu životního cyklu SQL Serveru napříč prostředími. Kontejner je kompletní image SQL Serveru připravená ke spuštění.

V závislosti na platformě kontejneru, například při použití orchestrátoru kontejnerů, jako je Kubernetes, pokud je kontejner ztracen, je možné ho znovu nasadit a připojit ke sdílenému úložišti, které bylo použito. I když to zajišťuje určitou odolnost, dochází k určitým výpadkům spojeným s obnovením databáze a není skutečně vysoce dostupná, protože by byla při použití skupiny dostupnosti nebo FCI.

Pokud chcete nakonfigurovat vysokou dostupnost pro kontejnery SQL Serveru nasazené na platformě Kubernetes nebo na platformy jiné než Kubernetes, můžete použít DH2i DxEnterprise jako jedno z řešení klastrování, na které můžete nakonfigurovat skupinu dostupnosti v režimu vysoké dostupnosti. Tato možnost poskytuje cíl bodu obnovení (RPO) a plánovanou dobu obnovení (RTO) očekávané z řešení s vysokou dostupností.

Nasazení virtuálního počítače s Linuxem

Linux je možné nasadit s SQL Serverem na virtuálních počítačích Azure s Linuxem. Stejně jako u místních instalací vyžaduje podporovaná instalace použití metody bezpečnostního uzamčení (fencing) selhaného uzlu, který je oddělený od samotného agenta clusteru. Ohraničení uzlů je poskytováno prostřednictvím agentů dostupnosti ohraničení. Některé distribuce je dodávají jako součást platformy, zatímco jiné spoléhají na externí dodavatele hardwaru a softwaru. V preferované distribuci Linuxu se podívejte, jaké formy ohraničení uzlů jsou k dispozici, aby bylo možné nasadit podporované řešení ve veřejném cloudu.

Příručky pro instalaci SQL Serveru v Linuxu jsou k dispozici pro následující distribuce:

• rychlý start pro : Instalace SQL Serveru a vytvoření databáze v Red Hat
• rychlý start pro : Instalace SQL Serveru a vytvoření databáze na Ubuntu
• Rychlý start: Instalace SQL Serveru a vytvoření databáze na SUSE Linux Enterprise Server

Škálování čtení

Sekundární repliky mají možnost používat pro dotazy jen pro čtení. Existují dva způsoby, jak toho lze dosáhnout pomocí Availability Group:

• Povolit přímý přístup ke sekundární jednotce
• Konfigurace směrování jen pro čtení, která vyžaduje použití posluchače. SQL Server 2016 (13.x) zavedl možnost vyrovnávat zatížení připojení jen pro čtení prostřednictvím naslouchátka pomocí algoritmu round-robin, což umožňuje rozprostřít požadavky jen pro čtení mezi všechny čitelné repliky.

Poznámka:

Sekundární repliky s možností čtení jsou k dispozici pouze v edici Enterprise. Každá instance, která je hostitelem čitelné repliky, potřebuje licenci SQL Serveru.

Škálování čitelných kopií databáze prostřednictvím skupin AG bylo poprvé zavedeno s distribuovanými skupinami AG v SQL Serveru 2016 (13.x). Tato funkce nabízí kopie databáze jen pro čtení nejen místně, ale také regionálně i globálně s minimální konfigurací. Toto nastavení snižuje síťový provoz a latenci tím, že se dotazy spouštějí místně. Každá primární replika skupiny dostupnosti může obsahovat dvě další skupiny dostupnosti, i když se nejedná o úplnou kopii pro čtení a zápis a každá distribuovaná skupina dostupnosti může podporovat až 27 čitelných kopií dat.

V SQL Serveru 2017 (14.x) a novějších verzích můžete vytvořit řešení jen pro čtení téměř v reálném čase s skupinami AG nakonfigurovanými s typem clusteru None. Pokud vaším cílem je použít skupiny AG pro čitelné sekundární repliky a ne dostupnost, tento přístup eliminuje složitost používání WSFC nebo externího clusterového řešení v Linuxu. Poskytuje přehledné výhody AG v jednodušším způsobu nasazení.

Jediným hlavním omezením je, že protože neexistuje žádný základní cluster s typem clusteru None, je konfigurace směrování jen pro čtení jiná. Z pohledu SQL Serveru je stále vyžadován listener pro směrování požadavků, i když neexistuje žádný cluster. Místo konfigurace tradičního naslouchacího programu použijte IP adresu nebo název primární repliky. Primární replika pak směruje požadavky pouze pro čtení.

Záložní pohotovostní režim pro odesílání protokolů lze technicky nakonfigurovat pro čitelné použití obnovením databáze WITH STANDBY. Vzhledem k tomu, že transakční protokoly vyžadují výhradní použití databáze k obnovení, znamená to, že uživatelé nebudou mít přístup k databázi, když k ní dojde. To činí převod protokolů ne zcela ideálním řešením - zejména pokud jsou vyžadována data téměř v reálném čase.

Na rozdíl od transakční replikace, kde jsou všechna data živá, je každá sekundární replika ve scénáři škálování pro čtení přesnou kopií primární repliky. Replika není ve stavu, kdy je možné použít jedinečné indexy. Pokud jsou potřebné nějaké indexy pro vytváření sestav nebo pokud je nutná manipulace s daty, musíte tyto indexy vytvořit v databázích na primární replice. Pokud tuto flexibilitu potřebujete, je replikace lepším řešením pro čitelná data.

Interoperabilita distribuce mezi platformami a Linuxem

S podporou SQL Serveru ve Windows Serveru i Linuxu se tato část zabývá tím, jak můžou spolupracovat pro zajištění dostupnosti kromě dalších účelů. Popisuje také scénář řešení, která zahrnují více než jednu linuxové distribuci.

Poznámka:

Neexistují žádné scénáře, kdy by instance clusteru s podporou převzetí služeb při selhání (FCI) nebo skupina dostupnosti (AG) založená na WSFC přímo spolupracovala s FCI nebo skupinou dostupnosti (AG) založenou na Linuxu. Cluster služby Windows Serveru pro převzetí služeb při selhání (WSFC) nelze rozšířit uzlem Pacemaker a naopak.

Distribuované skupiny dostupnosti

Distribuované skupiny dostupnosti jsou navržené k pokrytí konfigurací skupin dostupnosti, ať už jsou tyto dva clustery pod AGs dvě různé clustery WSFC, linuxové distribuce nebo jeden na WSFC a druhý na Linuxu. Distribuovaná skupina dostupnosti (AG) je primární metodou řešení, které funguje napříč různými platformami. Distribuovaná skupina dostupnosti (AG) je také primárním řešením pro migrace, jako je převod z infrastruktury SQL Serveru na Windows Server do linuxové infrastruktury, pokud to chce vaše společnost udělat. Jak jsme si poznamenali dříve, skupiny AG a zejména distribuované skupiny AG by minimalizovaly dobu, po kterou by aplikace byla nedostupná pro použití. Příklad distribuované skupiny dostupnosti, která zahrnuje WSFC a Pacemaker, je znázorněn v následujícím diagramu:

Pokud nakonfigurujete skupinu dostupnosti s typem clusteru None, může zahrnovat Windows Server a Linux a několik distribucí Linuxu. Vzhledem k tomu, že tato konfigurace není skutečná vysoká dostupnost, nepoužívejte ji pro kritická nasazení. Místo toho ho použijte pro scénáře škálování čtení, migraci nebo upgrade.

Přenášení protokolových souborů

Přesouvání protokolů je založené na zálohování a obnovení, takže neexistují žádné rozdíly v databázích, strukturách souborů a dalších prvcích SQL Serveru na Windows Serveru proti SQL Serveru na Linuxu. Můžete nakonfigurovat přesouvání protokolů mezi instalací SQL Serveru s Windows Serverem a Linuxem a mezi distribucemi Linuxu. Všechno ostatní zůstává stejné.

Stejně jako u Always On Availability Group, nefunguje přenos protokolových záznamů, když je zdrojový server na vyšší hlavní verzi SQL Serveru než cíl, který má nižší hlavní verzi.

Shrnutí

Instance a databáze SQL Serveru 2017 (14.x) a novější verze můžete nastavit jako vysoce dostupné pomocí stejných funkcí ve Windows Serveru i Linuxu. Kromě standardních scénářů dostupnosti místní vysoké dostupnosti a zotavení po havárii můžete minimalizovat výpadky spojené s upgrady a migracemi pomocí funkcí dostupnosti na SQL Serveru. Skupiny AG můžou také poskytovat další kopie databáze jako součást stejné architektury, aby bylo možné škálovat čitelné kopie. Ať už nasazujete nové řešení nebo zvažujete upgrade, SQL Server má dostupnost a spolehlivost, kterou potřebujete.

Související obsah

• Co je skupina dostupnosti AlwaysOn?
• Instalace clusteru SQL Server pro převzetí služeb při selhání