Sdílet prostřednictvím

Co je skupina dostupnosti AlwaysOn?

  • Článek

platí pro:SQL Server

Tento článek představuje koncepty skupin dostupnosti AlwaysOn, které jsou centrální pro konfiguraci a správu jedné nebo více skupin dostupnosti v edici Enterprise SQL Serveru. Pro edici Standard si projděte skupiny dostupnosti AlwaysOn úrovně Basic pro jednoúčelovou databázi.

Funkce Skupin dostupnosti AlwaysOn je řešení s vysokou dostupností a zotavením po havárii, které poskytuje alternativu k zrcadlení databáze na podnikové úrovni. Skupiny dostupnosti AlwaysOn maximalizují dostupnost skupiny uživatelských databází pro podnik. Skupina dostupnosti podporuje prostředí pro převzetí služeb při selhání pro samostatnou sadu uživatelských databází, známých jako databáze dostupnosti, které společně přebírají služby při selhání. Skupina dostupnosti podporuje sadu primárních databází pro čtení i zápis a jednu až osm sad odpovídajících sekundárních databází. Volitelně je možné sekundární databáze zpřístupnit pro přístup jen pro čtení nebo některé operace zálohování.

S SQL Serverem povoleným službou Azure Arcmůžete zobrazit skupiny dostupnosti na webu Azure Portal.

Přehled

Skupina dostupnosti podporuje replikované prostředí pro samostatnou sadu uživatelských databází, označovanou jako databáze dostupnosti. Můžete vytvořit skupinu dostupnosti pro vysokou dostupnost (HA) nebo pro škálování čtení. Skupina vysoké dostupnosti je skupina databází, které společně přejde při selhání. Skupina dostupnosti na úrovni čtení je skupina databází, které se kopírují do jiných instancí SQL Serveru pro úlohy jen pro čtení. Skupina dostupnosti podporuje jednu sadu primárních databází a jednu až osm sad odpovídajících sekundárních databází. Sekundární databáze nejsou zálohy. Pravidelně zálohujte databáze a jejich transakční protokoly.

Tip

Můžete vytvořit libovolný typ zálohy primární databáze. Alternativně můžete vytvořit zálohy protokolů a pouze kopie úplných záloh sekundárních databází. Další informace najdete v tématu Vyložení podporovaných záloh do sekundárních replik skupiny dostupnosti.

Každou sadu databází dostupnosti hostuje replika dostupnosti . Existují dva typy replik dostupnosti: jedna primární replika, která hostuje primární databáze, a jedna až osm sekundárních replik, z nichž každá hostuje sadu sekundárních databází a slouží jako potenciální cíle převzetí služeb při selhání pro skupinu dostupnosti. Skupina dostupnosti převezme služby při selhání na úrovni repliky dostupnosti. Replika dostupnosti poskytuje redundanci pouze na úrovni databáze pro sadu databází v jedné skupině dostupnosti. Převzetí služeb při selhání nesouvisí s problémy s databází, jako je například situace, kdy se databáze stane podezřelou kvůli ztrátě datového souboru nebo poškození transakčního protokolu.

Primární replika zpřístupňuje primární databáze a umožňuje připojení klientů s možností čtení a zápisu. Primární replika odesílá záznamy transakčního protokolu každé primární databáze do každé sekundární databáze. Tento proces – označovaný jako synchronizace dat – probíhá na úrovni databáze. Každá sekundární replika ukládá do mezipaměti záznamy transakčního protokolu (zajišťuje trvanlivost protokolu) a následně je aplikuje na odpovídající sekundární databázi. Synchronizace dat probíhá mezi primární databází a každou připojenou sekundární databází nezávisle na ostatních databázích. Sekundární databázi je proto možné pozastavit nebo selhat, aniž by to mělo vliv na jiné sekundární databáze, a primární databázi je možné pozastavit nebo selhat bez ovlivnění jiných primárních databází.

