Sdílet prostřednictvím

Provedení vynuceného ručního převzetí služeb při selhání skupiny dostupnosti AlwaysOn (SQL Server)

  • Článek

platí pro:SQL Server

Toto téma popisuje, jak provést vynucené převzetí služeb při selhání (s možnou ztrátou dat) ve skupině dostupnosti AlwaysOn pomocí aplikace SQL Server Management Studio, Transact-SQL nebo PowerShellu na SQL Serveru. Vynucené převzetí služeb při selhání je forma ručního převzetí služeb při selhání, která je určená výhradně pro zotavení po havárii, pokud není možné plánované ruční převzetí služeb při selhání. Pokud vynutíte převzetí služeb při selhání na nesynchronizovanou sekundární repliku, je možná nějaká ztráta dat. Proto důrazně doporučujeme vynutit převzetí služeb při selhání pouze v případě, že službu musíte okamžitě obnovit do skupiny dostupnosti a jste ochotni riskovat ztrátu dat.

Po vynuceném převzetí služeb při selhání se cílový server, na který byla skupina dostupnosti převedena, stane novou primární replikou. Sekundární databáze ve zbývajících sekundárních replikách jsou pozastavené a musí být obnoveny ručně. Jakmile bude bývalá primární replika k dispozici, přejde do sekundární role, což způsobí, že se bývalé primární databáze stanou sekundárními databázemi a přecházejí do stavu SUSPENDED. Než obnovíte danou sekundární databázi, můžete z ní obnovit ztracená data. Všimněte si však, že zkrácení transakčního protokolu je u dané primární databáze zpožděné, zatímco některé z jejích sekundárních databází jsou pozastavené.

Důležitý

Synchronizace dat s primární databází nebude probíhat, dokud nebude obnovena sekundární databáze. Informace o obnovení sekundární databáze najdete v tématu Pokračování: Základní úlohy po vynuceném převzetí služeb při selhání v další části tohoto článku.

Vynucené převzetí služeb při selhání je nezbytné v následujících nouzových situacích:

  • Po vynucení kvora v clusteru WSFC (vynucené kvorum) musíte vynutit převzetí služeb při selhání každé skupiny dostupnosti (s možnou ztrátou dat). Vynucení převzetí služeb při selhání je vyžadováno, protože mohl dojít ke ztrátě skutečného stavu hodnot clusteru WSFC. Pokud ale můžete vynutit převzetí služeb při selhání v instanci serveru, která je hostitelem repliky, která byla primární replikou před vynuceným kvorem nebo do sekundární repliky synchronizované před vynuceným kvorem, můžete se vyhnout ztrátě dat. Další informace najdete v tématu Potenciální způsoby, jak se vyhnout ztrátě dat po vynucení kvora, dále v tomto tématu.

    Důležitý

    Pokud se kvorum znovu obnoví přirozeným způsobem místo vynucení, repliky dostupnosti projdou normálním obnovením. Pokud primární replika po obnovení kvora stále není dostupná, můžete provést plánované ruční převzetí na synchronizovanou sekundární repliku.

    cs-CZ: Pro informace o vynucení kvóra naleznete téma Obnova systému WSFC po havárii pomocí vynuceného kvóra (SQL Server). Informace o tom, proč se po vynucení kvora vyžaduje vynucení převzetí služeb při selhání, najdete v tématu režimy převzetí služeb při selhání a převzetí služeb při selhání (skupiny dostupnosti AlwaysOn).

  • Pokud se primární replika stane nedostupnou za předpokladu, že cluster WSFC má platné kvórum, můžete vynutit přechod (s možnou ztrátou dat) na libovolnou repliku, jejíž role je ve stavu SEKUNDÁRNÍ nebo ŘEŠÍCÍ. Pokud je to možné, vynuťte převzetí služeb při selhání na sekundární repliky s potvrzováním synchronním režimem, která byla synchronizovaná, když došlo ke ztrátě primární repliky.

    Spropitné

    Když má cluster WSFC zdravé kvorum, a vydáte příkaz k vynucenému převzetí služeb při selhání na synchronizované sekundární replice, replika provede plánované ruční převzetí služeb při selhání.

