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 k zobrazení toho, zda je replika označená jako SYNCHRONOUS_COMMIT aktuální. sequence_number je monotonicky rostoucí bigint, který představuje, jak aktuální je replika místní skupiny dostupnosti ve srovnání se zbytkem replik ve skupině dostupnosti.

Toto číslo se aktualizuje, když provedete převzetí služeb při selhání, přidáte nebo odeberete repliky a při dalších operacích se skupinou dostupnosti.

Primární replika aktualizuje číslo a pak ho odešle do sekundárních replik. Sekundární replika, která je up-to-date, má stejnou sequence_number jako primární replika.

Když se Pacemaker rozhodne povýšit repliku na primární, nejprve odešle oznámení všem replikám, aby extrahovaly pořadové číslo a uložily ho. Toto oznámení se označuje jako předpropagační oznámení. Když se Pacemaker pokusí povýšit repliku na primární, replika se povýší pouze tehdy, pokud je její sekvenční číslo nejvyšší ze všech sekvenčních čísel všech replik. V opačném případě operaci povýšení odmítne. Pomocí tohoto procesu lze primární replikou učinit pouze repliku s nejvyšším pořadovým číslem, čímž se zajistí, že nedojde ke ztrátě dat.

Povýšení funguje, pokud alespoň jedna replika dostupná pro povýšení má stejné pořadové číslo jako předchozí primární. Výchozím chováním je, že agent prostředků Pacemaker automaticky nastaví REQUIRED_COPIES_TO_COMMIT, aby alespoň jedna sekundární replika pro synchronní potvrzení byla aktuální a dostupná jako cíl automatického převzetí 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ředstavte si například případ skupiny dostupnosti se třemi synchronizovanými replikami – jednou primární replikou a dvěma sekundárními replikami s potvrzením synchronizace.

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

Výchozí chování můžete přepsat a nakonfigurovat prostředek skupiny dostupnosti tak, aby REQUIRED_COPIES_TO_COMMIT nebylo nastaveno automaticky.

Důležité

Pokud je REQUIRED_COPIES_TO_COMMIT0, riskujete ztrátu dat. Pokud dojde k výpadku primárního, resource agent automaticky nevyvolá převzetí funkcí. Musíte si zvolit čekání na obnovení primárního serveru nebo provedení ručního 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 SUSE Linux Enterprise Serveru) 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. Tato změna dočasně sníží úroveň primární na sekundární a pak ji znovu zvýší, což způsobí dočasnou nedostupnost zápisu. Nová hodnota REQUIRED_COPIES_TO_COMMIT je nastavená až po restartování replik, takže není okamžitá při spuštění příkazu pcs .

Vyvážení vysoké dostupnosti a ochrany dat

Výchozí chování popsané výše platí také pro případ dvou synchronních replik (primárních a sekundárních). Pacemaker nastaví REQUIRED_COPIES_TO_COMMIT na 1, aby sekundární replika byla vždy aktuální pro maximální ochranu dat.

Výstraha

Toto nastavení má vyšší riziko nedostupnosti primární repliky kvůli plánovaným nebo neplánovaným výpadkům na sekundární replice. Můžete změnit výchozí chování agenta prostředků a přepsat REQUIRED_COPIES_TO_COMMIT hodnotu na 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

Když tuto hodnotu přepíšete, agent prostředků použije nové nastavení pro REQUIRED_COPIES_TO_COMMIT a přestane tuto hodnotu počítat. V případě potřeby ho musíte aktualizovat ručně (například pokud zvýšíte 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	Musíte ručně vydat FAILOVER. Může způsobit ztrátu dat. Nový primární 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	Musíte ručně vydat FAILOVER. Může způsobit ztrátu dat. Nový primární je R/W.	Primární je režim čtení/zápisu (R/W).
REQUIRED_COPIES_TO_COMMIT = 1 1	Cluster automaticky problémy FAILOVER. Žádná ztráta dat. Nový primární je R/W.	Primární je režim čtení/zápisu (R/W).

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

Související obsah

• Skupiny dostupnosti pro SQL Server v Linuxu