Vysoká dostupnost a ochrana dat pro konfigurace skupin dostupnosti

Platí pro:SQL Server v Linuxu

Tento článek představuje podporované konfigurace nasazení pro skupiny dostupnosti AlwaysOn SQL Serveru na serverech s Linuxem. Skupina dostupnosti podporuje vysokou dostupnost a ochranu dat. Automatická detekce selhání, automatické převzetí služeb při selhání a transparentní opětovné připojení po převzetí služeb při selhání poskytují vysokou dostupnost. Synchronizované repliky poskytují ochranu dat.

V clusteru při selhání systému Windows Server (WSFC) používá běžná konfigurace pro vysokou dostupnost dvě synchronní repliky a třetí server nebo sdílený svazek pro dosažení kvora. Svědek sdíleného souboru potvrzuje konfiguraci skupiny dostupnosti – stav synchronizace, úlohu repliky například. Tato konfigurace zajišťuje, že sekundární replika zvolená jako cíl převzetí služeb při selhání má nejnovější data a změny konfigurace skupiny dostupnosti.

WSFC synchronizuje metadata konfigurace pro arbitráž převzetí služeb při selhání mezi replikami skupiny dostupnosti a kopií sdílené složky. Pokud skupina dostupnosti není ve WSFC, instance SQL Serveru ukládají do databáze metadata master konfigurace.

Například skupina dostupnosti v clusteru s Linuxem má CLUSTER_TYPE = EXTERNAL. Neexistuje žádná WSFC k arbitrate převzetí služeb při selhání. V tomto případě se metadata konfigurace spravují a udržují instancemi SQL Serveru. Vzhledem k tomu, že v tomto clusteru není žádný svědek server, je potřeba třetí instance SQL Serveru k ukládání metadat stavu konfigurace. Všechny tři instance SQL Serveru společně poskytují distribuované úložiště metadat pro cluster.

Správce clusteru může dotazovat instance SQL Serveru ve skupině dostupnosti a orchestrovat převzetí služeb při selhání za účelem zajištění vysoké dostupnosti. V clusteru s Linuxem je Pacemaker správcem clusteru.

Od verze SQL Server 2017 (14.x) CU 1 je vysoká dostupnost pro skupinu CLUSTER_TYPE = EXTERNAL dostupnosti povolená pro dvě synchronní repliky a pouze repliku konfigurace. Repliku konfigurace je možné hostovat na libovolné edici SQL Serveru 2017 (14.x) CU 1 nebo novější verze (včetně edice SQL Server Express). Konfigurační replika udržuje informace o konfiguraci skupiny dostupnosti v databázi master, ale neobsahuje uživatelské databáze ve skupině dostupnosti.

Vliv konfigurace na výchozí nastavení prostředků

Nastavení REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT prostředků clusteru zaručuje, že zadaný počet sekundárních replik zapisuje transakční data do protokolu před potvrzením každé transakce primární replikou. Pokud používáte správce externího clusteru, toto nastavení má vliv na vysokou dostupnost i ochranu dat. Výchozí hodnota pro nastavení závisí na architektuře v době vytvoření prostředku clusteru. Když nainstalujete agenta prostředků SYSTÉMU SQL Server – mssql-server-ha a vytvoříte prostředek clusteru pro skupinu dostupnosti, správce clusteru zjistí konfiguraci skupiny dostupnosti a odpovídajícím způsobem nastaví REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT .

Pokud je konfigurace podporovaná, nastaví se parametr REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT agenta prostředku na hodnotu, která poskytuje vysokou dostupnost a ochranu dat. Další informace najdete v tématu Vysvětlení agenta prostředků SQL Serveru pro pacemaker.

Následující části popisují výchozí chování prostředku clusteru.

Zvolte návrh skupiny dostupnosti, který vyhovuje konkrétním obchodním požadavkům na vysokou dostupnost, ochranu dat a škálování čtení.