Poznámka

Další informace o požadavcích a doporučeních pro vynucení převzetí služeb při selhání a o ukázkovém scénáři, který používá vynucené převzetí k obnově po katastrofickém selhání, naleznete v článku scénář použití: Vynucené převzetí k obnově po katastrofickém selhání , později v tomto tématu.

Omezení a restrikce

  • Jediný čas, kdy nemůžete provést vynucené převzetí služeb při selhání, je, že clustering s podporou převzetí služeb při selhání Windows Serveru (WSFC) nemá kvorum.

  • Ztráta dat je možná během vynuceného překlopení skupiny dostupnosti. Kromě toho platí, že pokud je při zahájení vynuceného převzetí služeb při selhání spuštěna primární replika, můžou být klienti stále připojení k bývalým primárním databázím. Proto důrazně doporučujeme vynucené převzetí při selhání pouze v případě, že primární replika už není spuštěná a pokud jste ochotni riskovat ztrátu dat pro obnovení přístupu k databázím ve skupině dostupnosti.

  • Pokud je sekundární databáze ve stavu VRÁCENÍ nebo INICIALIZACE, vynucení převzetí služeb při chybě způsobí, že se databáze nespustí jako primární. Pokud byla databáze ve stavu INICIALIZACE, budete muset použít chybějící záznamy protokolu ze zálohy databáze nebo plně obnovit databázi úplně od začátku. Pokud byla databáze ve stavu REVERTOVÁNÍ, budete muset databázi plně obnovit ze záloh.

  • Příkaz převzetí služeb při selhání se vrátí, jakmile cíl převzetí služeb při selhání přijme tento příkaz. Obnovení databáze však probíhá asynchronně poté, co skupina dostupnosti dokončí převzetí služeb při selhání.

  • Při převzetí služeb při selhání nemusí být zachována konzistence napříč databázemi v rámci skupiny dostupnosti.

    Poznámka

    Podpora napříč databázemi a distribuovanými transakcemi se liší podle verzí SQL Serveru a operačního systému. Další informace naleznete v tématu transakce mezi databázemi a distribuované transakce pro skupiny dostupnosti AlwaysOn a zrcadlení databáze (SQL Server).

Požadavky

Doporučení

  • Nevynucujte převzetí služeb při selhání, pokud je primární replika stále spuštěná.

  • Pokud je to možné, vynuťte převzetí služeb při selhání pouze do cílového bodu, jehož sekundární databáze jsou ve stavu NESYNCHRONIZOVÁNO, SYNCHRONIZOVÁNO, nebo SYNCHRONIZUJÍCÍ. Informace o dopadech vynucení převzetí služeb při selhání, pokud je sekundární databáze ve stavu inicializace nebo vrácení zpět, najdete v části Omezení a omezení použití, uvedené výše v tomto tématu.

  • Latence dané sekundární databáze vzhledem k primární databázi by se obvykle měla podobat různým sekundárním replikám asynchronního potvrzení. Když však dojde k vynucenému převzetí služeb při selhání, může být ztráta dat významným problémem. Proto zvažte věnovat čas určení relativní latence kopií databází na různých sekundárních replikách. Pokud chcete zjistit, která kopie dané sekundární databáze má nejmenší prodlevu, porovnejte jejich LSN na konci logu. Vyšší hodnota LSN koncového protokolu znamená nižší latenci.

    Spropitné

    Pokud chcete porovnat LSN koncového záznamu, připojte se ke každé online sekundární replice postupně a proveďte dotaz na sys.dm_hadr_database_replica_states pro hodnotu end_of_log_lsn každé místní sekundární databáze. Poté porovnejte koncové LSNy protokolu různých kopií každé databáze. Všimněte si, že různé databáze mohou mít nejvyšší LSN na různých sekundárních replikách. V takovém případě nejvhodnější cíl pro převzetí služeb při selhání závisí na relativní důležitosti, kterou přikládáte datům v různých databázích. To znamená, pro kterou z těchto databází byste chtěli nejvíce minimalizovat možnou ztrátu dat?

  • Pokud se klienti můžou připojit k původnímu primárnímu serveru, vynucené převzetí služeb při selhání způsobuje určité riziko rozděleného chování mozku. Před vynucením převzetí služeb při selhání doporučujeme důrazně zabránit klientům v přístupu k původní replice primárního systému. Jinak se po vynucení převzetí služeb při selhání mohou původní primární databáze a aktuální primární databáze aktualizovat nezávisle na ostatních databázích.