Volitelně můžete nakonfigurovat jednu nebo více sekundárních replik pro podporu přístupu jen pro čtení k sekundárním databázím a můžete nakonfigurovat jakoukoli sekundární repliku tak, aby umožňovala zálohování sekundárních databází.

SQL Server 2017 zavedl dvě různé architektury pro skupiny dostupnosti. skupiny dostupnosti AlwaysOn poskytují vysokou dostupnost, zotavení po havárii a vyrovnávání na úrovni čtení. Tyto skupiny dostupnosti vyžadují správce clusteru. Ve Windows poskytuje funkce převzetí služeb při selhání správce clusteru. V Linuxu můžete použít Pacemaker. Druhou architekturou je skupina dostupnosti na úrovni čtení. Skupina škálování čtení poskytuje repliky pro úlohy pouze pro čtení, ale neposkytuje vysokou dostupnost. Ve skupině dostupnosti zaměřené na čtení není žádný správce clusteru, protože automatické přepnutí není možné.

Nasazení skupin dostupnosti Always On pro vysokou dostupnost ve Windows vyžaduje cluster převzetí služeb při selhání Windows Serveru (WSFC). Každá replika dané skupiny dostupnosti se musí nacházet v jiném uzlu stejného WSFC. Jedinou výjimkou je, že během migrace do jiného clusteru WSFC může skupina dostupnosti dočasně existovat ve dvou clusterech současně.

Poznámka

Informace o skupinách dostupnosti v Linuxu najdete v tématu Skupiny dostupnosti pro SQL Server v Linuxu.

V konfiguraci vysoké dostupnosti se vytvoří role clusteru pro každou skupinu dostupnosti, kterou vytvoříte. Cluster WSFC tuto roli monitoruje, aby vyhodnotil stav primární repliky. Kvorum pro skupiny dostupnosti AlwaysOn je založeno na všech uzlech v clusteru WSFC bez ohledu na to, jestli daný uzel clusteru hostuje jakékoli repliky dostupnosti. Na rozdíl od zrcadlení databáze ve skupinách dostupnosti Always On neexistuje role pro svědka.

Poznámka

Informace o vztahu komponent SQL Server Always On ke clusteru WSFC naleznete v tématu Převzetí služeb při selhání systému Windows Server se serverem SQL Server.

Následující obrázek znázorňuje skupinu dostupnosti, která obsahuje jednu primární repliku a čtyři sekundární repliky. Je podporováno až osm sekundárních replik, včetně jedné primární repliky a čtyř sekundárních replik s potvrzením synchronního zápisu.

diagram skupiny dostupnosti s pěti replikami

Termíny a definice

Semestr Popis
skupina dostupnosti Kontejner pro sadu databází, dostupnostních databází, které se společně přepnou při selhání.
databáze dostupnosti Databáze, která patří do skupiny dostupnosti. Pro každou databázi dostupnosti skupina dostupnosti udržuje jednu kopii pro čtení i zápis (primární databázi) a jednu až osm kopií jen pro čtení (sekundární databáze).
primární databáze Kopie dostupnostní databáze pro čtení i zápis.
sekundární databáze Kopie databáze dostupnosti pouze pro čtení.
replika dostupnosti Instance skupiny dostupnosti, která je hostována konkrétní instancí SQL Serveru a udržuje místní kopii každé databáze dostupnosti, jež náleží do této skupiny dostupnosti. Existují dva typy replik dostupnosti: jedna primární replika a jedna až osm sekundárních replik.
primární replika Replika dostupnosti, která zpřístupňuje primární databáze klientům pro čtení i zápis, a také odesílá záznamy transakčního protokolu pro každou primární databázi do všech sekundárních replik.
sekundární replika Replika dostupnosti, která udržuje sekundární kopii každé databáze dostupnosti a slouží jako potenciální cílové body pro převzetí služeb při selhání pro skupinu dostupnosti. Volitelně může sekundární replika podporovat přístup jen pro čtení k sekundárním databázím, které můžou podporovat vytváření záloh v sekundárních databázích.
naslouchací služba skupiny dostupnosti Název serveru, ke kterému se klienti můžou připojit, aby mohli přistupovat k databázi v primární nebo sekundární replice skupiny dostupnosti. Posluchači skupiny dostupnosti směrují příchozí připojení na primární repliku nebo na sekundární repliku určenou pouze pro čtení.

