Sdílet prostřednictvím

Režimy a operace převzetí služeb při selhání (Skupiny dostupnosti Always On)

platí pro:SQL Server

Tento článek popisuje režimy převzetí služeb při selhání a samotné převzetí služeb při selhání pro skupiny dostupnosti Always On SQL Serveru.

Přehled

V kontextu skupiny dostupnosti se primární role a sekundární role replik dostupnosti obvykle dají zaměnit v procesu označovaného jako převzetí služeb při selhání. Existují tři formy převzetí služeb při selhání: automatické převzetí služeb při selhání (bez ztráty dat), plánované ruční převzetí služeb při selhání (bez ztráty dat) a vynucené ruční převzetí služeb při selhání (s možnou ztrátou dat), obvykle označované jako vynucené převzetí služeb při selhání. Automatické i plánované ruční převzetí služeb při selhání zachová všechna vaše data. Skupina dostupnosti převezme služby při selhání na úrovni repliky dostupnosti. To znamená, že skupina dostupnosti převezme služby při selhání jedné ze svých sekundárních replik (aktuální cíl převzetí služeb při selhání).

Poznámka:

Pokud není nakonfigurovaná detekce stavu na úrovni databáze, problémy na úrovni databáze, jako je například podezření na ztrátu datového souboru, odstranění databáze nebo poškození transakčního protokolu, nezpůsobí převzetí služeb při selhání skupiny dostupnosti.

Během převzetí služeb při selhání převezme cílový systém primární roli, obnoví své databáze a přenese je do online režimu jako nové primární databáze. Bývalá primární replika, pokud je k dispozici, přepne na sekundární roli a její databáze se stanou sekundárními databázemi. Tyto role se můžou potenciálně přepnout zpět (nebo do jiného cíle převzetí služeb při selhání) v reakci na více selhání nebo pro účely správy.

Způsoby převzetí služeb při selhání, které daná replika dostupnosti podporuje, jsou určeny vlastností režimu převzetí služeb při selhání. U dané repliky dostupnosti závisí možné režimy převzetí služeb při selhání na režimu dostupnosti repliky následujícím způsobem:

  • Repliky synchronního potvrzení podporují dvě nastavení: automatické nebo ruční. "AUTOMATICKÉ" nastavení podporuje jak automatické, tak ruční převzetí služeb při selhání. Aby se zabránilo ztrátě dat, automatické převzetí služeb při selhání a plánované převzetí služeb při selhání vyžaduje, aby byl cíl převzetí služeb při selhání synchronní sekundární replikou se stavem synchronizace v pořádku (to znamená, že každá sekundární databáze v cíli převzetí služeb při selhání je synchronizovaná s odpovídající primární databází). Kdykoli sekundární replika nesplňuje obě tyto podmínky, podporuje pouze vynucený failover. Vynucené převzetí služeb při selhání je také podporováno u replik ve stavu ŘEŠENÍ.

  • Repliky asynchronního potvrzení podporují pouze režim ručního převzetí. Kromě toho, protože se nikdy nesynchronizují, podporují pouze vynucené přepnutí při selhání.

Poznámka:

Po přepnutí při selhání se musí klientské aplikace, které potřebují přístup k primárním databázím, připojit k nové primární replice. Pokud je nová sekundární replika nakonfigurovaná tak, aby umožňovala přístup jen pro čtení, klientské aplikace jen pro čtení se k ní můžou připojit. Informace o tom, jak se klienti připojují ke skupině dostupnosti, naleznete v tématu Naslouchací procesy skupiny dostupnosti, připojení klienta a převzetí služeb při selhání aplikací (SQL Server).

Změny SQL Serveru 2025

SQL Server 2025 zavádí následující změny:

Rychlé přepnutí na záložní systém při dlouhodobých problémech se stavem

V prostředí skupiny dostupnosti AlwaysOn monitoruje cluster windows s podporou převzetí služeb při selhání (WSFC) stav skupiny dostupnosti a jejích replik. Když se na primární replice zjistí problém se stavem, služba WSFC aktivuje sekvenci nápravných akcí. ** Ve výchozím nastavení WSFC restartuje prostředek skupiny dostupnosti na aktuální replice. Pokud WSFC nemůže přenést prostředek zpět do režimu online, pak WSFC přesměruje prostředek skupiny dostupnosti na jinou repliku. I když je tato posloupnost nápravných akcí účinná u přechodných selhání, může vést ke zpoždění při přepnutí v případě nepřechodných selhání.

Chování převzetí služeb při selhání WSFC je řízeno hodnotou RestartThreshold. Ve výchozím nastavení je hodnota RestartThreshold pro skupinu dostupnosti Always On nastavena na 1, což znamená, že WSFC se pokusí restartovat prostředek na aktuálním uzlu, před tím než provede převzetí služeb při selhání.

Počínaje SQL Serverem 2025 (17.x) můžete nastavit RestartThreshold pro skupinu dostupnosti Always On na hodnotu 0, což způsobí, že WSFC okamžitě provede převzetí prostředku skupiny dostupnosti, když je zjištěn trvalý problém se stavem. To je užitečné ve scénářích, ve kterých chcete minimalizovat výpadky a zajistit, aby skupina dostupnosti byla vždy dostupná na replikě, která je v pořádku.