Potenciální způsoby, jak předcházet ztrátě dat po vynucení kvora

Za určitých podmínek selhání po ztrátě kvora se můžete vyhnout ztrátě dat následujícím způsobem:

  • Pokud je původní primární replika online

    Pokud dojde ke ztrátě kvora a obnovení kvora WSFC obnoví uzel clusteru, který hostí primární repliku skupiny dostupnosti, můžete předejít ztrátě dat pro tuto skupinu dostupnosti. Připojte se k primární replice a proveďte vynucené převzetí rolí při selhání (FAILOVER_ALLOW_DATA_LOSS). Tím se primární replika vrátí do režimu online. Protože uskutečňujete vynucené převzetí služeb při selhání u původní primární repliky, nedojde ke ztrátě dat.

  • Pokud se synchronizovaná sekundární replika s potvrzením synchronizace připojí online

    Pokud dojde ke ztrátě kvora a vynucené obnovení kvora WSFC obnoví uzel clusteru, který je hostitelem synchronizované sekundární repliky pro skupinu dostupnosti, měli byste být schopni zabránit ztrátě dat pro tuto skupinu dostupnosti. Pokud byl obnovený uzel aktivní v době, kdy došlo ke ztrátě kvora, můžete určit, zda by mohlo dojít ke ztrátě dat v dané databázi dotazem na sloupec is_failover_ready v zobrazení dynamické správy sys.dm_hadr_database_replica_cluster_states. Například pro instanci serveru s názvem sql108w2k8r22zadejte následující dotaz:

    SELECT * FROM sys.dm_hadr_database_replica_cluster_states  
   WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas   
      WHERE replica_server_name ='sql108w2k8r22')

    Opatrnost

    Pokud obnovený uzel nebyl v provozu v době ztráty kvora, is_failover_ready nemusí odrážet skutečný stav clusteru v době, kdy primární replika přešla do režimu offline. Proto je hodnota is_failover_ready dobrá pouze v případě, že hostitelský uzel je v době selhání v pořádku. Další informace najdete v tématu "Proč je vyžadováno vynucené přepnutí při selhání po vynucení kvora" v části Přepínání a režimy přepínání (skupiny dostupnosti Always On).

    Pokud is_failover_ready = 1, databáze se označí jako synchronizovaná v clusteru a je připravená k převzetí služeb při selhání. Pokud is_failover_ready = 1 pro každou databázi na dané sekundární replice, můžete provést vynucené převzetí služeb při selhání (FORCE_FAILOVER_ALLOW_DATA_LOSS) bez ztráty dat na této sekundární replice. Synchronizovaná sekundární replika je v primární roli online, tzn. jako nová primární replika se všemi daty beze změny.

    Pokud is_failover_ready = 0, databáze není v clusteru označena jako synchronizovaná a není není připravená na plánované ruční převzetí služeb při selhání. Pokud vynutíte převod služeb při chybě sekundární replikou hostitele, budou data v této databázi ztracena.

    Poznámka

    Když vynutíte převzetí služeb při selhání sekundární repliky, bude ztráta dat záviset na tom, jak daleko cíl převzetí služeb při selhání za primární replikou zaostává. Bohužel, v případě, že cluster WSFC nemá kvorum nebo bylo kvorum vynuceno, nemůžete posoudit možnou ztrátu dat. Mějte však na paměti, že jakmile klastr WSFC obnoví zdravé kvorum, můžete začít monitorovat možnou ztrátu dat. Další informace najdete v tématu Sledování potenciální ztráty dat v režimech převzetí služeb při selhání a převzetí služeb při selhání (skupiny dostupnosti AlwaysOn).

Dovolení

