Sdílet prostřednictvím

Rozdíly mezi režimy dostupnosti pro skupinu dostupnosti AlwaysOn

platí pro:SQL Server

Ve skupinách dostupnosti AlwaysOn je režim dostupnosti vlastností repliky, která určuje, jestli se daná replika dostupnosti může spustit v synchronním režimu potvrzení. Pro každou repliku dostupnosti musí být režim dostupnosti nakonfigurovaný buď pro synchronní režim potvrzení, asynchronní potvrzení, nebo pouze režim konfigurace.

Pokud je primární replika nakonfigurovaná pro režim asynchronního potvrzení, nečeká na zápis příchozích záznamů transakčních protokolů na disk žádnou sekundární repliku (kvůli posílení protokolu).

Pokud je daná sekundární replika nakonfigurovaná pro režim asynchronního potvrzení, primární replika nečeká na posílení zabezpečení protokolu. Pokud jsou jak primární replika, tak daná sekundární replika nakonfigurovány na režim synchronního potvrzení, primární replika čeká, až sekundární replika potvrdí, že uložila protokol, s výjimkou případu, kdy se sekundární replika nepodaří připojit k primární přes ping v době vypršení časového limitu relace primární repliky.

Poznámka:

Pokud sekundární replika s potvrzením synchronního zápisu překročí dobu časového limitu relace primární repliky (výchozí hodnota je 10 sekund), primární replika dočasně označí stav synchronizace každé databáze v této sekundární replice jako NOT SYNCHRONIZING a stav repliky jako NOT_HEALTHY. Když se sekundární replika znovu připojí k primární replice, obnoví režim synchronního potvrzení.

Podporované režimy dostupnosti

Skupiny dostupnosti AlwaysOn podporují tři režimy dostupnosti:

  • Režim asynchronního potvrzení
  • Režim synchronního potvrzení
  • Režim pouze konfigurace

Režim asynchronního potvrzení je řešení zotavení po havárii, které efektivně funguje, pokud jsou repliky dostupnosti distribuovány na velké vzdálenosti. Pokud je každá sekundární replika spuštěná v režimu asynchronního potvrzení, primární replika nečeká na posílení protokolu žádnou ze sekundárních replik. Místo toho okamžitě po zápisu záznamu protokolu do místního souboru protokolu primární replika odešle potvrzení transakce klientovi. Primární replika se spouští s minimální latencí transakcí ve vztahu k sekundární replice nakonfigurované pro režim asynchronního potvrzení.

Pokud je aktuální primární server nakonfigurován pro asynchronní režim potvrzení dostupnosti, potvrdí transakce asynchronně pro všechny sekundární repliky bez ohledu na jejich individuální nastavení režimu dostupnosti.

Další informace najdete v části Asynchronous-Commit Režim dostupnosti dále v tomto článku.

Synchronní režim potvrzení zdůrazňuje vysokou dostupnost nad výkonem za cenu zvýšené latence transakcí. V režimu synchronního potvrzení transakce čekají na odeslání potvrzení transakce klientovi, dokud sekundární replika nezpevní protokol na disk. Když synchronizace dat začíná v sekundární databázi, začne sekundární replika používat příchozí záznamy protokolu z odpovídající primární databáze. Jakmile se zpevní každý záznam protokolu, sekundární databáze přejde do SYNCHRONIZED stavu. Následně je každá nová transakce zpevněna sekundární replikou před zápisem do místního protokolového souboru. Pokud jsou synchronizované všechny sekundární databáze dané sekundární repliky, režim synchronního potvrzení transakcí podporuje ruční přepnutí při selhání a volitelně automatické přepnutí při selhání.

Další informace najdete dále v tomto článku v tématu Synchronous-Commit režimu dostupnosti.

Režim pouze pro konfiguraci se vztahuje na skupiny dostupnosti, které nejsou na clusteru služby převzetí služeb při selhání Windows Serveru. Replika v režimu pouze konfigurace neobsahuje uživatelská data. V režimu pouze konfigurace ukládá databáze repliky master metadata konfigurace skupiny dostupnosti. Další informace najdete v tématu Vysoká dostupnost a ochrana dat pro konfigurace skupin dostupnosti.

Následující obrázek znázorňuje skupinu dostupnosti s pěti replikami dostupnosti. Primární replika a jedna sekundární replika jsou nakonfigurované pro režim synchronního potvrzení s automatickým převzetím při selhání. Další sekundární replika je nakonfigurovaná v režimu synchronního potvrzení s pouze plánovaným ručním převzetím služeb při selhání a dvě sekundární repliky jsou nakonfigurované v režimu asynchronního potvrzení, který podporuje pouze vynucené ruční převzetí služeb při selhání (obvykle označované jako vynucené převzetí služeb při selhání).