Je tu jasný kompromis:

  • RestartThreshold Nastavením na 1 je vaše skupina dostupnosti odolnější vůči přechodným selháním a vrátí se do online režimu rychleji. Avšak v případě trvalých selhání může být failover a doba nečinnosti delší.
  • Nastavením RestartThreshold na 0 se vaše skupina dostupnosti stává méně tolerantní k přechodným selháním, což může vést k zbytečnému převzetí služeb při selhání. V případě trvalých selhání ale může být převzetí služeb při selhání a doba výpadku kratší.

Pomocí Správce clusteru s podporou převzetí služeb při selhání nebo PowerShellu RestartThreshold můžete nastavit prostředek skupiny dostupnosti AlwaysOn.

Pokud chcete například nastavit RestartThreshold hodnotu 0 pro skupinu dostupnosti s názvem ag1, použijte následující příkaz:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

Aktuální nastavení můžete ověřit RestartThreshold spuštěním následujícího příkazu:

Get-ClusterResource -Name "ag1" | Format-List *

Vylepšení odesílání asynchronních požadavků na stránku

Když skupina dostupnosti provede přepnutí při selhání, musí každá replika najít společný bod obnovení, do kterého se má synchronizovat. Bod obnovení udržuje skupinu dostupnosti stabilní, takže může i nadále posílat změny. Vrácení zpět a opakování je součástí tohoto procesu synchronizace. K vrácení zpět dojde, když sekundární replika musí vrátit transakce zpět, aby se dostala do společného bodu obnovení. Při zotavení po havárii (DR) je převzetí služeb při selhání do asynchronní repliky s FAILOVER_ALLOW_DATA_LOSS nejčastěji spojeno s funkcí úpravy redo operací.

V některých situacích, při převzetí služeb v případě selhání, když sekundární replika přechází na primární, má nová primární replika síťovou latenci od původní primární (nové sekundární), což zpomaluje vrácení operace opakování na nové sekundární.

SQL Server 2025 (17.x) zavádí aktualizaci synchronizačního mechanismu ke zlepšení procesu undo-of-redo pro tento scénář, takže nyní skupina dostupnosti provádí požadavky na stránky asynchronně a v dávkách.

Vezměte v úvahu následující skutečnosti:

  • Vylepšení synchronizačního mechanismu je ve výchozím nastavení povolené. Pokud chcete vylepšení zakázat a vrátit se k výchozímu chování, povolte příznak trasování 12348 na všech replikách ve skupině dostupnosti, které jsou aktuálně sekundární nebo které můžou být v budoucnu sekundární.
  • Pokud repliky skupiny dostupnosti nemají latenci sítě, nemusí toto vylepšení zlepšit vrácení zpět.

Databáze se po selhání přepnou do stavu řešení.

Ve vzácných případech může jedna nebo více databází skupiny dostupnosti zůstat ve stavu Nesynchronizující po krátkou dobu kvůli přechodné ztrátě kvora WSFC, například při dočasném odpojení sítě nebo restartování většiny uzlů clusteru. Aktualizace logiky obnovení skupiny dostupnosti zavedená v SQL Serveru 2025 (17.x) vylepšuje interní toleranci k tomuto typu ztráty kvora clusteru a zabraňuje tomu, aby databáze skupin dostupnosti uvízly ve stavu Nesynchronizuje, jakmile se skupina dostupnosti vrátí do režimu online.

Pojmy a definice

Automatické přepnutí při selhání
Převzetí služeb při selhání, ke kterému dojde automaticky při ztrátě primární repliky. Automatické převzetí služeb při selhání se podporuje jen v případech, kdy je aktuální primární a jedna sekundární replika nakonfigurovaná s režimem převzetí služeb při selhání nastaveným na AUTOMATIC a sekundární replika je aktuálně synchronizovaná. Pokud je režim přepnutí primární nebo sekundární repliky 'RUČNÍ', automatické přepnutí nemůže proběhnout.

Plánované ruční přepnutí při selhání (bez ztráty dat)
Plánované ruční převzetí služeb při selhání, nebo ruční převzetí služeb při selhání, je převzetí služeb při selhání iniciované správcem databáze, obvykle pro účely správy. Plánované ruční převzetí služeb při selhání se podporuje jenom v případě, že jsou primární i sekundární replika nakonfigurované pro režim synchronního potvrzení a primární i sekundární replika jsou aktuálně synchronizované (ve stavu SYNCHRONIZOVANÉ). Při synchronizaci cílové sekundární repliky je možné ruční převzetí služeb při selhání (bez ztráty dat) i v případě, že došlo k chybě primární repliky, protože sekundární databáze jsou připravené k převzetí služeb při selhání. Správce databáze ručně zahájí ruční převzetí služeb při selhání.

