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

platí pro:SQL Server – Linux

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.

Jednou z běžných úloh, pro které musí každý, kdo nasazuje SQL Server, je zajistit, aby všechny důležité instance SQL Serveru a databáze v nich byly k dispozici, když je podnik a koncoví uživatelé potřebují, ať už je to 9 až 5, 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) zavedl mnoho nových funkcí nebo vylepšení stávajících funkcí, z nichž některé jsou pro dostupnost. Největší novinkou SQL Serveru 2017 (14.x) byla podpora pro SQL Server na linuxových distribucích. Úplný seznam nových funkcí sql Serveru najdete v následujících článcích:

• Novinky v SQL Serveru 2017
• Co je nového pro SQL Server 2017 v Linuxu
• Novinky v SQL Serveru 2019
• Co je nového pro SQL Server 2019 v linuxovém
• Novinky v SQL Serveru 2022

Tento článek se zaměřuje na pokrytí scénářů dostupnosti v SQL Serveru 2017 (14.x) a novějších verzích a také nových a vylepšených funkcích dostupnosti. Mezi scénáře patří hybridní scénáře, které budou moct zasahovat do 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 ty, které poskytuje virtualizace, platí pro instalace SQL Serveru v hostovaném virtuálním počítači bez ohledu na to, jestli se jedná o veřejný cloud nebo hostovaný místním serverem hypervisoru.

Scénáře SQL Serveru s využitím funkcí dostupnosti

Skupiny dostupnosti AlwaysOn, instance clusteru s podporou převzetí služeb při selhání AlwaysOn a přesouvání protokolů se dají používat různými způsoby, a ne nutně jen pro účely dostupnosti. Existují čtyři hlavní způsoby použití funkcí dostupnosti:

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

V následujících částech najdete informace o relevantních funkcích, které se dají použít pro daný scénář. Jedna funkce není pokryta replikací SQL Serveru. I když není oficiálně označena jako funkce dostupnosti v rámci Always On, SQL Server replikace se často používá pro vytvoření datové redundance v některý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í, 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 v případě problému, který je místní pro datové centrum nebo jednu oblast v cloudu. V této části se dozvíte, jak s touto úlohou můžou pomoct funkce dostupnosti SQL Serveru. Všechny popsané funkce jsou k dispozici na Windows Serveru i v Linuxu.

Skupiny dostupnosti

Představené v SQL Serveru 2012 (11.x), 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. Skupina dostupnosti (AG) se dá 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 bude nutné ručně synchronizovat cokoli, co není zaznamenáno 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 SQL Serveru 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 by měla vlastní posluchač. Zatímco implementace naslouchacího procesu se na Windows Serveru a Linuxu mírně liší, funkce, které poskytuje a jak se používá, jsou stejné. Následující diagram znázorňuje skupinu dostupnosti založenou na Windows Serveru, která používá cluster s podporou převzetí služeb při selhání systému Windows Server (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 se nepřidá. 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 je naslouchací proces používán a aplikace používá novější verzi rozhraní .NET Framework (verze 3.5 s aktualizací nebo 4.0 a vyšší), mělo by být převzetí služeb při selhání zpracováno s minimálním nebo žádným dopadem na koncové uživatele. 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 k rozdílům ve způsobu fungování základního clusteru na Linuxu a Windows Serveru se všechna převzetí služeb při selhání (ruční nebo automatická) skupin dostupnosti provádí prostřednictvím clusteru v 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 je doporučená konfigurace skupin AG minimálně tři repliky. Důvodem je způsob, jakým funguje základní clustering.
• 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) zavádí 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. cs-CZ: Integraci pro AG a FCI zajišťují knihovny DLL prostředků kompatibilních s clustery, které poskytuje SQL Server.

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. DNS zajišťuje rozlišení jmen v systému Linux.

Vzhledem k rozdílu v zásobníku clusteru je potřeba provést některé změny pro AG, protože SQL Server musí zpracovávat určitá metadata, která jsou nativně zpracovávána WSFC. Jednou z takových zásadních změn je zavedení typu clusteru pro skupinu dostupnosti. [něco] je uloženo ve sys.availability_groups ve sloupcích cluster_type a cluster_type_desc. Existují tři typy clusterů:

• 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í podkladovou službu WSFC, je výchozí typ clusteru WSFC a není potřeba ho nastavit. Pro skupiny dostupnosti založené na Linuxu musí být typ clusteru nastaven 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. To znamená, že se skupina dostupnosti nedá přepnout z žádné na externí nebo WSFC nebo naopak.

Pro ty, kteří chtějí jenom přidat další kopie databáze jen pro čtení, nebo pokud se vám líbí, co skupina dostupnosti (AG) poskytuje pro migrace nebo upgrady, ale nechtějí být svázáni s další složitostí základního clusteru nebo dokonce replikací, je skupina dostupnosti s typem clusteru 'None' ideálním řešením. 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 je 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 se ale jedna sekundární replika synchronizovala, ale druhá měla problém, nebylo možné řídit chování primárního serveru tak, aby buď čekal na špatnou repliku, nebo aby se mohla přesunout dál. To znamená, že primární replika v určitém okamžiku bude nadále přijímat zápisové transakce, i když sekundární replika nebude v synchronizovaném stavu, což znamená, že na sekundární replice dochází ke ztrátě dat.

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 potřeba synchronizovat, což má vliv na ztrátu dat, dostupnost AG a převzetí při selhání.
• Pro WSFCs a typ clusteru None je výchozí hodnota 0, a lze ji nastavit ručně na 1 nebo 2.
• U typu External clusteru ve výchozím nastavení nastaví mechanismus clusteru tuto hodnotu a lze ji přepsat ručně. Pro tři synchronní repliky bude 1výchozí hodnota .

Na Linuxu je hodnota pro REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT nakonfigurována na prostředku AG v clusteru. Ve Windows je nastavená 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í nebude k dispozici, dokud se tento problém nevyřeší. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ovlivňuje také chování převzetí služeb při selhání, protože automatické převzetí služeb při selhání nešlo nastat, pokud správný počet sekundárních replik nebyl ve správném stavu. Na Linuxu hodnota 0 nepovolí automatické převzetí, takže pokud používáte synchronní režim s automatickým převzetím, musí být hodnota nastavena vyšší než 0, aby se dosáhlo automatického převzetí. 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 zajistit dostupnost v SQL Serveru pro aplikace, které vyžadují distribuované transakce a používají DTC v pozadí, nasadit FCIs. 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 jiného typu než 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 SYSTÉMU SQL Server 2017 (14.x) a novějších verzích je možné podporu DTC přidat také do skupiny dostupnosti po jejím vytvoření. V SQL Serveru 2016 (13.x) bylo možné povolit podporu DTC pro AG pouze při jeho vytvoření.

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

Clusterované instalace jsou funkcí SQL Serveru od verze 6.5. FCI jsou prověřenou metodou zajištění dostupnosti pro celou instalaci SQL Serveru, která se označuje jako instance. To znamená, že všechno uvnitř instance, včetně databází, úloh agenta SQL Serveru, propojených serverů atd., se přesune na jiný server, pokud by základní server narazil na problém. Všechny FCI vyžadují určitý druh sdíleného úložiště, i když je poskytováno prostřednictvím sítě. Prostředky FCI můžou být spuštěné a vlastněné pouze jedním uzlem v daném okamžiku. V následujícím diagramu první uzel clusteru vlastní FCI, což také znamená, že vlastní sdílené prostředky úložiště přidružené k němu označené plnou čárou k úložišti.

Po převzetí služeb při selhání se vlastnictví změní, jak je vidět v následujícím diagramu:

U FCI došlo k nulové ztrátě dat, ale základní sdílené úložiště je kritickým bodem způsobujícím selhání, protože existuje jedna kopie dat. FCI se často kombinují s jinou metodou vysoké dostupnosti, jako je například skupina dostupnosti (AG) nebo přesouvání logů, aby měly redundantní kopie databází. Nasazená další metoda by měla používat fyzicky oddělené úložiště od FCI. Když FCI při selhání přejde na jiný uzel, zastaví se na jednom uzlu a spustí se na jiném, podobně jako při vypnutí serveru a jeho opětovném zapnutí. FCI prochází normálním procesem obnovení, což znamená, že všechny transakce, které je potřeba vrátit dopředu, budou vráceny dopředu, a všechny transakce, které jsou neúplné, budou vráceny zpět. Proto je databáze konzistentní od určitého okamžiku do času selhání nebo ručního přepnutí při selhání, takže nedojde ke ztrátě dat. Databáze jsou dostupné až po dokončení obnovení, takže doba obnovení bude záviset na mnoha faktorech a obecně bude delší než převzetí služeb při selhání AG. 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.

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; Použije se jedinečný název přiřazený K 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 se nakonfiguruje FCI v Linuxu.
• Linux podporuje pouze jednu instalaci SQL Serveru na hostitele, takže všechny FCI budou 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 obnovy bodu a doby obnovení flexibilnější nebo databáze nejsou považovány za vysoce kritické, je log shipping další ověřenou funkcí dostupnosti 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ů.

Pravděpodobně největší výhodou použití přenosu protokolů do určité míry je, že zohledňuje lidskou chybu. Aplikace transakčních protokolů může být zpožděna. Proto pokud někdo vydá něco jako UPDATE bez WHERE klauzule, pohotovostní režim nemusí mít změnu, takže byste mohli přepnout na tuto možnost během opravy primárního systému. I když je log shipping snadno konfigurovatelný, přepnutí z primárního na teplý pohotovostní režim, známé jako změna role, je vždy ruční. Změna role je inicializována prostřednictvím jazyka Transact-SQL a podobně jako AG (skupina dostupnosti) je nutné ručně synchronizovat všechny objekty, které nejsou zachyceny v transakčním protokolu. Odesílání protokolů je třeba konfigurovat pro každou jednotlivou databázi, zatímco jedna skupina dostupnosti může zahrnovat 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. V této části se dozvíte, jak můžou funkce dostupnosti SQL Serveru pomoct s kontinuitou podnikových procesů.

Skupiny dostupnosti

Jednou z výhod skupin AG je, že vysokou dostupnost i zotavení po havárii je možné nakonfigurovat 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 "žádný" vyžaduje skupina dostupnosti, aby všechny repliky byly součástí stejného základního clusteru, bez ohledu na to, zda se jedná o řešení WSFC nebo externí cluster. To znamená, že ve výše uvedené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 lze použít k zotavení po havárii. Stejně jako u běžné AG musí být základní mechanismus clusteru rozšířen do všech umístění, což zvyšuje složitost. Další úvaha u FCI: sdílené úložiště. Stejné disky musí být dostupné v primární a sekundární lokalitě. Externí metoda, jako je funkce poskytovaná dodavatelem úložiště na hardwarové vrstvě nebo použití repliky úložiště ve Windows Serveru, je nutná k zajištění, aby disky používané FCI existovaly jinde.

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

Přenášení protokolů je jednou z nejstarších metod obnovení po havárii pro databáze SQL Serveru. 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 přesouvání protokolů se mnoho prostředí zpozdí načítání transakčního protokolu, aby se zohlednilo lidské chyby.

Migrace a upgrady

Při nasazování nových instancí nebo upgradu starých instancí nemůže firma 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:

Další metody, jako je použití záloh a jejich obnovení jinde, je možné použít také pro migrace a upgrady. Nejsou popsány v tomto článku.

Skupiny dostupnosti

Existující instanci obsahující jednu nebo více skupin AG je možné upgradovat na novější verze SQL Serveru. I když to vyžaduje určitý výpadek, se správným množstvím plánování je možné ho minimalizovat.

Pokud je cílem migrace na nové servery a neměnit konfiguraci (včetně operačního systému nebo verze SQL Serveru), je možné tyto servery přidat jako uzly do existujícího základního clusteru a přidat je do skupiny dostupnosti. Jakmile je replika nebo repliky ve správném stavu, může dojít k ručnímu převzetí služeb na nový server a potom se staré repliky můžou odebrat ze skupiny dostupnosti a nakonec vyřadit 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 například změnit SQL Server 2016 (13.x) běžící na Windows Server 2012 R2 na SQL Server 2017 (14.x) běžící na Windows Server 2016.