Vyžaduje oprávnění ALTER AVAILABILITY GROUP pro skupinu dostupnosti, oprávnění CONTROL AVAILABILITY GROUP, oprávnění ALTER ANY AVAILABILITY GROUP, nebo oprávnění CONTROL SERVER.

Použití aplikace SQL Server Management Studio

Přinutit k převzetí služeb při selhání (i za cenu možné ztráty dat)

  1. V Průzkumníku objektů se připojte k instanci serveru, která hostí repliku, jehož role je ve stavu SEKUNDÁRNÍ nebo ŘEŠENÍ ve skupině dostupnosti, která potřebuje převzít služby při selhání, a rozbalte strom serveru.

  2. Rozbalte uzel AlwaysOn s vysokou dostupností a uzel skupiny dostupnosti .

  3. Klikněte pravým tlačítkem na skupinu dostupnosti, kterou chcete převzít při selhání, a vyberte příkaz Převzetí při selhání.

  4. Tím se spustí Průvodce skupinou dostupnosti převzetí služeb při selhání. Další informace naleznete v tématu Použití průvodce pro převzetí služeb při selhání skupiny dostupnosti (SQL Server Management Studio).

  5. Po vynucení převzetí služeb při selhání skupiny dostupnosti proveďte nezbytné následné kroky. Další informace naleznete v tématu Pokračování: Základní úlohy po vynuceném převzetí služeb při selhání, dále v tomto tématu.

Použití Transact-SQL

K vynucení převzetí služeb při selhání (s možnou ztrátou dat)

  1. Připojte se k instanci serveru, která je hostitelem repliky, jejíž role je ve stavu SEKUNDÁRNÍ nebo ŘEŠENÍ ve skupině dostupnosti, která potřebuje přepnutí při selhání.

  2. Použijte příkaz ALTER AVAILABILITY GROUP následujícím způsobem:

    ALTER AVAILABILITY GROUP název_skupiny FORCE_FAILOVER_ALLOW_DATA_LOSS

    kde group_name je název skupiny dostupnosti.

    Následující příklad vynutí přechod skupiny dostupnosti AccountsAG na místní sekundární repliku.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

  3. Po vynucení převzetí služeb při selhání v rámci skupiny dostupnosti proveďte nezbytné následné kroky. Další informace naleznete v části Následné kroky: Základní úlohy po vynuceném převzetí služeb při selhání, později v tomto tématu.

Použití PowerShellu

vynucení přepnutí na záložní systém (s možnou ztrátou dat)

  1. Změňte adresář (cd) na instanci serveru, která je hostitelem repliky ve stavu SEKUNDÁRNÍ nebo ŘEŠENÍ v rámci skupiny dostupnosti, kterou je potřeba převzít při selhání.

  2. Použijte rutinu Switch-SqlAvailabilityGroup s parametrem AllowDataLoss v jednom z následujících formulářů:

    • -AllowDataLoss

      Ve výchozím nastavení parametr -AllowDataLoss způsobí, že Switch-SqlAvailabilityGroup vás bude upozorňovat, že vynucení převzetí služeb při selhání může vést ke ztrátě nepotvrzených transakcí, a požádá vás o potvrzení. Chcete-li pokračovat, zadejte Y; pokud chcete operaci zrušit, zadejte N.

      Následující příklad provede vynucené převzetí služeb při selhání (s možnou ztrátou dat) skupiny dostupnosti MyAg na sekundární repliku na instanci serveru SecondaryServer\InstanceNames názvem. Zobrazí se výzva k potvrzení této operace.

      Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss

    • -AllowDataLoss-Force

      Pokud chcete zahájit nucené převzetí služeb při selhání bez potvrzení, zadejte parametry -AllowDataLoss a -Force. To je užitečné, pokud chcete zahrnout příkaz do skriptu a spustit ho bez zásahu uživatele. Použijte však možnost -Force s opatrností, protože vynucené převzetí služeb při selhání může vést ke ztrátě dat z databází, které se účastní skupiny dostupnosti.

      Následující příklad provede nucené přepnutí při selhání (s možnou ztrátou dat) skupiny dostupnosti MyAg na serverovou instanci s názvem SecondaryServer\InstanceName. Možnost -Force potlačí potvrzení této operace.

      Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss -Force

    Poznámka

    Pokud chcete zobrazit syntaxi rutiny, použijte rutinu Get-Help v prostředí SQL Server PowerShell. Další informace najdete v tématu Získání nápovědy k SQL Serveru PowerShell.

  3. Po vynucení převzetí služeb při selhání skupiny dostupnosti proveďte nezbytné následné kroky. Další informace najdete v tématu Sledování: Základní úlohy po vynuceném převzetí služeb při selhání, dále v tomto tématu.