Diagram režimů dostupnosti replik a režimů převzetí služeb při selhání

Synchronizace a převzetí služeb při selhání mezi dvěma replikami dostupnosti závisí na režimu dostupnosti obou replik. Aby například došlo k synchronnímu potvrzení, musí být primární i sekundární replika nakonfigurované pro synchronní potvrzení. Podobně pro automatické převzetí služeb při selhání je potřeba nakonfigurovat obě repliky pro automatické převzetí služeb při selhání. Chování dříve ilustrovaného scénáře nasazení je proto možné shrnout v následující tabulce, která zkoumá chování s jednotlivými potenciálními primárními replikami:

Aktuální primární replika Cíle automatického záložního řešení Chování režimu synchronního potvrzení u Chování režimu asynchronního potvrzení Možné automatické převzetí při selhání
01 02 02 a 03 04 Ano
02 01 01 a 03 04 Ano
03 01 a 02 04 Ne
04 01, 02 a 03 Ne

Obvykle je uzel 04 jako asynchronní replika nasazený v lokalitě pro zotavení po havárii. Skutečnost, že Uzly 01, 02 a 03 zůstávají v režimu asynchronního potvrzení po převzetí služeb při selhání na Node 04 pomáhá zabránit potenciálnímu snížení výkonu ve vaší skupině dostupnosti kvůli vysoké latenci sítě mezi těmito dvěma lokalitami.

Režim dostupnosti asynchronního potvrzení

V režimu asynchronního potvrzení se sekundární replika nikdy nesynchronuje s primární replikou. I když daná sekundární databáze může dohnat odpovídající primární databázi, může se jakákoli sekundární databáze v libovolném bodě zpozdit. Režim asynchronního potvrzení může být užitečný ve scénáři zotavení po havárii, ve kterém je primární replika a sekundární replika oddělené významnou vzdáleností a kde nechcete, aby malé chyby ovlivnily primární repliku nebo v situacích, kdy je výkon důležitější než synchronizovaná ochrana dat. Vzhledem k tomu, že primární replika nečeká na potvrzení ze sekundární repliky, nebudou mít problémy se sekundární replikou nikdy vliv na primární repliku.

Sekundární replika s asynchronním závazkem se snaží držet krok se záznamy protokolu, které přijímá z primární repliky. Sekundární databáze asynchronního potvrzení ale zůstávají nesynchronizované a pravděpodobně budou poněkud zaostaly za odpovídajícími primárními databázemi. Obvykle je mezera mezi sekundární databází asynchronního potvrzení a odpovídající primární databází malá. Pokud je ale server hostující sekundární repliku přetěžující nebo je síť pomalá, může se stát, že mezera může být podstatná.

Jediná forma převzetí služeb při selhání podporovaná režimem asynchronního potvrzení je vynucené převzetí služeb při selhání (s možnou ztrátou dat). Vynucení převzetí služeb při poruše je poslední možností určenou pouze pro situace, kdy aktuální primární replika zůstane po delší dobu nedostupná a okamžitá dostupnost primárních databází je důležitější než riziko možné ztráty dat. Cíl převzetí služeb při selhání musí být replika, jejíž role je v SECONDARY nebo RESOLVING stavu. Cíl převzetí služeb při selhání přejde do primární role a jeho kopie databází se stanou primárními databázemi. Všechny zbývající sekundární databáze spolu s bývalými primárními databázemi se po jejich zpřístupnění pozastaví, dokud je ručně neobnovíte. V režimu asynchronního potvrzení se ztratí všechny transakční protokoly, které původní primární replika ještě neodesílala do bývalé sekundární repliky. To znamená, že některé nebo všechny nové primární databáze nemusí mít nedávno potvrzené transakce. Další informace o tom, jak vynucené převzetí služeb při selhání funguje a jaké jsou osvědčené postupy pro jeho použití, 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).

Režim dostupnosti synchronního potvrzení

V režimu dostupnosti synchronního potvrzení (režim synchronního potvrzení) po připojení ke skupině dostupnosti sekundární databáze zachytí odpovídající primární databázi a přejde do SYNCHRONIZED stavu. Sekundární databáze zůstává SYNCHRONIZED , dokud synchronizace dat pokračuje. To zaručuje, že každá transakce potvrzená pro danou primární databázi je potvrzena na odpovídající sekundární databázi. Při synchronizaci každé sekundární databáze na dané sekundární replice je zdravotní stav synchronizace sekundární repliky jako celek HEALTHY.

V této části:

Faktory, které přeruší synchronizaci dat