Skupiny AG s typem clusteru None se také dají použít k migraci nebo upgradu. V typické konfiguraci skupiny dostupnosti nemůžete kombinovat a shodovat typy clusterů, takže všechny repliky by měly být typu Žádné. 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í, aby nejvíce časově náročnou částí práce byla synchronizace dat, kterou lze provádět postupně v průběhu času. Pokud nastane čas zahájit přepnutí na novou konfiguraci, je přímá výpadek krátká oproti jednomu dlouhému výpadku, kdy by bylo potřeba dokončit veškerou práci, včetně synchronizace dat.

Skupiny AG můžou poskytovat minimální prostoje během oprav základního operačního systému tím, že během dokončení oprav ručně přepnou primární repliku na sekundární repliku. Z hlediska operačního systému by to bylo na Windows Serveru častější, protože často, ale ne vždy, obsluha základního operačního systému může vyžadovat restartování. Opravy Linuxu někdy vyžadují restartování, ale může to být zřídkakdy.

Oprava instancí SQL Serveru, které se účastní přístupnostní skupiny může také minimalizovat výpadky v závislosti na tom, jak složitá je architektura přístupnostní skupiny. Pro opravy serverů, které se účastní skupiny dostupnosti, se nejprve opraví sekundární replika. Jakmile je opraven správný počet replik, primární replika se ručně přesměruje na jiný uzel, aby bylo možné provést upgrade. V tomto okamžiku je možné upgradovat také všechny zbývající sekundární repliky.

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

Samotné FCI nemohou pomoci s tradiční migrací nebo upgradem; pro databáze v FCI a pro zohlednění všech ostatních objektů by měla být nakonfigurována skupina dostupnosti nebo log shipping. FcI v systému Windows Server jsou ale stále oblíbenou možností, když je potřeba opravit základní servery Windows. Ruční převzetí služeb při selhání je možné zahájit, což znamená krátký výpadek místo toho, aby instance byla po celou dobu opravy Windows Serveru nedostupná. FCI je možné upgradovat na novější verze SQL Serveru. 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 log shipping poskytnout způsob, jak v případě instalaci záplat 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, jak je uvedeno v tomto dokumentu, existuje bez ohledu na to, jak je SQL Server nasazen. Tyto dvě metody mají některé zvláštní aspekty, pokud jde o zajištění vysoké dostupnosti SQL Serveru.

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

Nasazení kontejneru SQL Serveru je nový způsob nasazení SQL Serveru v Linuxu. Kontejner je kompletní image SQL Serveru, která je připravená ke spuštění.

V závislosti na platformě kontejneru, kterou používáte, například při použití orchestrátoru kontejnerů, jako je Kubernetes, pokud dojde ke ztrátě kontejneru, může být znovu nasazen a připojen 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í IaaS založené na Linuxu

Virtuální počítače IaaS s Linuxem je možné nasadit s SQL Serverem nainstalovaným pomocí Azure. Stejně jako u místních instalací vyžaduje podporovaná instalace použití uzlu, který selhal, který je externí pro 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 dosáhnout pomocí AG: povolením přímého přístupu k sekundární a konfigurací směrování jen pro čtení, které vyžaduje použití listeneru. 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 a každá instance hostující repliku pro čtení by potřebovala 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). To by společnostem umožnilo mít kopie databáze jen pro čtení nejen místně, ale i globálně s minimálním množstvím konfigurace a snížit síťový provoz a latenci tím, že se dotazy spouští místně. Každá primární replika skupiny dostupnosti může inicializovat dvě další skupiny dostupnosti, i když není plně pro čtení a zápis, takže každá distribuovaná skupina dostupnosti může podporovat až 27 kopií dat, která jsou dostupná pro čtení.

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 je cílem použít skupiny dostupnosti pro čitelné sekundární repliky a ne dostupnost, odeberete tím složitost používání WSFC nebo externího clusterového řešení v Linuxu a získáte čitelné výhody skupiny dostupnosti v jednodušší metodě nasazení.