Databáze dostupnosti

Chcete-li přidat databázi do skupiny dostupnosti, musí být databáze online databáze pro čtení i zápis, která existuje v instanci serveru, která je hostitelem primární repliky. Když přidáte databázi, připojí se ke skupině dostupnosti jako primární databázi, zatímco zůstane k dispozici pro klienty. Žádná odpovídající sekundární databáze neexistuje, dokud se zálohy nové primární databáze neobnoví do instance serveru, která je hostitelem sekundární repliky (pomocí funkce RESTORE WITH NORECOVERY). Nová sekundární databáze je ve stavu obnovení, dokud není připojena ke skupině dostupnosti. Další informace najdete v tématu Spuštění přesunu dat na Always On sekundární databázi (SQL Server).

Spojení umístí sekundární databázi do stavu ONLINE a zahájí synchronizaci dat s odpovídající primární databází. synchronizace dat je proces, kterým se v sekundární databázi reprodukují změny primární databáze. Synchronizace dat zahrnuje primární databázi, která odesílá záznamy transakčního protokolu do sekundární databáze.

Důležitý

Databáze dostupnosti se někdy označuje jako replika databáze v názvech objektů SMO (Transact-SQL, PowerShell a SQL Server Management Objects). Například termín "replika databáze" se používá v názvech zobrazení dynamické správy AlwaysOn, která vracejí informace o databázích dostupnosti: sys.dm_hadr_database_replica_states a sys.dm_hadr_database_replica_cluster_states. Ve službě SQL Server Books Online však termín "replika" obvykle odkazuje na dostupnostní repliky. Například "primární replika" a "sekundární replika" vždy odkazují na repliky dostupnosti.

Repliky dostupnosti

Každá skupina dostupnosti definuje sadu dvou nebo více partnerů pro převzetí služeb při selhání označovaných jako repliky dostupnosti. repliky dostupnosti jsou komponenty skupiny dostupnosti. Každá replika dostupnosti hostuje kopii databází dostupnosti ve skupině dostupnosti. Pro danou skupinu dostupnosti musí být repliky dostupnosti hostované samostatnými instancemi SQL Serveru umístěnými na různých uzlech clusteru WSFC. Každá z těchto instancí serveru musí být povolená pro funkci AlwaysOn.

SQL Server 2019 (15.x) zvyšuje maximální počet synchronních replik na 5, a to z 3 v SQL Serveru 2017 (14.x). Tuto skupinu pěti replik můžete nakonfigurovat tak, aby měla v rámci skupiny automatické převzetí služeb při selhání. Existuje jedna primární replika a čtyři synchronní sekundární repliky.

Daná instance může hostovat pouze jednu repliku dostupnosti na skupinu dostupnosti. Každá instance se ale dá použít pro mnoho skupin dostupnosti. Daná instance může být buď samostatná, nebo jako instance clusteru SQL Server s podporou převzetí služeb při selhání (FCI). Pokud požadujete redundanci na úrovni serveru, použijte instance clusteru s podporou převzetí služeb při selhání.

Každá replika dostupnosti má přiřazenou počáteční roli – buď primární roli, nebo sekundární roli, která je zděděna databází dostupnosti této repliky. Role dané repliky určuje, jestli je hostitelem databází pro čtení i zápis nebo databází jen pro čtení. Jedna replika, označovaná jako primární replika, má přiřazenou primární roli a hostuje databáze pro čtení i zápis, které se označují jako primární databáze. Alespoň jedna další replika, známá jako sekundární replika, má přiřazenou sekundární roli. Sekundární replika hostuje databáze jen pro čtení, označované jako sekundární databáze.

Poznámka