Vynucené převzetí služeb při selhání (s možnou ztrátou dat)
Převzetí služeb při selhání, které může zahájit správce databáze, pokud není synchronizovaná žádná sekundární replika s primární replikou nebo pokud není spuštěná primární replika a žádná sekundární replika není připravena k převzetí služeb při selhání. Vynucené přepnutí hrozí možné ztráty dat a doporučuje se pouze pro obnovu po katastrofě. Vynucené převzetí při selhání se také označuje jako ruční převzetí, protože je možné ho spustit pouze ručně. Jediným typem převzetí služeb při selhání, který je podporován v asynchronním režimu potvrzení dostupnosti, je tento.

Automatická sada převzetí služeb při selhání

V rámci dané skupiny dostupnosti je pár replik dostupnosti (včetně aktuální primární repliky), které jsou nakonfigurované pro synchronní režim potvrzování s automatickým převzetím úloh při selhání (pokud existuje). Sada automatického převzetí služeb při selhání se projeví pouze v případě, že sekundární replika je aktuálně synchronizována s primární replikou.

Sada přepnutí při selhání synchronního potvrzení

V rámci dané skupiny dostupnosti je sada dvou nebo tří replik dostupnosti (včetně aktuální primární repliky), které jsou nakonfigurované pro režim synchronního potvrzení( pokud existuje). Sada převzetí služeb při selhání se synchronním potvrzením nabývá účinnosti, pouze pokud jsou sekundární repliky nakonfigurované pro ruční režim převzetí služeb při selhání a alespoň jedna sekundární replika je aktuálně SYNCHRONIZOVANÁ s primární replikou.

Celá sada pro zotavení po havárii

V rámci dané skupiny dostupnosti je sada všech replik dostupnosti, jejichž provozní stav je aktuálně ONLINE, bez ohledu na režim dostupnosti a režimu převzetí služeb při selhání. Celá sada převzetí služeb při selhání se stane relevantní, pokud není aktuálně synchronizována žádná sekundární replika s primární replikou.

Přehled převzetí služeb při selhání

Následující tabulka shrnuje, které formy převzetí služeb při selhání jsou podporovány v různých režimech dostupnosti a převzetí služeb při selhání. Pro každý pár je efektivní režim dostupnosti a režim převzetí služeb při selhání určen průsečíkem režimů primární repliky a režimů jedné nebo více sekundárních replik.

Formulář pro převzetí služeb při selhání Režim asynchronního potvrzení Synchronní režim potvrzení s režimem ručního převzetí služeb při selhání Synchronní režim potvrzení s režimem automatického převzetí služeb při selhání
Automatické přepnutí při selhání Ne Ne Ano
Plánované ruční selhání Ne Ano Ano
Vynucené převzetí služeb při selhání Ano Ano Ano1

1 Pokud vydáte příkaz vynuceného převzetí služeb při selhání na synchronizované sekundární replice, sekundární replika se chová stejně jako při ručním převzetí služeb při selhání.

Doba, po kterou je databáze během převzetí při selhání nedostupná, závisí na typu převzetí při selhání a její příčině.

Důležité

Aby bylo možné podporovat připojení klientů po převzetí služeb při selhání, s výjimkou samostatných databází, musí být v nové primární databázi ručně znovu vytvořena přihlášení a úlohy definované na některé z bývalých primárních databází. Další informace najdete v tématu Správa přihlášení a úloh pro databáze skupiny dostupnosti (SQL Server).

Sady převzetí služeb při selhání

Formy převzetí služeb při selhání, které jsou možné pro danou skupinu dostupnosti, lze pochopit pomocí sad těchto převzetí. Sada převzetí služeb při selhání se skládá z primární repliky a sekundárních replik, které podporují danou formu převzetí služeb při selhání:

  • Automatická sada převzetí služeb při selhání (volitelné): V rámci dané skupiny dostupnosti je pár replik dostupnosti (včetně aktuální primární repliky), které jsou nakonfigurované pro synchronní režim potvrzení s automatickým převzetím služeb při selhání( pokud existuje). Sada automatického převzetí služeb při selhání se projeví pouze v případě, že sekundární replika je aktuálně synchronizována s primární replikou.

  • Sada převzetí služeb při selhání synchronního potvrzení (volitelné): V rámci dané skupiny dostupnosti je sada dvou nebo tří replik dostupnosti (včetně aktuální primární repliky), které jsou nakonfigurované pro režim synchronního potvrzení( pokud existuje). Sada převzetí služeb při selhání se synchronním potvrzením nabývá účinnosti, pouze pokud jsou sekundární repliky nakonfigurované pro ruční režim převzetí služeb při selhání a alespoň jedna sekundární replika je aktuálně SYNCHRONIZOVANÁ s primární replikou.

  • Celá sada převzetí služeb při selhání: V rámci dané skupiny dostupnosti je sada všech replik dostupnosti, jejichž provozní stav je aktuálně ONLINE, bez ohledu na režim dostupnosti a režimu převzetí služeb při selhání. Celá sada převzetí služeb při selhání se stane relevantní, pokud není aktuálně synchronizována žádná sekundární replika s primární replikou.

Když nakonfigurujete repliku dostupnosti jako synchronní potvrzení s automatickým převzetím služeb při selhání, replika dostupnosti se stane součástí automatické sady převzetí služeb při selhání. Jestli se však sada skutečně projeví, závisí na aktuálním primáru. Formy převzetí služeb při selhání, které jsou v daném okamžiku skutečně možné, závisí na tom, jaké sady převzetí služeb při selhání aktuálně platí.