Nastavení a použití poskytovatele SQL Serveru PowerShellu

Následné kroky: Základní úkoly po vynuceném převzetí po selhání

  1. Po vynuceném převzetí selhání se sekundární replika, na kterou jste přešli, stane novou primární replikou. Pokud ale chcete, aby byla replika dostupnosti přístupná klientům, možná budete muset překonfigurovat kvorum WSFC nebo upravit konfiguraci režimu dostupnosti skupiny dostupnosti následujícím způsobem:

    • Pokud jste převzali služby při selhání mimo automatickou sadu převzetí služeb při selhání: Upravte hlasy kvora uzlů WSFC tak, aby odrážely novou konfiguraci skupiny dostupnosti. Pokud uzel WSFC, který hostuje cílovou sekundární repliku, nemá hlas kvora WSFC, možná budete muset vynutit kvorum WSFC.

      Poznámka

      Sada automatického převzetí služeb při selhání existuje pouze v případě, že jsou dvě repliky dostupnosti (včetně dosavadní primární repliky) nakonfigurované pro režim potvrzení se synchronním přenosem a automatickým převzetím služeb při selhání.

      Upravit hlasy kvora

    • Pokud jste provedli převzetí služeb při selhání mimo sadu synchronního potvrzení pro převzetí služeb při selhání: Doporučujeme zvážit úpravy režimu dostupnosti a režimu převzetí služeb při selhání na nové primární replice a u zbývajících sekundárních replik, aby odrážely vaši požadovanou konfiguraci synchronního potvrzení a automatického převzetí služeb při selhání.

      Poznámka

      Sada převzetí služeb při selhání synchronního potvrzení existuje pouze v případě, že je aktuální primární replika nakonfigurovaná pro režim synchronního potvrzení.

      Změna režimu dostupnosti a režimu převzetí služeb při selhání

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

    Po obnovení sekundární databáze zahájí synchronizaci dat s odpovídající primární databází. Sekundární databáze vrátí zpět všechny záznamy protokolu, které nebyly nikdy potvrzeny v nové primární databázi. Proto pokud máte obavy o možnou ztrátu dat v primárních databázích po převzetí při selhání, měli byste se pokusit vytvořit snímek databáze v pozastavených databázích na jedné ze sekundárních databází s potvrzením synchronnosti.

    Důležitý

    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 synchronního potvrzení nemůže přejít do stavu ZDRAVÝ, dokud zůstane pozastavená jakákoli místní databáze.

    Vytvoření snímku databáze

    Obnovení databáze dostupnosti

    Opatrnost

    Po obnovení všech sekundárních databází před opětovným pokusem o převzetí služeb při selhání skupiny počkejte, až všechny sekundární databáze v dalším cíli převzetí služeb při selhání vstoupí do stavu SYNCHRONIZACE. Pokud některá databáze ještě není synchronizována, bude zabráněno tomu, aby se stala primární databází online, a opětovné vytvoření synchronizace dat pro databázi může vyžadovat obnovení transakčních protokolů, obnovení úplné zálohy databáze nebo převzetí služeb při selhání zpět na předchozí primární repliku.

  3. Pokud se replika dostupnosti, která selhala, nebude vracet do repliky dostupnosti, nebo se vrátí příliš pozdě na to, abyste mohli odložit zkrácení transakčního protokolu na nové primární databázi, zvažte odebrání selhavší repliky ze skupiny dostupnosti, aby nedošlo k vyčerpání místa na disku pro soubory protokolu.

    Odebrat sekundární repliku

  4. Pokud sledujete vynucené převzetí služeb při selhání s jedním nebo více dalšími vynucenými převzetím služeb při selhání, proveďte zálohu protokolu po každém dalším vynuceném převzetí služeb při selhání v řadě. Informace o příčině najdete v části Rizika vynucení převzetí služeb při selhání v části Vynucené ruční převzetí služeb při selhání (s možnou ztrátou dat) vrežimu převzetí služeb při selhání a převzetí služeb při selhání (skupiny dostupnosti AlwaysOn).

    Provedení zálohování protokolu