Pokud je role repliky dostupnosti neurčitá, například během převzetí role při selhání, jsou její databáze dočasně ve stavu NESYNCHRONIZUJÍ. Jejich role je nastavená na ŘEŠENÍ, dokud se nevyřeší role repliky dostupnosti. Pokud replika dostupnosti přejde do role primární, stanou se její databáze primárními databázemi. Pokud se replika dostupnosti přeřadí na sekundární roli, její databáze se stanou sekundárními.

Režimy dostupnosti

Mód dostupnosti je vlastnost každé repliky dostupnosti. Režim dostupnosti určuje, zda primární replika čeká na provedení transakcí v databázi, dokud určitá sekundární replika nezapíše záznamy transakčního protokolu na disk (zajištěný zápis). Skupiny dostupnosti AlwaysOn podporují dva režimy dostupnosti: režim asynchronního potvrzení a režim synchronního potvrzení.

  • režimu asynchronního potvrzení

    Replika dostupnosti, která používá tento režim dostupnosti, se označuje jako replika asynchronního potvrzení. V režimu asynchronního potvrzení potvrdí primární replika transakce bez čekání na potvrzení od sekundárních replik v asynchronním režimu k zapevnění jejich transakčních protokolů. Režim asynchronního potvrzení minimalizuje latenci transakcí v sekundárních databázích, ale umožňuje jim prodlevu za primárními databázemi, což umožňuje ztrátu některých dat.

  • Režim synchronního potvrzení

    Replika dostupnosti, která používá tento režim dostupnosti, se označuje jako synchronně potvrzující replika. V režimu synchronního potvrzení před potvrzením transakcí čeká primární replika synchronního potvrzení na potvrzení sekundární repliky synchronního potvrzení, aby potvrdila, že dokončila posílení protokolu. Režim synchronního potvrzení zajišťuje, že po synchronizaci dané sekundární databáze s primární databází jsou potvrzené transakce plně chráněné. Tato ochrana přichází za cenu zvýšené latence transakcí. Volitelně, SQL Server 2017 zavedl funkci požadovaného synchronizovaného sekundárního, která může při požadavku zvýšit bezpečnost, ale na úkor zpoždění. Funkci REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT lze povolit tak, aby vyžadovala určitý počet synchronních replik k potvrzení transakce před tím, než se primární replika může potvrdit.

Další informace najdete v tématu Rozdíly mezi režimy dostupnosti skupiny dostupnosti AlwaysOn.

Typy převzetí při selhání

V kontextu relace mezi primární a sekundární replikou jsou primární a sekundární role potenciálně zaměnitelné v procesu známém jako převzetí služeb při selhání. Během převzetí služby při selhání přejde cílová sekundární replika do primární role. Stane se novou primární replikou. Nová primární replika přináší své databáze online jako primární databáze a klientské aplikace se k nim můžou připojit. Pokud je k dispozici bývalá primární replika, přejde na sekundární roli a stane se sekundární replikou. Bývalé primární databáze se stanou sekundárními databázemi a synchronizace dat se obnoví.

Skupina dostupnosti provádí přepnutí při selhání na úrovni dostupnostní repliky. Převzetí služeb při selhání nejsou způsobené problémy s databází, jako je například podezření na ztrátu datového souboru, odstranění databáze nebo poškození transakčního protokolu.