Představte si například skupinu dostupnosti, která má čtyři repliky dostupnosti, a to následujícím způsobem:

Replika Režim dostupnosti a nastavení režimu převzetí služeb při selhání
A Synchronní potvrzení s automatickým převzetím při selhání
B Synchronní potvrzení s automatickým převzetím při selhání
C Synchronní potvrzení pouze s plánovaným ručním přepnutím při selhání
D Asynchronní potvrzení (pouze s nuceným převzetím služeb)

Chování převzetí služeb při selhání pro každou sekundární repliku závisí na tom, která replika dostupnosti (availability replica) je aktuálně primární replikou. V podstatě platí, že pro danou sekundární repliku je chování při selhání nejhorším případem vzhledem k aktuální primární replice. Následující obrázek znázorňuje, jak se chování sekundárních replik při selhání liší v závislosti na aktuální primární replice a jestli je nakonfigurovaný pro režim asynchronního potvrzení (pouze s vynuceným převzetím služeb při selhání) nebo režim synchronního potvrzení (s automatickým převzetím služeb při selhání nebo bez něj).

Jak konfigurace primární repliky ovlivňuje převzetí služeb při selhání

Automatické převzetí služeb při selhání

Automatické převzetí služeb při selhání způsobí, že se kvalifikovaná sekundární replika automaticky přepne do primární role, jakmile primární replika přestane být dostupná. Automatické převzetí služeb při selhání je nejvhodnější, pokud je uzel WSFC, který hostí primární repliku, umístěný blízko uzlu, který hostí sekundární repliku. Je to proto, že synchronizace dat funguje nejlépe s nízkou latencí zpráv mezi počítači a protože klientská připojení můžou zůstat místní.

V této části:

Podmínky vyžadované pro automatické převzetí při selhání

Automatické převzetí při selhání probíhá pouze za následujících podmínek:

  • Existuje automatický mechanismus převzetí služeb při selhání. Tato sada se skládá z primární repliky a sekundární repliky ( cíle automatického převzetí služeb při selhání), které jsou nakonfigurovány do režimu synchronního potvrzení a nastaveny na automatické převzetí služeb při selhání. Pokud je primární replika nastavená na RUČNÍ převzetí služeb při selhání, automatické převzetí služeb při selhání nemůže nastat, i když je sekundární replika nastavená na AUTOMATICKÉ převzetí služeb při selhání.

    Další informace najdete v tématu režimy dostupnosti (skupiny dostupnosti AlwaysOn).

  • Cíl automatického převzetí služeb při selhání má stav synchronizace, který je v pořádku (znamená to, že každá sekundární databáze v cíli převzetí služeb při selhání se synchronizuje s odpovídající primární databází).

    Návod

    Skupiny dostupnosti AlwaysOn monitorují stav obou replik v automatické sadě převzetí služeb při selhání. Pokud dojde k selhání některé repliky, stav skupiny dostupnosti je nastavený na KRITICKÝ. Pokud sekundární replika selže, automatické převzetí služeb při selhání není možné, protože cíl automatického převzetí služeb při selhání není k dispozici. Pokud primární replika selže, skupina dostupnosti přesune svou činnost na sekundární repliku. Dokud se předchozí primární replika nevrátí online, neexistuje žádný automatický cíl pro převzetí při selhání. V obou případech doporučujeme kvůli zajištění dostupnosti v nepravděpodobném případě sekvenčního selhání nakonfigurovat jinou sekundární repliku jako cíl automatického převzetí služeb při selhání.

    Další informace najdete v tématu Použití zásad AlwaysOn k zobrazení stavu skupiny dostupnosti (SQL Server) a změně režimu převzetí služeb při selhání repliky dostupnosti (SQL Server).

  • Cluster služby převzetí serveru Windows při selhání (WSFC) má kvorum. Další informace naleznete v tématu režimy kvora a hlasovací konfigurace WSFC (SQL Server).

  • Primární replika se stala nedostupnou a byly splněny úrovně podmínek převzetí služeb při selhání definované vaší flexibilní politikou převzetí služeb při selhání. Informace o úrovních podmínek převzetí služeb při selhání najdete v tématu Flexibilní zásady převzetí služeb při selhání pro automatické převzetí služeb při selhání skupiny dostupnosti (SQL Server).

Jak funguje automatické přebírání služeb při selhání