Jakmile budou všechny jeho databáze synchronizovány, sekundární replika přejde do HEALTHY stavu. Synchronizovaná sekundární replika zůstane v pořádku, pokud nedojde k některé z následujících situací:

  • Zpoždění nebo chyba sítě nebo počítače způsobí vypršení časového limitu relace mezi sekundární replikou a primární replikou.

    Poznámka:

    Informace o časové vlastnosti relace repliky dostupnosti najdete v tématu Co je Always On skupina dostupnosti?

  • Pozastavíte sekundární databázi na sekundární replice. Sekundární replika přestane být synchronizována a stav synchronizace je označen jako NEZDRAVÝ. Sekundární replika nemůže být znovu ve správném stavu, dokud nebude pozastavená sekundární databáze buď znovu aktivována a znovu synchronizována, nebo odebrána ze skupiny dostupnosti.

  • Primární databázi přidáte do skupiny dostupnosti. Dříve synchronizované sekundární repliky zadávají NOT_HEALTHY stav synchronizace. Tento stav označuje, že alespoň jedna databáze je ve NOT SYNCHRONIZING stavu synchronizace. Daná sekundární replika nemůže být HEALTHY znovu, dokud nebude na replice připravena odpovídající sekundární databáze, bude připojená ke skupině dostupnosti a nebude synchronizovaná s novou primární databází.

  • Primární nebo sekundární repliku změníte na režim s asynchronním potvrzením dostupnosti. Po změně na režim asynchronního potvrzení zůstane sekundární replika ve stavu synchronizační kondice HEALTHY tak dlouho, dokud bude synchronizace dat pokračovat. Pokud se ale primární replika změní pouze na asynchronní režim potvrzení, sekundární replika synchronního potvrzení přejde do PARTIALLY_HEALTHY stavu synchronizace a zdraví. Tento stav označuje, že alespoň jedna databáze je ve SYNCHRONIZING stavu synchronizace, ale žádná z databází není ve NOT SYNCHRONIZING stavu.

  • Změníte jakoukoli sekundární repliku na režim dostupnosti synchronního potvrzování. To způsobí, že se sekundární replika označí jako ve PARTIALLY_HEALTHY stavu zdraví synchronizace, dokud všechny její databáze nebudou ve SYNCHRONIZED stavu synchronizace.

Návod

Pokud chcete zobrazit stav synchronizace skupiny dostupnosti, repliky dostupnosti nebo databáze dostupnosti, dotazujte sloupec synchronization_health nebo synchronization_health_desc tabulky sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states nebo sys.dm_hadr_database_replica_states.

Jak funguje synchronizace na sekundární replice

V režimu synchronního potvrzení, po připojení sekundární repliky ke skupině dostupnosti a navázání relace s primární replikou:

  1. Sekundární replika zapisuje příchozí záznamy protokolu na disk (zpevní protokol).
  2. Sekundární replika odešle do primární repliky potvrzovací zprávu.

Po zpevnění protokolu na sekundární databázi a jeho synchronizaci s koncem protokolu na primární databázi, je stav sekundární databáze nastaven na SYNCHRONIZED.

Doba potřebná pro synchronizaci závisí na tom, jak daleko byla sekundární databáze za primární databází na začátku relace. Tento rozdíl se měří podle počtu záznamů protokolu, které byly původně přijaty z primární repliky, zatížení práce primární databáze a rychlostí hostitele instance sekundární repliky.

Proces transakce

V synchronním režimu potvrzení jsou transakce potvrzeny do obou replik v tomto pořadí:

  1. Primární replika přijímá transakci od klienta.

  2. Primární replika zapíše záznam do transakčního protokolu a současně odešle záznam protokolu do sekundárních replik.

    Jakmile se záznam zapíše do transakčního protokolu primární databáze, transakce může být odvolána pouze tehdy, když dojde k převzetí služeb při selhání na sekundární, která protokol neobdržela.

  3. Primární replika čeká na potvrzení od sekundární repliky v rámci synchronního potvrzování.

  4. Sekundární replika zpevní protokol a vrátí potvrzení primární replice.

  5. Primární replika dokončí zpracování potvrzení a odešle klientovi potvrzovací zprávu.

Časový limit synchronního potvrzení

Pokud sekundární replika synchronně potvrzující dosáhne časového limitu, aniž by potvrdila, že protokol byl upevněn, ve skupině dostupnosti dojde k následujícím akcím:

  1. Primární replika označuje sekundární repliku jako neúspěšnou.
  2. Stav sekundární repliky se změní na DISCONNECTED.
  3. Primární přestane čekat na potvrzení.
  4. Skupina dostupnosti označuje stav synchronizace jako NOT SYNCHRONIZING a stav repliky jako NOT_HEALTHY.

Toto chování zajišťuje, že v případě selhání synchronního potvrzení sekundární repliky nedojde k zastavení stabilizace logu na primární replice.