Existují tři formy převzetí při selhání – automatické, ruční a vynucené (s možnou ztrátou dat). Formy převzetí služeb při selhání podporované danou sekundární replikou závisejí na její dostupnostním režimu, v režimu synchronního potvrzení pak na režimu převzetí služeb při selhání na primární replice a cílové sekundární replice takto.

  • Režim synchronního potvrzení podporuje dvě formy převzetí -plánované ruční převzetí a automatické převzetí, pokud je cílová sekundární replika současně synchronizovaná s primární replikou. Podpora těchto forem převzetí služeb při selhání závisí na nastavení vlastnosti režimu převzetí služeb při selhání u partnerů pro převzetí služeb při selhání. Pokud je režim převzetí služeb při selhání nastavený na "ruční" na primární nebo sekundární replice, je pro tuto sekundární repliku podporováno pouze ruční převzetí služeb při selhání. Pokud je u primární i sekundární repliky nastavený režim převzetí služeb při selhání na hodnotu "automaticky", podporuje se na této sekundární replice automatické i ruční převzetí služeb při selhání.

    • plánované ruční převzetí při selhání (bez ztráty dat)

      Ruční převzetí služeb při selhání nastane poté, co správce databáze vydá příkaz pro převzetí služeb při selhání, čímž způsobí, že synchronizovaná sekundární replika se změní na primární roli (se zaručenou ochranou dat) a primární replika se změní na sekundární roli. Ruční převzetí služeb při selhání vyžaduje, aby primární i cílová sekundární replika běžely v režimu synchronního potvrzení a sekundární replika už musí být synchronizovaná.

    • Automatické převzetí služeb při selhání (bez ztráty dat)

      Automatické převzetí služeb při selhání nastane jako reakce na poruchu, která způsobí, že synchronizovaná sekundární replika přejde k primární roli (se zaručenou ochranou dat). Jakmile bude dostupná, bývalá primární replika přejde na sekundární roli. Automatické převzetí služeb při selhání vyžaduje, aby jak primární, tak i cílová sekundární replika běžely v režimu synchronního potvrzení a režim převzetí služeb při selhání byl nastaven na Automatické. Sekundární replika už musí být synchronizovaná, musí mít kvorum WSFC a splňovat podmínky stanovené flexibilními zásadami převzetí služeb při selhání skupiny dostupnosti.

  • V režimu asynchronního potvrzení je jedinou formou záložního režimu vynucené ruční převzetí, které se obvykle nazývá vynucené převzetí, přičemž může dojít ke ztrátě dat. Vynucené převzetí při selhání je považováno za formu ručního převzetí, protože může být zahájeno pouze ručně. Vynucené přepnutí při selhání je možnost zotavení po havárii. Je to jediná forma převzetí služeb při selhání, která je možná, když cílová sekundární replika není synchronizovaná s primární replikou.

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).

Důležitý

  • Instance clusteru převzetí služeb při selhání SQL Serveru (FCI) nepodporují automatické převzetí služeb při selhání podle skupin dostupnosti, takže jakoukoli repliku dostupnosti hostovanou službou FCI je možné nakonfigurovat pouze pro ruční převzetí služeb při selhání.
  • Pokud vydáte příkaz vynuceného převzetí úloh na synchronizované sekundární replice, sekundární replika se chová stejně jako při plánovaném ručním převzetí úloh.

Výhody