Automatické převzetí služeb při selhání zahájí následující posloupnost akcí:

  1. Pokud je instance serveru, která je hostitelem aktuální primární repliky, stále spuštěná, změní stav primárních databází na ODPOJENO a odpojí všechny klienty.

  2. Pokud některé záznamy protokolu čekají ve frontách obnovení na cílové sekundární replice, použije sekundární replika zbývající záznamy protokolu k dokončení průběžného předávání sekundárních databází.

    Poznámka:

    Doba potřebná k použití protokolu pro danou databázi závisí na rychlosti systému, nedávném pracovním zatížení a množství protokolu ve frontě obnovení.

  3. Dřívější sekundární replika se stane primární rolí. Její databáze se stanou primárními databázemi. Nová primární replika co nejrychleji vrátí všechny nepotvrzené transakce (fáze obnovy). Tato uzamčení izolují nepotvrzené transakce a umožňují jejich vrácení na pozadí, zatímco klienti používají databázi. Tento proces nevrací žádné potvrzené transakce.

    Dokud není daná sekundární databáze připojená, bude krátce označena jako NOT_SYNCHRONIZED. Před zahájením obnovení zpět se sekundární databáze mohou připojit k novým primárním databázím a rychle přejít do synchronizovaného stavu. Nejlepším scénářem je obvykle třetí synchronně potvrzující replika, která zůstává v sekundární roli po přepnutí při selhání.

  4. Později, když se instance serveru, která byla hostitelem bývalé primární repliky, restartuje, rozpozná, že primární roli nyní vlastní jiná dostupnostní replika. Bývalá primární replika přechází na sekundární roli a její databáze se stanou sekundárními databázemi. Nová sekundární replika se připojí k aktuální primární replice a co nejrychleji sladí svou databázi s aktuálními primárními databázemi. Jakmile nová sekundární replika znovu synchronizuje své databáze, převzetí služeb při selhání je opět možné v opačném směru.

Konfigurace automatického přepnutí při selhání

Repliku dostupnosti je možné nakonfigurovat tak, aby podporovala automatické převzetí služeb při selhání v jakémkoli okamžiku.

Konfigurace automatického převzetí služeb při selhání

  1. Ujistěte se, že je sekundární replika nakonfigurovaná tak, aby používala režim dostupnosti synchronního potvrzení. Další informace najdete v tématu Změna režimu dostupnosti repliky (SQL Server).

  2. Nastavte režim převzetí služeb při selhání na automatický. Další informace najdete v tématu Změna režimu převzetí služeb při selhání repliky dostupnosti (SQL Server).

  3. Volitelně můžete změnit flexibilní zásady převzetí služeb při selhání skupiny dostupnosti a určit tak typy selhání, které můžou způsobit, že dojde k automatickému převzetí služeb při selhání. Další informace najdete v tématu Konfigurace flexibilních zásad převzetí služeb při selhání pro řízení podmínek pro automatické převzetí služeb při selhání (skupiny dostupnosti AlwaysOn) a zásady převzetí služeb při selhání pro instance clusteru s podporou převzetí služeb při selhání.

Plánované ruční selhání (bez ztráty dat)

Ruční převzetí služeb při selhání způsobí, že synchronizovaná sekundární replika přejde na primární roli poté, co správce databáze vydá příkaz ručního převzetí služeb při selhání v instanci serveru, která je hostitelem cílové sekundární repliky. Aby bylo možné podporovat ruční převzetí služeb při selhání, musí být sekundární replika i aktuální primární replika nakonfigurované pro režim synchronního potvrzení, pokud existuje. Každá sekundární databáze repliky dostupnosti musí být připojená ke skupině dostupnosti a synchronizovaná s odpovídající primární databází (to znamená, že sekundární replika musí být synchronizovaná). To zaručuje, že každá transakce potvrzená v bývalé primární databázi byla potvrzena také na nové primární databázi. Proto jsou nové primární databáze identické se starými primárními databázemi.

Následující obrázek znázorňuje fáze plánovaného přepnutí při selhání.

  1. Před převzetím služeb při selhání je primární replika hostovaná instancí serveru na Node01.

  2. Správce databáze zahájí plánované přepnutí. Cílem převzetí služeb při selhání je replika dostupnosti hostovaná instancí serveru na Node02.

  3. Cílová adresa pro převzetí služeb při selhání (Node02) se stane novou primární replikou. Vzhledem k tomu, že se jedná o plánované převzetí při selhání, bývalá primární replika se během převzetí přepne na sekundární roli a její databáze se okamžitě aktivují jako sekundární databáze.

Ilustrace plánovaného ručního převzetí služeb při selhání

V této části:

Podmínky vyžadované pro ruční převzetí služeb v případě selhání

Aby bylo možné podporovat ruční převzetí služeb při selhání, musí být aktuální primární replika nastavena na režim synchronního potvrzování a sekundární replika musí být:

  • Nakonfigurováno pro synchronní režim potvrzení.

  • Aktuálně se synchronizuje s primární replikou.

Pokud chcete ručně převzít službu ve skupině dostupnosti, musíte být připojeni k sekundární replice, která se stane novou primární replikou.

Jak funguje plánované ruční přepnutí při výpadku