Následující konfigurace popisují vzory návrhu skupin dostupnosti a možnosti jednotlivých vzorů. Tyto vzory návrhu se vztahují na skupiny dostupnosti s řešeními CLUSTER_TYPE = EXTERNAL s vysokou dostupností.

• tři synchronní repliky
• Dvě synchronní repliky
• Dvě synchronní repliky a pouze replika konfigurace

Tři synchronní repliky

Tato konfigurace se skládá ze tří synchronních replik. Ve výchozím nastavení poskytuje vysokou dostupnost a ochranu dat. Může také poskytovat škálování pro čtení.

Skupina dostupnosti se třemi synchronními replikami může poskytovat škálování čtení, vysokou dostupnost a ochranu dat. Následující tabulka popisuje chování dostupnosti.

Chování dostupnosti	Škálování čtení	Vysoká dostupnost ochrana osobních údajů	Ochrana dat
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0	1 1 Kč	2
Primární výpadek	Automatické převzetí služeb při selhání Může dojít ke ztrátě dat. Nový primární je R/W.	Automatické převzetí služeb při selhání Nový primární je R/W.	Automatické převzetí služeb při selhání Nový primární server není k dispozici pro transakce čtení nebo zápisu, dokud se předchozí primární server nezotaví a znovu se nepřipojí jako sekundární do skupiny dostupnosti.
Jeden sekundární výpadek repliky	Primární je režim čtení/zápisu (R/W). Sekundární databáze je dostupná pro čtení.	Primární je režim čtení/zápisu (R/W). Sekundární databáze je dostupná pro čtení.	Primární server zůstává pro transakce čtení nebo zápisu nedostupný, dokud se nezdařený sekundární server nezotaví a znovu nepřipojí ke skupině dostupnosti.
Výpadek dvou sekundárních replik	Primární je k dispozici pouze pro čtení a ne pro zápisy, dokud se jedna ze sekundárních replik neobnoví a znovu se připojí ke skupině dostupnosti.	Primární je k dispozici pouze pro čtení a ne pro zápisy, dokud se jedna ze sekundárních replik neobnoví a znovu se připojí ke skupině dostupnosti.	Primární server zůstává nedostupný pro transakce čtení nebo zápisu, dokud se všechny selhané sekundární repliky neobnoví a znovu nepřipojí ke skupině dostupnosti.
Primární a jeden sekundární výpadek repliky	Automatické převzetí služeb při selhání Může dojít ke ztrátě dat. Nový primární server je k dispozici pouze pro čtení a ne pro zápisy, dokud se jedna ze sekundárních replik neobnoví a znovu se připojí ke skupině dostupnosti.	Automatické převzetí služeb při selhání Nový primární server je k dispozici pouze pro čtení a zápisy, dokud se jedna ze sekundárních replik neobnoví a znovu se připojí ke skupině dostupnosti.	Automatické převzetí služeb při selhání Nový primární server zůstává pro transakce čtení nebo zápisu nedostupný, dokud se předchozí primární a sekundární replika neobnoví a znovu připojí ke skupině dostupnosti.

¹ Výchozí

Dvě synchronní repliky

Tato konfigurace umožňuje ochranu dat. Stejně jako ostatní konfigurace skupiny dostupnosti může povolit škálování čtení. Konfigurace dvou synchronních replik neposkytuje automatickou vysokou dostupnost. Konfigurace dvou replik se vztahuje pouze na SQL Server 2017 (14.x) RTM a už se nepodporuje s vyššími verzemi SQL Serveru 2017 (14.x).

Skupina dostupnosti se dvěma synchronními replikami poskytuje škálování čtení a ochranu dat. Následující tabulka popisuje chování dostupnosti.

Chování dostupnosti	Škálování čtení	Ochrana dat
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Primární výpadek	Automatické převzetí služeb při selhání Může dojít ke ztrátě dat. Nový primární je R/W.	Automatické převzetí služeb při selhání Nový primární uzel není k dispozici pro transakce čtení ani zápisu, dokud se předchozí primární neobnoví a znovu nepřipojí do skupiny dostupnosti jako sekundární.
Jeden sekundární výpadek repliky	R/W primární běží vystaveno ztrátě dat.	Primární server zůstává pro transakce čtení nebo zápisu nedostupný, dokud se nezdařený sekundární server nezotaví a znovu nepřipojí ke skupině dostupnosti.