Když je sekundární replika opět online:

  1. Stav sekundární repliky se změní na CONNECTED.
  2. Sekundární replika zpracovává frontu odesílání protokolů primární repliky.
  3. Stav synchronizace přejde do SYNCHRONIZINGa stav repliky na PARTIALLY_HEALTHY.

Po zpracování fronty odeslání protokolu se stav synchronizace stane SYNCHRONIZED, a stav repliky se změní na HEALTHY.

Synchronní režim potvrzení chrání vaše data tím, že vyžaduje synchronizaci dat mezi dvěma místy za cenu poněkud zvýšení latence transakce.

Synchronní režim potvrzení s výhradně ručním převzetím služeb při selhání

Jakmile jsou tyto repliky připojeny a databáze je synchronizována, je možné ručně převzít úlohu při selhání. Pokud sekundární replika přestane fungovat, primární replika není ovlivněná. Primární replika běží bez ochrany, pokud neexistují žádné SYNCHRONIZED repliky (to znamená, že se data neposílají do žádné sekundární repliky). Pokud dojde ke ztrátě primární repliky, sekundární repliky přejdou do stavu RESOLVING, ale vlastník databáze může vynutit přepnutí na sekundární repliky (s možnou ztrátou dat). Další informace najdete v tématu převzetí služeb při selhání a režimy převzetí služeb při selhání (skupiny dostupnosti Always On).

Synchronní režim potvrzení s automatickým převzetím služeb při výpadku

Automatické převzetí služeb při selhání zajišťuje vysokou dostupnost tím, že zajistí, aby se databáze po ztrátě primární repliky rychle zpřístupnila. Pokud chcete nakonfigurovat dostupnostní skupinu pro automatické přepnutí při selhání, musíte nastavit aktuální primární repliku i alespoň jednu sekundární repliku na synchronní režim potvrzení s automatickým přepnutím při selhání. SQL Server 2019 (15.x) zvýšil maximální počet synchronních replik na 5, z 3 v SQL Serveru 2017 (14.x). Tuto skupinu pěti replik můžete v rámci skupiny nakonfigurovat tak, aby měla automatické převzetí služeb při selhání. Existuje jedna primární replika a čtyři synchronní sekundární repliky.

Aby bylo možné v daném okamžiku provést automatické převzetí služeb při selhání, musí být tato sekundární replika synchronizována s primární replikou (tj. všechny sekundární databáze musí být synchronizovány) a cluster WSFC (Windows Server Failover Clustering) musí mít kvorum. Pokud se primární replika za těchto podmínek stane nedostupnou, automaticky dojde k převzetí služeb. Sekundární replika se přepne na roli primární a nabízí svou databázi jako primární databázi. Další informace najdete v části Automatické převzetí služeb při selhání v článku Režimy převzetí služeb při selhání a převzetí služeb při selhání (skupiny dostupnosti AlwaysOn).

Poznámka:

Informace o kvoru WSFC a skupinách dostupnosti AlwaysOn naleznete v tématu Režimy kvora WSFC a hlasovací konfigurace (SQL Server).

Latence dat v sekundární replice

Implementace přístupu jen pro čtení do sekundárních replik je užitečná, pokud vaše úlohy jen pro čtení můžou tolerovat určitou latenci dat. V situacích, kdy je latence dat nepřijatelná, zvažte spouštění úloh jen pro čtení u primární repliky.

Primární replika odesílá záznamy protokolů změn v primární databázi do sekundárních replik. V každé sekundární databázi použije vyhrazené vlákno znovu záznamy protokolu. V sekundární databázi s přístupem pro čtení se daná změna dat nezobrazí ve výsledcích dotazu, dokud se na sekundární databázi nepoužije záznam protokolu obsahující změnu a transakce se potvrdí v primární databázi.

To znamená, že mezi primárními a sekundárními replikami existuje určitá latence, obvykle jen otázkou sekund. V neobvyklých případech ale může být latence důležitá například v případě, že problémy se sítí snižují propustnost. Latence se zvyšuje, když dojde k kritickým bodům vstupně-výstupních operací a když je přesun dat pozastavený. K monitorování pozastaveného přesunu dat můžete použít řídicí panel Skupiny dostupnosti Always On (SQL Server Management Studio) nebo dynamické zobrazení správy sys.dm_hadr_database_replica_states.

Pokud chcete snížit latenci v SQL Serveru 2025 (17.x) a novějších verzích, můžete zkrátit dobu (v milisekundách), kterou primární replika přijímá k potvrzení transakcí do sekundární repliky. Další informace naleznete v tématu Konfigurace serveru: doba potvrzení skupiny dostupnosti (ms).

Chcete-li změnit režim dostupnosti a režim převzetí služeb při selhání

Upravit hlasy kvora

Ruční přepnutí při selhání

Zobrazení skupin dostupnosti, repliky dostupnosti a stavů databáze

Související obsah

  • Last updated on