Plánovaný manuální přesun, který je nutné zahájit na cílové sekundární replice, zahájí následující posloupnost akcí:

  1. Aby se zajistilo, že v původních primárních databázích nedojde k žádným novým uživatelským transakcím, cluster WSFC odešle požadavek na přechod do režimu offline primární repliky.

  2. Pokud nějaký protokol čeká ve frontě obnovení jakékoli sekundární databáze, sekundární replika dokončí průběžné předávání této sekundární databáze. Doba potřebná závisí na rychlosti systému, nedávné pracovní zátěži a množství logů ve frontě obnovení. Pokud chcete zjistit aktuální velikost fronty obnovení, použijte čítač výkonu fronty obnovení . Další informace naleznete v tématu SQL Server, replika databáze.

    Poznámka:

    Čas přepnutí při selhání je možné regulovat omezením velikosti fronty obnovení. To ale může způsobit zpomalení primární repliky, aby sekundární replika zůstala vzhůru.

  3. Sekundární replika se stane novou primární replikou a bývalá primární replika se stane novou sekundární replikou.

  4. Nová primární replika vrátí zpět všechny nepotvrzené transakce a přenese své databáze do online režimu jako primární databáze. Všechny sekundární databáze jsou krátce označené jako NESYNCHRONIZOVANÉ, dokud se nepřipojí a znovu nesynchronizují s novými primárními databázemi. Tento proces nevrací žádné potvrzené transakce.

  5. Když se bývalá primární replika vrátí do režimu online, převezme sekundární roli a bývalá primární databáze se stane sekundární databází. Nová sekundární replika rychle znovu synchronizuje nové sekundární databáze s odpovídajícími primárními databázemi.

    Poznámka:

    Jakmile nová sekundární replika resynchronizuje databáze, převzetí služeb při selhání je opět možné, ale v opačném směru.

Po přepnutí na záložní databázi se klienti musí znovu připojit k aktuální primární databázi. Další informace najdete v tématu Posluchače skupin dostupnosti, připojení klientů a převzetí služeb při selhání aplikace (SQL Server).

Zachování dostupnosti během upgradů

Správce databáze pro vaše skupiny dostupnosti může použít ruční převzetí služeb při selhání k udržení dostupnosti databáze při upgradu hardwaru nebo softwaru. Chcete-li použít skupinu dostupnosti pro upgrady softwaru, instance serveru a/nebo uzel počítače, který hostí cílovou sekundární repliku, musí již mít nainstalované upgrady. Další informace najdete v tématu Aktualizace instancí replik Always On skupiny dostupnosti.

Vynucené převzetí služeb po selhání (s případnou ztrátou dat)

Vynucení převzetí služeb při selhání skupiny dostupnosti (s možnou ztrátou dat) je metoda zotavení po havárii, která umožňuje použít sekundární repliku jako záložní server v pohotovostním stavu. Protože vynucené převzetí služeb může riskovat ztrátu dat, mělo by se používat opatrně a střídmě. Doporučujeme vynucovat převzetí služeb při selhání pouze tehdy, když potřebujete okamžitě obnovit službu ve svých databázích dostupnosti a jste ochotni riskovat ztrátu dat. Další informace o požadavcích a doporučeních pro vynucení převzetí služeb při selhání a ukázkovém scénáři, který používá vynucené převzetí služeb při selhání k zotavení z závažného selhání, najdete v tématu Provedení vynuceného ručního převzetí služeb při selhání skupiny dostupnosti (SQL Server).

Výstraha

Vynucení přepnutí při selhání vyžaduje, aby cluster WSFC měl kvorum. Informace o konfiguraci kvora a nuceném nastavování kvora naleznete v tématu Windows Server Failover Clustering (WSFC) s SQL Serverem.

V této části:

Jak vynucené převzetí služeb při selhání funguje

Vynucené převzetí služeb při selhání zahájí přechod primární role na cílovou repliku, jejíž role je ve stavu SEKUNDÁRNÍ nebo ŘEŠENÍ. Cíl při selhání se stane novou primární replikou a okamžitě poskytuje klientům kopie svých databází. Jakmile bude bývalá primární replika dostupná, přejde na sekundární roli a její databáze se stanou sekundárními databázemi.

Všechny sekundární databáze (včetně bývalých primárních databází, jakmile budou k dispozici) jsou pozastavené. V závislosti na stavu předchozí synchronizace dat pozastavené sekundární databáze může být vhodné pro záchranu chybějících potvrzených dat pro danou primární databázi. Na sekundární replice, která je nakonfigurovaná pro přístup jen pro čtení, můžete sekundární databáze dotazovat, aby ručně zjišťovala chybějící data. Potom můžete vydat příkazy Transact-SQL v nových primárních databázích, aby bylo možné provést potřebné změny.

Rizika vynucení převzetí služeb při selhání

Je nezbytné pochopit, že vynucení převzetí služeb při selhání může způsobit ztrátu dat. Ztráta dat je možná, protože cílová replika nemůže komunikovat s primární replikou, a proto nemůže zaručit synchronizaci databází. Vynucení převzetí služeb při selhání spustí novou větev obnovení. Vzhledem k tomu, že původní primární databáze a sekundární databáze jsou na různých větvích obnovení, každá z nich nyní obsahuje data, která druhá databáze neobsahuje: původní primární databáze obsahuje změny, které se ještě neodeslaly z fronty pro odeslání do bývalé sekundární databáze (neodeslaný log); bývalé sekundární databáze obsahují jakékoli změny, ke kterým dojde po vynucení failoveru.

Pokud je převzetí služeb při selhání vynuceno, protože primární replika selhala, potenciální ztráta dat závisí na tom, zda byly do sekundární repliky před selháním odeslány nějaké transakční protokoly. V režimu asynchronního potvrzení vždy existuje možnost kumulovaných neodeslaných záznamových logů. V režimu synchronního potvrzení je to možné jenom do synchronizace sekundárních databází.