¹ Výchozí

Dvě synchronní repliky a replika pouze pro konfiguraci

Skupina dostupnosti se dvěma (nebo více) synchronními replikami a replikou pouze pro konfiguraci poskytuje ochranu dat a může také nabízet vysokou dostupnost. Následující diagram představuje tuto architekturu:

1. Synchronní replikace uživatelských dat do sekundární repliky Zahrnuje také metadata týkající se konfigurace skupiny dostupnosti.
2. Synchronní replikace metadat konfigurace skupiny dostupnosti Nezahrnuje uživatelská data.

V diagramu skupiny dostupnosti primární replika odešle konfigurační data do sekundární repliky i repliky pouze pro konfiguraci. Sekundární replika také přijímá uživatelská data. Replika konfigurace nepřijímá uživatelská data. Sekundární replika je v synchronním režimu dostupnosti. Replika určená pouze pro konfiguraci neobsahuje databáze ve skupině dostupnosti – pouze metadata o skupině dostupnosti. Konfigurační data na replikě, která je pouze pro konfiguraci, se potvrdí synchronně.

Poznámka:

Skupina dostupnosti s pouze replikou konfigurace je nová pro SQL Server 2017 (14.x) CU 1. Všechny instance SQL Serveru ve skupině dostupnosti musí být SQL Server 2017 (14.x) CU 1 nebo novější verze.

Výchozí hodnota je REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 0. Následující tabulka popisuje chování dostupnosti.

Chování dostupnosti	Vysoká dostupnost ochrana osobních údajů	Ochrana dat
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT=	0 1	1
Primární výpadek	Automatické převzetí služeb při selhání Nový primární je R/W. Může dojít ke ztrátě dat.	Automatické převzetí služeb při selhání Nový primární uzel není k dispozici pro transakce čtení ani zápisu, dokud se předchozí primární neobnoví a znovu nepřipojí do skupiny dostupnosti jako sekundární.
Výpadek sekundární repliky	Primární je určen pro čtení/zápis, avšak běží s rizikem ztráty dat (pokud selže a nelze jej obnovit). Bez automatického převzetí služeb při selhání, pokud selže i primární server.	Primární server zůstává pro transakce čtení nebo zápisu nedostupný, dokud se nezdařený sekundární server nezotaví a znovu nepřipojí ke skupině dostupnosti. Pokud dojde k selhání primárního serveru, není k dispozici žádná replika, na kterou by bylo možné přepnout.
Výpadek pouze repliky konfigurace	Primární je režim čtení/zápisu (R/W). Bez automatického převzetí služeb při selhání, pokud selže i primární server.	Primární je režim čtení/zápisu (R/W). Bez automatického převzetí služeb při selhání, pokud selže i primární server.
Synchronní sekundární + konfigurace – pouze výpadek repliky	Primární systém je nedostupný pro transakce čtení i zápisu. Žádné automatické přepínání.	Primární systém je nedostupný pro transakce čtení i zápisu. Pokud dojde k selhání primárního serveru, není k dispozici žádná replika, na kterou by bylo možné přepnout.

¹ Výchozí

Poznámka:

Instance SYSTÉMU SQL Server, která je hostitelem pouze repliky konfigurace, může také hostovat jiné databáze. Může také fungovat pouze jako konfigurační databáze pro více než jednu skupinu dostupnosti.

Požadavky

• Všechny repliky ve skupině dostupnosti s jedinou replikou konfigurace musí být SQL Server 2017 (14.x) CU 1 nebo novější verze.
• Každá edice SQL Serveru může hostovat pouze repliku konfigurace, včetně SQL Serveru Express.
• Skupina dostupnosti potřebuje kromě primární repliky alespoň jednu sekundární repliku.
• Do maximálního počtu replik na instanci SQL Serveru se nezapočítávají pouze repliky konfigurace. SQL Server Standard edition umožňuje až tři repliky, SQL Server Enterprise Edition umožňuje až 9.