Ukázkový scénář: Použití vynuceného převzetí služeb při selhání k zotavení z závažného selhání

Pokud primární replika selže a žádná synchronizovaná sekundární replika není k dispozici, přinucení převzetí úkolů skupinou dostupnosti může být vhodnou reakcí. Vhodnost vynucení přepnutí na záložní systém závisí na tom, zda (1) očekáváte, že primární replika bude offline déle, než toleruje vaše smlouva o úrovni služeb (SLA), a (2) zda jste ochotni riskovat potenciální ztrátu dat pro rychlé zpřístupnění primárních databází. Pokud se rozhodnete, že skupina dostupnosti vyžaduje vynucené převzetí služeb při selhání, skutečné vynucené převzetí služeb při selhání je ale jedním krokem vícekrokového procesu.

Pro ilustraci kroků potřebných k použití vynuceného převzetí služeb při selhání k zotavení z závažného selhání představuje toto téma jeden možný scénář zotavení po havárii. Ukázkový scénář považuje skupinu dostupnosti, jejíž původní topologie se skládá z hlavního datového centra, které hostuje tři repliky dostupnosti synchronního potvrzení, včetně primární repliky, a vzdáleného datového centra, které hostuje dvě sekundární repliky asynchronního potvrzení. Následující obrázek znázorňuje původní topologii této ukázkové skupiny dostupnosti. Skupinu dostupnosti hostuje cluster WSFC s více podsítěmi se třemi uzly v hlavním datovém centru (Node 01, Node 02a Node 03) a dva uzly ve vzdáleném datovém centru (Node 04 a Node 05).

původní topologie skupiny dostupnosti

Hlavní datové centrum se neočekávaně vypne. Tři repliky dostupnosti přejdou do režimu offline a jejich databáze přestanou být dostupné. Následující obrázek znázorňuje dopad této chyby na topologii skupiny dostupnosti.

topologie po selhání hlavního datového centra

Správce databáze (DBA) stanoví, že nejlepší možnou reakcí je vynucení převzetí služeb při selhání dostupnostní skupiny na jednu ze vzdálených sekundárních replik s asynchronním potvrzením. Tento příklad ilustruje obvyklé kroky při vynucení přepnutí skupiny dostupnosti na vzdálenou repliku a následném návratu skupiny dostupnosti k její původní topologii.

Zde uvedená odpověď na selhání se skládá z následujících dvou fází:

Reakce na katastrofické selhání hlavního datového centra

Následující obrázek znázorňuje řadu akcí provedených ve vzdáleném datovém centru v reakci na katastrofické selhání v hlavním datovém centru.

kroky pro reakci na selhání hlavního datového centra

Kroky na tomto obrázku označují následující kroky:

Krok Akce Odkazy
1. Správce databáze nebo sítě zajišťuje, že cluster WSFC má kvorum v pořádku. V tomto příkladu musí být kvorum vynucené. Kvorum WSFC a konfigurace hlasování (SQL Server)

Obnova po havárii WSFC prostřednictvím vynuceného kvóra (SQL Server)
2. DBA se připojí k instanci serveru s nejnižší latencí (na uzlu 04) a provede vynucené ruční převzetí služeb. Vynucené převzetí služby při selhání převede tuto sekundární repliku do primární role a pozastaví sekundární databáze na zbylé sekundární replice (na Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) (Proveďte dotaz na sloupec end_of_log_lsn. Další informace najdete v tématu Doporučenívýše v tomto tématu.)
3. Správce databáze ručně obnoví každou sekundární databázi na zbývající sekundární replice. obnovení databáze dostupnosti (SQL Server)