Následující tabulka shrnuje riziko ztráty dat pro konkrétní databázi na replice, na kterou vynutíte převzetí služeb v případě selhání.

Režim dostupnosti sekundární repliky Je databáze synchronizovaná? Je možné ztráty dat?
Synchronní potvrzení Ano Ne
Synchronní potvrzení Ne Ano
Asynchronní zápis Ne Ano

Sekundární databáze sledují pouze dvě forky obnovení, takže pokud provedete více vynucených převzetí služeb při selhání, nemusí být možné obnovit jakoukoli sekundární databázi, která spustila synchronizaci dat s předchozím vynuceným převzetím služeb při selhání. Pokud k tomu dojde, bude nutné odebrat sekundární databáze, které nelze obnovit, ze skupiny dostupnosti, obnovit správný bod v čase a znovu se připojit ke skupině dostupnosti. V tomto scénáři může dojít k chybě 1408 se stavem 103 (chyba: 1408, závažnost: 16, stav: 103). Obnovení nebude fungovat napříč různými větveními obnovení, proto nezapomeňte provést zálohu protokolu po provedení více než jednoho vynuceného převzetí služeb při selhání.

Proč je vyžadováno vynucené přepnutí po vynucení kvora

Po vynucení kvora v clusteru WSFC (vynucené kvorum) musíte u každé skupiny dostupnosti provést vynucené převzetí služeb při selhání (s možnou ztrátou dat). Vynucené převzetí služeb při selhání je nezbytné, protože skutečný stav hodnot clusteru WSFC mohl být ztracen. Zabránění běžným scénářům převzetí služeb při selhání po vynuceném dosažení kvorum je nutné z důvodu, že se v překonfigurovaném clusteru WSFC může objevit nesynchronizovaná sekundární replika, která se jeví jako synchronizovaná.

Představte si například cluster WSFC, který hostuje skupinu dostupnosti na třech uzlech: Uzel A hostuje primární repliku a uzel B a uzel C, každý hostuje sekundární repliku. Uzel C se při synchronizaci místní sekundární repliky odpojí od clusteru WSFC. Node A a Node B ale zachovají v pořádku kvorum a skupina dostupnosti zůstává online. Na uzlu A primární replika nadále přijímá aktualizace a na uzlu B sekundární replika se bude dál synchronizovat s primární replikou. Sekundární replika na uzlu C se stane nesynchronizovanou a stále více zaostává za primární replikou. Vzhledem k tomu, že je uzel C odpojen, zůstane replika nesprávně ve stavu SYNCHRONIZOVÁNO.

Pokud je kvórum ztraceno a poté vynuceno na uzlu A, měl by být stav synchronizace skupiny dostupnosti v clusteru WSFC správný, přičemž sekundární replika na uzlu C se zobrazí jako NESYNCHRONIZOVANÁ. Pokud je však kvorum vynucené v uzlu C, synchronizace skupiny dostupnosti bude nesprávná. Stav synchronizace v clusteru se vrátí zpět do doby, kdy byl uzel C odpojen, s tím, že sekundární replika na uzlu C bude nesprávně zobrazena jako SYNCHRONIZOVANÁ. Vzhledem k tomu, že plánované ruční převzetí služeb při selhání zaručuje bezpečnost dat, jsou nepovolené, aby se skupina dostupnosti po vynucení kvora vrátila do online režimu.

Sledování potenciální ztráty dat

Pokud má cluster WSFC kvorum v pořádku, můžete odhadnout aktuální potenciál ztráty dat v databázích. U dané sekundární repliky aktuální potenciál ztráty dat závisí na tom, jak daleko místní sekundární databáze zaostává za odpovídajícími primárními databázemi. Vzhledem k tomu, že se prodleva v průběhu času liší, doporučujeme pravidelně sledovat potenciální ztrátu dat pro nesynchronizované sekundární databáze. Sledování zpoždění zahrnuje porovnání LSN posledního potvrzení a času posledního potvrzení pro každou primární databázi a její sekundární databáze následujícím způsobem:

  1. Připojte se k primární replice.

  2. Proveďte dotaz na sloupce last_commit_lsn (LSN poslední potvrzené transakce) a last_commit_time (čas posledního potvrzení) v dynamické spravovací zobrazení sys.dm_hadr_database_replica_states.

  3. Porovnejte hodnoty vrácené pro každou primární databázi a každou z jejích sekundárních databází. Rozdíl mezi LSN posledního potvrzení naznačuje míru zpoždění.

  4. Výstrahu můžete aktivovat, když množství prodlevy v databázi nebo sadě databází překročí požadovanou maximální prodlevu po danou dobu. Dotaz může například spustit úloha, která se spouští každou minutu v každé primární databázi. Pokud rozdíl mezi last_commit_time primární databáze a některou z jejích sekundárních databází překročil cíl bodu obnovení (RPO) (například 5 minut) od posledního spuštění úlohy, může úloha vyvolat výstrahu.

Důležité