Skupiny dostupnosti AlwaysOn poskytují bohatou sadu možností, které zlepšují dostupnost databáze a zlepšují využití prostředků. Klíčové komponenty jsou následující:

  • Podporuje až devět dostupnostních replik. Replika dostupnosti je instance skupiny dostupnosti hostované konkrétní instancí SQL Serveru a udržuje místní kopii každé databáze dostupnosti, která patří do skupiny dostupnosti. Každá skupina dostupnosti podporuje jednu primární repliku a až osm sekundárních replik. Další informace najdete v tématu Co je skupina dostupnosti AlwaysOn?

    Důležitý

    Každá replika dostupnosti se musí nacházet na jiném uzlu jednoho clusteru Windows Server s podporou převzetí služeb při selhání (WSFC). Další informace o požadavcích, omezeních a doporučeních pro skupiny dostupnosti najdete v tématu Požadavky, omezení a doporučení pro skupiny dostupnosti AlwaysOn.

  • Podporuje alternativní režimy dostupnosti následujícím způsobem:

    • režim asynchronního potvrzení. Tento režim dostupnosti je řešení zotavení po havárii, které funguje dobře, když se repliky dostupnosti distribuují do značné vzdálenosti.

    • synchronní potvrzovací režim. Tento režim dostupnosti zdůrazňuje vysokou dostupnost a ochranu dat nad výkonem za cenu zvýšené latence transakcí. Daná skupina dostupnosti může podporovat až pět replik synchronního potvrzení dostupnosti, včetně aktuální primární repliky.

      Další informace najdete v tématu Rozdíly mezi režimy dostupnosti skupiny dostupnosti AlwaysOn.

  • Podporuje několik forem převzetí služeb při selhání skupiny dostupnosti: automatické převzetí služeb při selhání, plánované ruční převzetí služeb při selhání (obecně označované jako "ruční převzetí služeb při selhání") a vynucené ruční převzetí služeb při selhání (obecně označované jako "vynucené převzetí služeb při selhání"). 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í (Always On Availability Groups).

  • Umožňuje nakonfigurovat danou repliku dostupnosti tak, aby podporovala obě následující možnosti aktivní-sekundární:

  • Podporuje naslouchací zařízení pro každou skupinu dostupnosti. naslouchací jednotka skupiny dostupnosti je název serveru, ke kterému se klienti mohou připojit, aby mohli přistupovat k databázi v primární nebo sekundární replice skupiny dostupnosti Always On. Posluchače skupiny dostupnosti směrují příchozí připojení k primární replice nebo k sekundární replice, která je určena pouze pro čtení. Naslouchající služba zajišťuje rychlé převzetí služeb aplikace při selhání skupiny dostupnosti. Další informace najdete v tématu Připojení k posluchači skupiny dostupnosti Always On.

  • Podporuje flexibilní zásady převzetí služeb při selhání pro větší kontrolu nad selháním skupiny dostupnosti. Další informace najdete v tématu Převzetí služeb při selhání a režimy převzetí (Always On Availability Groups).

  • Podporuje automatickou opravu stránky pro ochranu proti poškození stránky. Další informace najdete v tématu Automatická oprava stránek (skupiny dostupnosti: zrcadlení databází).

  • Podporuje šifrování a kompresi, které poskytují zabezpečený a vysoce výkonný přenos.

  • Poskytuje integrovanou sadu nástrojů pro zjednodušení nasazení a správy skupin dostupnosti, včetně:

Klientská připojení

Připojení klienta k primární replice dané skupiny dostupnosti můžete poskytnout vytvořením naslouchacího procesu skupiny dostupnosti. Naslouchací zařízení skupiny dostupnosti poskytuje sadu prostředků, které jsou připojené k dané skupině dostupnosti, aby bylo možné směrovat připojení klientů k příslušné replice dostupnosti.

Naslouchací služba skupiny dostupnosti je přidružená k jedinečným názvem DNS, který slouží jako virtuální název sítě (VNN), a k jedné nebo více virtuálním IP adresám a číslu portu TCP. Více informací viz Připojení k posluchači skupiny dostupnosti Always On.

Spropitné

Pokud skupina dostupnosti má pouze dvě repliky dostupnosti a není nakonfigurovaná tak, aby umožňovala přístup pro čtení k sekundární replice, můžou se klienti připojit k primární replice pomocí připojovacího řetězce zrcadlení databáze. Tento přístup může být užitečný dočasně po migraci databáze ze zrcadlení databáze do skupin dostupnosti AlwaysOn. Než přidáte další sekundární repliky, budete muset vytvořit posluchače pro skupinu dostupnosti a aktualizovat aplikace tak, aby používaly síťový název toho posluchače.

Aktivní sekundární repliky