Vrácení skupiny dostupnosti do původní topologie

Následující obrázek znázorňuje řadu akcí, které vrací skupinu dostupnosti do původní topologie po návratu hlavního datového centra do online režimu a opětovné navázání komunikace uzlů WSFC s clusterem WSFC.

Důležitý

Pokud je kvorum clusteru WSFC vynucené, jakmile se offline uzly restartují, mohou vytvořit nové kvorum, pokud jsou splněny obě následující podmínky: (a) mezi žádným uzlem v sadě vynuceného kvora neexistuje žádné síťové připojení a (b) restartované uzly jsou většina uzlů clusteru. Výsledkem by byl "rozdělený mozek", ve kterém by skupina dostupnosti měla dvě nezávislé primární repliky, jednu v každém datovém centru. Než vynutíte kvorum k vytvoření sady kvora menšiny, přečtěte si zotavení po havárii WSFC prostřednictvím vynuceného kvora (SQL Server).

Kroky pro vrácení skupiny do původní topologie

Kroky na tomto obrázku označují následující kroky:

Krok Odkazy
1. Uzly v hlavním datovém centru se vrátí do online režimu a znovu vytvoří komunikaci s clusterem WSFC. Repliky dostupnosti se zobrazují online jako sekundární repliky s pozastavenými databázemi, a DBA bude muset brzy ručně obnovit každou z těchto databází. obnovení databáze dostupnosti (SQL Server)

Tip: Pokud máte obavy o možnou ztrátu dat v primárních databázích po převzetí služeb při selhání, měli byste se pokusit vytvořit snímek databáze v pozastavených databázích v jedné sekundární databázi synchronního potvrzení. Mějte na paměti, že zkrácení transakčního protokolu je zpožděné v primární databázi, zatímco některé z jejích sekundárních databází je pozastavené. Stav synchronizace sekundární repliky synchronního potvrzení nemůže přejít do stavu zdravého, dokud zůstává pozastavena jakákoli místní databáze.
2. Po obnovení databází správce databáze dočasně změní novou primární repliku na režim synchronního potvrzení. To zahrnuje dva kroky:

1) Změňte jednu repliku dostupnou offline na režim asynchronního potvrzení.

2) Změňte novou primární repliku na režim synchronního commitu. Poznámka: Tento krok umožňuje, aby obnovené sekundární databáze pro synchronní potvrzování dosáhly stavu SYNCHRONIZOVÁNO.		 Změna režimu dostupnosti pro repliku dostupnosti (SQL Server)
3. Jakmile sekundární replika s potvrzením o synchronizaci na Node 03 (původní primární replika) přejde do stavu synchronizace v pořádku, DBA provede plánované ruční přepnutí této repliky, aby se znovu stala primární replikou. Replika na Node 04 se stává sekundární replikou. sys.dm_hadr_database_replica_states (Transact-SQL)

Použijte zásady Always On ke zobrazení stavu skupiny dostupnosti (SQL Server)

Provedení Plánovaného Ručního Převzetí Služeb při Selhání Skupiny Dostupnosti (SQL Server)
4. DBA se připojí k nové primární replice a:

1) Změní původní primární repliku (ve vzdáleném centru) zpět na režim asynchronního potvrzení.

2) Změní sekundární repliku asynchronního potvrzení v hlavním datacentru zpět na synchronní režim potvrzení.		 Změnit režim dostupnosti skupiny replik (SQL Server)

Související úkoly

Upravit hlasy kvora

Plánované ruční převzetí při selhání:

Řešit potíže:

Související obsah

Viz také

přehled skupin dostupnosti AlwaysOn (SQL Server)
režimy dostupnosti (skupiny dostupnosti AlwaysOn)
Režimy převzetí služeb při selhání a převzetí služeb při selhání (skupiny dostupnosti Always On)
O přístupu klientského připojení k replikám dostupnosti (SQL Server)
monitorování skupin dostupnosti (SQL Server)
Clusterování technologie Windows Server Failover Clustering (WSFC) s SQL Serverem