Pokud cluster WSFC nemá kvorum nebo bylo kvorum vynuceno, last_commit_lsn a last_commit_time mají hodnotu NULL. Informace o tom, jak se můžete po vynuceném kvoru vyhnout ztrátě dat, najdete v tématu "Potenciální způsoby, jak se vyhnout ztrátě dat po vynucení kvora" v části Provedení vynuceného ručního převzetí služeb při selhání skupiny dostupnosti (SQL Server).

Správa potenciální ztráty dat

Po vynucení převzetí služeb při selhání se pozastaví všechny sekundární databáze. To zahrnuje bývalé primární databáze, jakmile se bývalá primární replika vrátí do režimu online a zjistí, že se jedná o sekundární repliku. Na každé sekundární replice je nutné ručně obnovit každou pozastavenou databázi.

Jakmile je bývalá primární replika k dispozici, za předpokladu, že jsou její databáze nepoškozené, můžete se pokusit spravovat potenciální ztrátu dat. Dostupný přístup ke správě potenciální ztráty dat závisí na tom, jestli se původní primární replika připojila k nové primární replice. Za předpokladu, že původní primární replika má přístup k nové primární instanci, dojde k automatickému a transparentnímu připojení.

Původní primární replika se znovu připojila.

Obvykle se po selhání restartuje původní primární replika, která se rychle znovu připojí ke svému partnerovi. Při opětovném připojení se původní primární replika stane sekundární replikou. Jeho databáze se stanou sekundárními databázemi a vstoupí do stavu SUSPENDED. Nové sekundární databáze nebudou vráceny zpět, pokud je neobnovíte.

Pozastavené databáze jsou však nedostupné, takže je nemůžete zkontrolovat a vyhodnotit, jaká data by se ztratila, pokud byste měli obnovit danou databázi. Rozhodnutí o obnovení nebo odebrání sekundární databáze proto závisí na tom, jestli jste ochotni přijmout jakoukoli ztrátu dat:

  • Pokud by ztráta dat byla nepřijatelná, měli byste odebrat databáze ze skupiny dostupnosti, abyste je zachránili.

    Správce databáze teď může obnovit bývalé primární databáze a pokusit se obnovit data, která by byla ztracena. Pokud je ale bývalá primární databáze online, liší se od aktuální primární databáze, takže správce databáze musí znepřístupnit odebranou databázi nebo aktuální primární databázi klientům, aby zabránil dalším rozdílům v databázích a aby zabránil problémům s převzetím služeb při selhání klienta.

  • Pokud by ztráta dat byla přijatelná pro vaše obchodní cíle, můžete obnovit sekundární databáze.

    Obnovení nové sekundární databáze způsobí, že se vrátí zpět jako první krok při synchronizaci databáze. Pokud v době selhání čekají nějaké záznamy protokolu ve frontě pro odesílání, dojde ke ztrátě odpovídajících transakcí, i když byly potvrzeny.

Původní primární replika se znovu nepřipojila.

Pokud můžete dočasně zabránit opětovnému připojení původní primární repliky přes síť k nové primární replice, můžete zkontrolovat původní primární databáze a vyhodnotit, jaká data by se ztratila, pokud by byla obnovena.

  • Pokud je potenciální ztráta dat přijatelná

    Umožňuje, aby se původní primární replika znovu připojila k nové primární replice. Opětovné připojení způsobí pozastavení nových sekundárních databází. Pokud chcete spustit synchronizaci dat v databázi, jednoduše ji obnovte. Nová sekundární replika zahodí původní fork obnovení pro danou databázi a ztratí všechny transakce, které nebyly nikdy odeslány nebo přijaty bývalou sekundární replikou.

  • Pokud je ztráta dat nepřijatelná

    Pokud původní primární databáze obsahuje kritická data, která by byla ztracena, pokud obnovíte pozastavenou databázi, můžete zachovat data v původní primární databázi odebráním ze skupiny dostupnosti. To způsobí, že databáze přejde do stavu obnovování. V této fázi doporučujeme, abyste se pokusili zálohovat závěrečnou část protokolu odebrané databáze. Aktuální primární databázi (bývalou sekundární databázi) pak můžete aktualizovat tak, že exportujete data, která chcete obnovit z původní primární databáze, a naimportujete ji do aktuální primární databáze. Doporučujeme co nejrychleji provést úplnou zálohu databáze aktualizované primární databáze.

    Potom v instanci serveru, která je hostitelem nové sekundární repliky, můžete odstranit pozastavenou sekundární databázi a vytvořit novou sekundární databázi obnovením této zálohy (a nejméně jedné následné zálohy protokolu) pomocí funkce RESTORE WITH NORECOVERY. Doporučujeme pozdržet další zálohy protokolů aktuálních primárních databází, dokud nebudou obnoveny odpovídající sekundární databáze.

Výstraha

Trunkace transakčního protokolu v primární databázi se zpozdí, pokud je některá z jejích sekundárních databází pozastavená. Stav synchronizace sekundární repliky s potvrzením synchronního potvrzení se nemůže převést na STAV ZDRAVÍ, pokud zůstane pozastavená jakákoliv místní databáze.

Související obsah

Konfigurace chování převzetí služeb při selhání

Provedení ručního převzetí služeb při selhání

Upravit konfiguraci kvora WSFC

  • Last updated on