Sdílet prostřednictvím

Co je skupina dostupnosti AlwaysOn?

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.

Návod

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

Konfigurace šifrování TLS 1.3

SQL Server 2025 (17.x) zavádí podporu tabulkového datového streamu 8.0, což umožňuje vynutit šifrování TLS 1.3 pro komunikaci mezi clusterem pro převzetí služeb při selhání Windows Serveru a replikami skupiny dostupnosti Always On. Začněte tím, že si projděte možnost Připojit s přísným šifrováním.

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 Instanciace skupiny dostupnosti, kterou hostí konkrétní instance SQL Serveru a která udržuje místní kopii každé databáze dostupnosti náležející této skupině 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. Neexistuje žádná odpovídající sekundární databáze, dokud neobnovíte zálohy nové primární databáze 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í samostatné instance SQL Serveru umístěného na různých uzlech clusteru WSFC hostovat repliky dostupnosti. 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ždou instanci však můžete 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é dostupnostní replice je přiřazena počáteční role – buď primární role nebo sekundární role, kterou dědí databáze 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

Každá replika dostupnosti má vlastnost režimu dostupnosti. Režim dostupnosti určuje, jestli primární replika čeká na potvrzení transakcí v databázi, dokud daná sekundární replika nezapíše záznamy transakčního protokolu na disk (zpevňuje protokol). 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í primární replika před potvrzením transakcí čeká, až sekundární replika potvrdí, že dokončila zápis do záznamu 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í replikou a sekundární replikou se primární a sekundární role můžou přepnout v procesu označovaného jako převzetí služeb při selhání. Během převzetí při selhání se cílová sekundární replika stane primární a novým hlavním replikátem. 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 do sekundární role 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 převezme služby při selhání na úrovni repliky dostupnosti. Převzetí služeb při selhání neprobíhá kvůli problémům s databází, jako je nedůvěryhodnost způsobená ztrátou datového souboru, odstranění databáze nebo poškození transakčního logu.

Existují tři formy převzetí služeb při selhání: automatické, ruční a vynucené (s možnou ztrátou dat). Formulář nebo formy převzetí služeb při selhání, které daná sekundární replika podporuje, závisí na jeho režimu dostupnosti. Režim synchronního potvrzení také závisí na režimu převzetí na primární replice a cílové sekundární replice následujícím způsobem.

  • Režim potvrzování synchronním způsobem podporuje dvě formy převzetí služeb při selhání: plánované ruční převzetí služeb při selhání a automatické převzetí služeb při selhání, pokud je cílová sekundární replika momentálně synchronizována s primární replikou. Nastavení vlastnosti režimu převzetí služeb při selhání u partnerů převzetí služeb při selhání určuje podporu těchto forem převzetí služeb při selhání. Pokud nastavíte režim převzetí služeb při selhání na ruční na primární nebo sekundární replice, sekundární replika podporuje pouze ruční převzetí služeb při selhání. Pokud nastavíte režim převzetí služeb při selhání na automatický u primární i sekundární repliky, sekundární replika podporuje jak automatické, tak 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, když správce databáze vydá příkaz převzetí služeb při selhání. Způsobí, že synchronizovaná sekundární replika přejde na primární roli (s garantovanou 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í. Sekundární replika již musí být synchronizovaná.

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

    Automatické přepnutí probíhá v reakci na selhání. Způsobí přechod synchronizované sekundární repliky na primární roli (se zaručenou ochranou dat). Jakmile se bývalá primární replika stane dostupnou, přejde do sekundární role. Automatické převzetí při selhání vyžaduje, aby primární i sekundární replika běžely v režimu synchronního potvrzení s režimem převzetí při selhání nastaveným 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í služeb při selhání je forma manuálního převzetí služeb při selhání, protože ho musíte zahájit ručně. Vynucené přepnutí při selhání je možnost zotavení po havárii. Je to jediná forma převzetí 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 SQL Server Failover nepodporují automatické převzetí služeb při selhání pomocí skupin dostupnosti, takže můžete nakonfigurovat pouze ruční převzetí služeb při selhání pro jakoukoli repliku dostupnosti, kterou FCI hostuje.
  • 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í:

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. Další informace najdete v tématu Připojení k posluchači skupiny dostupnosti Always On.

Pokud má skupina dostupnosti jenom 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 sekundární repliky, musíte pro skupinu dostupnosti vytvořit naslouchací proces skupiny dostupnosti a aktualizovat aplikace tak, aby používaly síťový název naslouchacího procesu.

Poznámka

SQL Server 2025 (17.x) zavádí podporu TDS 8.0, která umožňuje vynucovat přísné šifrování TLS 1.3 pro připojení k replikám skupiny dostupnosti AlwaysOn a naslouchacímu procesu.

Požadavky na konfiguraci:

  • Nové skupiny dostupnosti: Vytvořte skupinu AG s Encrypt=Strict v klauzuli CLUSTER_CONNECTION_OPTIONS a proveďte přepnutí při selhání, aby se použilo nastavení.
  • Existující skupiny dostupnosti: Upravte AG pomocí klauzule CLUSTER_CONNECTION_OPTIONS k nastavení Encrypt=Strict a proveďte failover pro použití nastavení.
  • Vynucení striktního šifrování: U každé repliky a restartování replik SYSTÉMU SQL Server nastavte tuto možnost na Ano v nástroji SQL Server Configuration Manager.
  • Požadavky na certifikát: Pokud je Encrypt=Strict nastaveno, TrustServerCertificate bude ignorováno.

Začněte tím, že si projděte možnost Připojit s přísným šifrováním.

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 nevynucuje předvolbu, 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. Další informace najdete v tématu Vyložení podporovaných záloh do sekundárních replik skupiny dostupnosti.

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

    Můžete nakonfigurovat jakoukoli sekundární repliku dostupnosti tak, aby umožňovala přístup jen pro čtení k místním databázím, i když některé operace nejsou plně podporované. Tato konfigurace brání 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. Tato konfigurace brání v vytváření připojení jen pro čtení k primární replice. Další informace naleznete v tématu Odlehčit úlohu jen pro čtení na sekundární repliku skupiny dostupnosti Always On.

    Pokud má skupina dostupnosti aktuálně posluchač skupiny dostupnosti a jednu nebo více čitelné sekundární repliky, SQL Server může směrovat požadavky na připojení pro č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

Časový limit relace je vlastnost dostupnostní repliky, která určuje, jak dlouho může připojení s jinou dostupnostní replikou zůstat neaktivní, než se připojení uzavře. 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 není během období časového limitu relace z druhé repliky obdržen žádný ping, replika vyprší časový limit. Její připojení se zavře a replika přejde do stavu ODPOJENO. 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. Tuto hodnotu můžete nakonfigurovat s minimální hodnotou 5 sekund. Obecně platí, že dobu časového limitu ponechte na 10 sekundách nebo vyšší. 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ánek (skupiny dostupnosti: zrcadlení databází).

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

Skupiny dostupnosti AlwaysOn fungují s následujícími funkcemi nebo komponentami SQL Serveru:

Další krok

Začínáme se skupinami dostupnosti AlwaysOn

  • Last updated on