Úvahy

• Pro žádnou skupinu dostupnosti není povolena více než jedna replika pro konfiguraci.
• Konfigurační replika nemůže být primární replikou.
• Nelze upravit režim dostupnosti konfigurační repliky. Pokud chcete změnit repliku pouze z konfigurace na synchronní nebo asynchronní sekundární repliku, odeberte pouze repliku konfigurace a přidejte sekundární repliku s požadovaným režimem dostupnosti.
• Replika pouze s konfigurací je synchronizována s metadaty skupiny dostupnosti. Neexistují žádná uživatelská data.
• Skupina dostupnosti s jednou primární replikou a jedinou replikou konfigurace, ale žádná sekundární replika není platná.
• Nemůžete vytvořit skupinu dostupnosti v instanci edice SQL Server Express.

Pochopit agenta prostředků SQL Serveru pro Pacemaker

SQL Server 2017 (14.x) zavedl sequence_number do sys.availability_groups, aby zobrazoval, jestli replika označená jako SYNCHRONOUS_COMMIT byla aktuální. sequence_number je monotonicky rostoucí BIGINT, který představuje, jak up-to-date místní replika skupiny dostupnosti je s ohledem na zbývající repliky ve skupině dostupnosti. Převzetí při selhání, přidání nebo odebrání replik a další operace v dostupnostní skupině aktualizují toto číslo. Číslo se aktualizuje na primárním serveru a pak se odešle do sekundárních replik. Sekundární replika, která je up-to-date má tedy stejnou sequence_number jako primární replika.

Když se Pacemaker rozhodne zvýšit úroveň repliky na primární, nejprve odešle oznámení všem replikám, aby extrahovali pořadové číslo a uložili ho (toto oznámení se nazývá oznámení o předběžném zvýšení úrovně). Dále, když se Pacemaker pokusí povýšit repliku na primární repliku, replikace se povýší pouze tehdy, pokud její pořadové číslo je nejvyšší ze všech pořadových čísel všech replik, jinak operaci povýšení zamítne. Tímto způsobem lze zvýšit úroveň pouze repliky s nejvyšším pořadovým číslem na primární, čímž se zajistí, že nedojde ke ztrátě dat.

Povýšení je zaručeno, že bude fungovat, pokud alespoň jedna replika dostupná pro povýšení má stejné pořadové číslo jako předchozí primární. Výchozí chování agenta prostředků Pacemaker je automaticky nastavit REQUIRED_COPIES_TO_COMMIT tak, aby alespoň jedna sekundární replika s potvrzením synchronního přenosu byla aktuální a dostupná jako cíl automatického převzetí služeb při selhání. Při každé akci monitorování se vypočítá hodnota REQUIRED_COPIES_TO_COMMIT (a v případě potřeby se aktualizuje) jako (počet synchronních replik potvrzení/ 2). V době převzetí služeb při selhání pak agent prostředků vyžaduje (total number of replicas - required_copies_to_commit repliky) k reakci na oznámení o předběžném povýšení, aby mohl jednu z nich povýšit na primární. Replika s nejvyšším sequence_number je povýšena na primární.

Představme si například případ skupiny dostupnosti se třemi synchronními replikami – jednou primární replikou a dvěma synchronními sekundárními replikami potvrzení.

• REQUIRED_COPIES_TO_COMMIT je 3 / 2 = 1

• Požadovaný počet replik, které musí reagovat na akci před propagací, je 3 – 1 = 2. Aby se aktivovalo převzetí služeb při selhání, musí být v provozu dvě repliky. Pokud dojde k primárnímu výpadku, a jedna ze sekundárních replik nereaguje a pouze jedna z druhotných replik reaguje na akci před povýšením, agent prostředků nemůže zaručit, že sekundární replika, která odpověděla, má nejvyšší sequence_number, a převzetí služeb při selhání se neaktivuje.