Skupiny dostupnosti AlwaysOn podporují aktivní sekundární repliky. Mezi aktivní sekundární funkce patří podpora pro:

  • provádění operací zálohování na sekundárních replikách

    Sekundární repliky podporují zálohování protokolů a zálohování pouze kopírování zálohování úplné databáze, souboru nebo skupiny souborů. Skupinu dostupnosti můžete nakonfigurovat tak, aby určila předvolbu místa, kde se mají provádět zálohy. Je důležité si uvědomit, že sql Server předvolbu nevynucuje, takže nemá žádný vliv na ad hoc zálohování. Interpretace této preference závisí na logice, kterou aplikujete skriptováním do úloh zálohování pro každou databázi v dané skupině dostupnosti. Pro jednotlivé repliky dostupnosti můžete určit prioritu provádění záloh na této replice vzhledem k ostatním replikám ve stejné skupině dostupnosti. Viz Přenesení podporovaných záloh na sekundární repliky skupiny dostupnostipro více informací.

  • přístup jen pro čtení k jedné nebo více sekundárním replikám (replikám s možností čtení)

    Repliku sekundární dostupnosti je možné nakonfigurovat tak, aby umožňovala přístup jen pro čtení k místním databázím, i když některé operace nejsou plně podporované. Tím zabráníte pokusům o připojení pro čtení i zápis do sekundární repliky. Je také možné zabránit úlohám pouze pro čtení na primární replikě tím, že povolíte pouze přístup pro čtení a zápis. Tím se zabrání vytváření připojení pouze pro čtení k primární replice. Další informace najdete v tématu Přenos zátěže úlohy pouze pro čtení na sekundární repliku skupiny dostupnosti Always On.

    Pokud skupina dostupnosti aktuálně má posluchač skupiny dostupnosti a jednu nebo více přístupných pro čtení sekundárních replik, SQL Server může směrovat požadavky na připojení s úmyslem čtení na jednu z nich (směrování jen pro čtení). Další informace najdete v tématu Připojení k posluchači skupiny dostupnosti Always On.

Doba vypršení časového limitu relace

Období časového limitu relace je vlastnost repliky dostupnosti, která určuje, jak dlouho může zůstat připojení k jiné replice dostupnosti neaktivní, než je připojení ukončeno. Primární a sekundární repliky se vzájemně pingují, aby signalizovaly, že jsou stále aktivní. Příjem příkazu ping z druhé repliky během časového limitu znamená, že připojení je stále otevřené a že instance serveru komunikují. Při obdržení pingu dostupnostní replika resetuje u daného připojení čítač časového limitu relace.

Doba časového limitu relace zabraňuje, aby buď replika čekala neomezeně dlouho na přijetí pingu z druhé repliky. Pokud se z druhé repliky během časového limitu relace neobdrží žádný ping, časový limit repliky vyprší. Připojení se zavře a vypršelá replika přejde do stavu ODPOJENÝ. I když je odpojená replika nakonfigurovaná pro synchronní režim potvrzení, transakce nečekají na opětovné připojení a opětovnou synchronizaci této repliky.

Výchozí časový limit relace pro každou repliku dostupnosti je 10 sekund. Tato hodnota je uživatelsky konfigurovatelná s minimálně 5 sekundami. Obecně doporučujeme zachovat časový limit na 10 sekund nebo více. Nastavení hodnoty na méně než 10 sekund vytváří možnost silně zatíženého systému, který nesprávně deklaruje selhání.

Poznámka

V roli řešení se období časového limitu relace nepoužije, protože pingování nenastane.

Automatická oprava stránky

Každá dostupnostní replika se pokusí automaticky obnovit z poškozených stránek v místní databázi tím, že vyřeší určité typy chyb, které brání čtení datové stránky. Pokud sekundární replika nemůže přečíst stránku, replika požádá o novou kopii stránky z primární repliky. Pokud primární replika nemůže přečíst stránku, replika rozešle žádost o čerstvou kopii všem sekundárním replikám a získá stránku od té, která odpoví jako první. Pokud je tento požadavek úspěšný, nahradí se nečitelná stránka kopií, která obvykle chybu vyřeší.

Další informace najdete v tématu Automatická oprava stránky (Skupiny dostupnosti: zrcadlení databází).

Interoperabilita a koexistence s jinými funkcemi databázového stroje

Skupiny dostupnosti AlwaysOn je možné použít s následujícími funkcemi nebo součástmi SQL Serveru:

Další krok

Začínáme se skupinami dostupnosti AlwaysOn