Jediným hlavním omezením je, že protože neexistuje žádný podkladový cluster s typem None, je konfigurace směrování jen pro čtení trochu odlišná. Z perspektivy SQL Serveru je stále zapotřebí naslouchací zařízení, které směruje požadavky, i když není přítomen žádný cluster. Místo konfigurace tradičního naslouchacího procesu se použije IP adresa nebo název primární repliky. Primární replika se pak použije ke směrování požadavků jen 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. Díky tomu je přesouvání protokolů méně než ideální řešení – zejména v případě, že se vyžadují data téměř v reálném čase.

Jedna věc, kterou je třeba poznamenat pro všechny scénáře škálování čtení pomocí skupin dostupnosti (AG), je, že na rozdíl od použití transakční replikace, kde jsou všechna data aktivní, není každá sekundární replika ve stavu umožňujícím použití jedinečných indexů; replika je přesnou kopií primární databáze. Pokud se vyžadují nějaké indexy pro vytváření sestav nebo zpracování dat, musí být vytvořeny 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 SQL Serverem, který je nyní podporován v systému Windows Server i Linux, se tato část věnuje scénářům, jak můžou spolupracovat pro dostupnost kromě jiných účelů a scénáře pro řešení, která budou obsahovat více než jednu linuxovou distribuci.

Poznámka:

Neexistují žádné scénáře, kdy by FCI nebo skupina dostupnosti založené na WSFC pracovaly přímo s FCI nebo skupinou dostupnosti založenou na Linuxu. WSFC nelze rozšířit uzlem Pacemaker a naopak.

Distribuované skupiny dostupnosti

Distribuované skupiny dostupnosti jsou navrženy tak, aby překrývaly konfigurace skupin dostupnosti, ať už jsou tyto dva základní clustery podporující AG dvě různé clustery WSFC, Linuxové distribuce nebo jeden v jednom WSFC a druhý na Linuxu. Distribuovaná skupina dostupnosti (AG) bude primární metodou pro řešení kompatibilní s různými platformami. Distribuovaná skupina dostupnosti je také primárním řešením pro migrace, jako je například převod z infrastruktury SQL Serveru na Windows Serveru na linuxovou infrastrukturu, pokud to vaše společnost zamýšlí. Jak je uvedeno výše, 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 je AG nakonfigurována s typem clusteru None, může zahrnovat jak Windows Server, tak Linux, a také různé distribuce Linuxu. Vzhledem k tomu, že se nejedná o skutečnou konfiguraci vysoké dostupnosti, neměla by se používat pro nezbytná nasazení, ale pro škálování pro čtení nebo scénáře migrace či upgradu.

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

Vzhledem k tomu, že přesouvání protokolů je založené na zálohování a obnovení a neexistují žádné rozdíly v databázích, strukturách souborů atd., pro SQL Server ve Windows Serveru a SQL Serveru v Linuxu. To znamená, že přesouvání protokolů je možné nakonfigurovat mezi instalací SQL Serveru s Windows Serverem a Linuxem, stejně jako mezi distribucemi Linuxu. Všechno ostatní zůstává stejné. Jediným upozorněním je, že přesouvání protokolů, stejně jako skupina dostupnosti, nemůže fungovat, když je zdroj ve vyšší hlavní verzi SQL Serveru proti cíli, který je v nižší verzi SQL Serveru.

Shrnutí

Instancí a databází SQL Serveru 2017 (14.x) a novějších verzí lze zajistit vysokou dostupnost pomocí stejných funkcí ve Windows Serveru i Linuxu. Kromě standardních scénářů dostupnosti místní vysoké dostupnosti a zotavení po havárii je možné výpadky spojené s upgrady a migracemi minimalizovat s funkcemi 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

• Konfigurace skupiny dostupnosti AlwaysOn sql Serveru pro zajištění vysoké dostupnosti v Linuxu
• Převzetí služeb při selhání skupiny dostupnosti Always On na Linuxu