Uživatel se může rozhodnout přepsat výchozí chování a nakonfigurovat prostředek skupiny dostupnosti tak, aby se REQUIRED_COPIES_TO_COMMIT nenastavil automaticky, jak bylo uvedeno dříve.

Důležité

Když REQUIRED_COPIES_TO_COMMIT je 0, existuje riziko ztráty dat. V případě výpadku primárního nebude agent prostředků automaticky spouštět převzetí služeb při selhání. Uživatel se musí rozhodnout, jestli chce počkat na obnovení primárního serveru nebo ruční převzetí služeb při selhání.

Pokud chcete nastavit REQUIRED_COPIES_TO_COMMIT hodnotu 0, spusťte:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Ekvivalentní příkaz pomocí crm (na SLES) je:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Pokud se chcete vrátit k výchozí vypočítané hodnotě, spusťte:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Poznámka:

Aktualizace vlastností prostředku způsobí zastavení a restartování všech replik. To znamená, že primární server se dočasně sníží na sekundární a pak se zvýší úroveň, což způsobí dočasnou nedostupnost zápisu. Nová hodnota REQUIRED_COPIES_TO_COMMIT bude nastavena pouze po restartování replik, takže nebude okamžitě spuštěna příkazem pcs .

Vyvážení vysoké dostupnosti a ochrany dat

Toto výchozí chování platí i pro případ dvou synchronních replik (primární + sekundární). Pacemaker ve výchozím nastavení REQUIRED_COPIES_TO_COMMIT = 1 zajišťuje, aby sekundární replika byla vždy aktuální pro maximální ochranu dat.

Výstraha

To má vyšší riziko nedostupnosti primární repliky kvůli plánovaným nebo neplánovaným výpadkům sekundární repliky. Uživatel může změnit výchozí chování agenta prostředků a přepsat REQUIRED_COPIES_TO_COMMIT na 0.

sudo pcs resource update <ag1> required_copies_to_commit=0

Po přepsání použije agent prostředků nové nastavení a REQUIRED_COPIES_TO_COMMIT zastaví jeho výpočet. Uživatelé ho musí ručně aktualizovat (například pokud zvýší počet replik).

Následující tabulky popisují dopad výpadku primárních nebo sekundárních replik v různých konfiguracích prostředků skupiny dostupnosti:

Skupina dostupnosti – dvě synchronizované repliky

Konfigurace	Primární výpadek	Jeden sekundární výpadek repliky
REQUIRED_COPIES_TO_COMMIT = 0	Uživatel musí vydat příručku FAILOVER. Může dojít ke ztrátě dat. Nová primární hodnota je R/W.	R/W primární běží vystaveno ztrátě dat.
REQUIRED_COPIES_TO_COMMIT = 1 1	Problémy s automatickým clusterem FAILOVER Žádná ztráta dat. Nová primární úroveň odmítne všechna připojení, dokud se předchozí primární neobnoví a jako sekundární nepřipojí ke skupině dostupnosti.	Primární odmítne všechna připojení, dokud se sekundární neobnoví.

¹ Výchozí chování agenta prostředků SQL Serveru pro Pacemaker.

Skupina dostupnosti – tři synchronizované repliky

Konfigurace	Primární výpadek	Jeden sekundární výpadek repliky
REQUIRED_COPIES_TO_COMMIT = 0	Uživatel musí vydat příručku FAILOVER. Může dojít ke ztrátě dat. Nová primární hodnota je R/W.	Primární je R/W.
REQUIRED_COPIES_TO_COMMIT = 1 1	Cluster automaticky problémy FAILOVER. Žádná ztráta dat. Nová primární je RW.	Primární je R/W.

¹ Výchozí chování agenta prostředků SQL Serveru pro Pacemaker.

Související obsah

• Skupiny dostupnosti pro SQL Server v Linuxu