Dela via

Hög tillgänglighet och dataskydd för konfigurationer av tillgänglighetsgrupper

gäller för:SQL Server – Linux

I den här artikeln beskrivs distributionskonfigurationer som stöds för SQL Server AlwaysOn-tillgänglighetsgrupper på Linux-servrar. En tillgänglighetsgrupp stöder hög tillgänglighet och dataskydd. Automatisk felidentifiering, automatisk redundans och transparent återanslutning efter redundans ger hög tillgänglighet. Synkroniserade repliker ger dataskydd.

I ett Windows Server-redundanskluster (WSFC) använder en vanlig konfiguration för hög tillgänglighet två synkrona repliker och en tredje server eller filresurs för att tillhandahålla kvorum. Vittnet för filresursdelning validerar konfigurationen av tillgänglighetsgruppen – till exempel synkroniseringens status och replikans roll. Den här konfigurationen säkerställer att den sekundära repliken som valts som redundansmål har de senaste konfigurationsändringarna för data och tillgänglighetsgrupper.

WSFC synkroniserar konfigurationsmetadata för felfördelning mellan tillgänglighetsgruppens repliker och filresursvittnet. När en tillgänglighetsgrupp inte finns på en WSFC lagrar SQL Server-instanserna konfigurationsmetadata i master databasen.

En tillgänglighetsgrupp i ett Linux-kluster har CLUSTER_TYPE = EXTERNALtill exempel . Det finns ingen WSFC för att hantera övergång. I det här fallet hanteras och underhålls konfigurationsmetadata av SQL Server-instanserna. Eftersom det inte finns någon vittnesserver i det här klustret krävs en tredje SQL Server-instans för att lagra metadata för konfigurationstillstånd. Alla tre SQL Server-instanserna tillhandahåller tillsammans distribuerad metadatalagring för klustret.

Klusterhanteraren kan fråga instanserna av SQL Server i tillgänglighetsgruppen och koordinera failover för att upprätthålla hög tillgänglighet. I ett Linux-kluster är Pacemaker klusterhanteraren.

Från och med SQL Server 2017 (14.x) CU 1 är hög tillgänglighet för en tillgänglighetsgrupp med CLUSTER_TYPE = EXTERNAL aktiverad för två synkrona repliker plus en konfigurationsreplik. Konfigurationsrepliken kan endast finnas på valfri version av SQL Server 2017 (14.x) CU 1 eller senare versioner (inklusive SQL Server Express Edition). Konfigurationsrepliken underhåller konfigurationsinformation om tillgänglighetsgruppen i master databasen men innehåller inte användardatabaserna i tillgänglighetsgruppen.

Hur konfigurationen påverkar standardresursinställningarna

Klusterresursinställningen REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT garanterar att det angivna antalet sekundära repliker skriver transaktionsdata till loggen innan den primära repliken genomför varje transaktion. När du använder en extern klusterhanterare påverkar den här inställningen både hög tillgänglighet och dataskydd. Standardvärdet för inställningen beror på arkitekturen när klusterresursen skapas. När du installerar SQL Server-resursagenten – mssql-server-ha – och skapar en klusterresurs för tillgänglighetsgruppen identifierar klusterhanteraren konfigurationen av tillgänglighetsgruppen och anger REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT därefter.

Om det stöds av konfigurationen anges resursagentparametern REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT till det värde som ger hög tillgänglighet och dataskydd. Mer information finns i Förståelse av SQL Server-resursagenten för pacemaker.

I följande avsnitt beskrivs standardbeteendet för klusterresursen.

Välj en tillgänglighetsgruppsdesign för att uppfylla specifika affärskrav för hög tillgänglighet, dataskydd och lässkalning.

Följande konfigurationer beskriver designmönster för tillgänglighetsgrupper och funktionerna i varje mönster. Dessa designmönster gäller för tillgänglighetsgrupper med CLUSTER_TYPE = EXTERNAL som lösningar för hög tillgänglighet.

  • Tre synkrona repliker
  • Två synkrona repliker
  • Två synkrona repliker och en konfigurationsreplik

Tre synkrona repliker

Den här konfigurationen består av tre synkrona repliker. Som standard ger den hög tillgänglighet och dataskydd. Det kan också ge skalbar läsförmåga.

Diagram som visar tre synkrona repliker.

En tillgänglighetsgrupp med tre synkrona repliker kan erbjuda kapacitet för flera samtidiga läsningar, hög tillgänglighet och dataskydd. I följande tabell beskrivs tillgänglighetsbeteende.

Tillgänglighetsbeteende läsoptimering Hög tillgänglighet och
dataskydd		 Dataskydd
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
Primärt avbrott Automatiskt felsäkerhetsövergång. Kan ha dataförlust. Ny primär är R/W. Automatiskt felsäkerhetsövergång. Ny primär är R/W. Automatiskt felsäkerhetsövergång. Den nya primära servern är inte tillgänglig för läs- eller skrivtransaktioner tills den tidigare primära servern återställs och återansluter till tillgänglighetsgrupp som sekundär server.
Ett sekundärt replikavbrott R/W är primär. Sekundära resurser är tillgängliga för läsningar. R/W är primär. Sekundära resurser är tillgängliga för läsningar. Den primära förblir otillgänglig för läs- eller skrivtransaktioner tills den felande sekundära återhämtar sig och återansluter till tillgänglighetsgruppen.
Två sekundära replikernas avbrott Den primära är endast tillgänglig för läsningar och inte för skrivningar förrän en av de sekundära replikerna återställs och återansluts till tillgänglighetsgruppen. Den primära är endast tillgänglig för läsningar och inte för skrivningar förrän en av de sekundära replikerna återställs och återansluts till tillgänglighetsgruppen. Den primära förblir inte tillgänglig för läs- eller skrivtransaktioner tills alla misslyckade sekundära repliker återställs och återansluts till tillgänglighetsgruppen.
Primärt replikavbrott och ett sekundärt avbrott Automatiskt felsäkerhetsövergång. Kan ha dataförlust. Den nya primära är endast tillgänglig för läsningar och inte för skrivningar förrän en av de sekundära replikerna återställs och återansluts till tillgänglighetsgruppen. Automatiskt felsäkerhetsövergång. Ny primär replika är endast tillgänglig för läsoperationer och skrivoperationer tills en av de sekundära replikerna återställs och återansluts till tillgänglighetsgruppen. Automatiskt felsäkerhetsövergång. Ny primär förblir otillgänglig för läs- eller skrivtransaktioner tills den tidigare primära och den sekundära repliken återställs och återansluts till tillgänglighetsgruppen.

1 Förval

Två synkrona repliker

Den här konfigurationen aktiverar dataskydd. Precis som de andra konfigurationerna för tillgänglighetsgrupper kan den aktivera funktionalitet för att skala läsningar. Konfigurationen av två synkrona repliker ger inte automatisk hög tillgänglighet. En konfiguration med två repliker gäller endast för SQL Server 2017 (14.x) RTM och stöds inte längre med högre (CU1 och senare) versioner av SQL Server 2017 (14.x).

Diagram som visar två synkrona repliker.

En tillgänglighetsgrupp med två synkrona repliker ger lässkalning och dataskydd. I följande tabell beskrivs tillgänglighetsbeteende.

Tillgänglighetsbeteende läsoptimering Dataskydd
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primärt avbrott Automatiskt felsäkerhetsövergång. Kan ha dataförlust. Ny primär är R/W. Automatiskt felsäkerhetsövergång. Den nya primären är inte tillgänglig för läs- eller skrivtransaktioner tills den tidigare primären återställs och återansluter till tillgänglighetsgruppen som sekundär.
Ett sekundärt replikavbrott Den primära funktionen är R/W, som körs med risk för dataförlust. Den primära förblir otillgänglig för läs- eller skrivtransaktioner tills den felande sekundära återhämtar sig och återansluter till tillgänglighetsgruppen.

1 Förval

Två synkrona repliker och en konfigurationsreplik

En tillgänglighetsgrupp med två (eller flera) synkrona repliker och en konfigurationsreplik ger dataskydd och kan också ge hög tillgänglighet. Följande diagram representerar den här arkitekturen:

Diagram som visar en tillgänglighetsgrupp med endast konfiguration.

  1. Synkron replikering av användardata till den sekundära repliken. Den innehåller även konfigurationsmetadata för tillgänglighetsgrupper.
  2. Synkron replikering av konfigurationsmetadata för tillgänglighetsgrupp. Den innehåller inte användardata.

I diagrammet för tillgänglighetsgrupp skickar en primär replik konfigurationsdata till både den sekundära repliken och den enda konfigurationsrepliken. Den sekundära repliken tar också emot användardata. Konfigurationsrepliken tar inte emot användardata. Den sekundära repliken är i synkront tillgänglighetsläge. Konfigurationsrepliken innehåller inte databaserna i tillgänglighetsgruppen – endast metadata om tillgänglighetsgruppen. Konfigurationsdata på den enbart konfiguration-replikan konsolideras synkront.

Anmärkning

En tillgänglighetsgrupp med endast konfigurationsreplik är ny för SQL Server 2017 (14.x) CU 1. Alla instanser av SQL Server i tillgänglighetsgruppen måste vara SQL Server 2017 (14.x) CU 1 eller senare versioner.

Standardvärdet för REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT är 0. I följande tabell beskrivs tillgänglighetsbeteende.

Tillgänglighetsbeteende Hög tillgänglighet och
dataskydd		 Dataskydd
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
Primärt avbrott Automatiskt felsäkerhetsövergång. Ny primär är R/W. Kan ha dataförlust. Automatiskt felsäkerhetsövergång. Den nya primären är inte tillgänglig för läs- eller skrivtransaktioner tills den tidigare primären återställs och återansluter till tillgänglighetsgruppen som sekundär.
Sekundärt replikanavbrott Det primära är R/W och riskerar dataförlust (om det primära misslyckas och inte kan återställas). Ingen automatisk redundansväxling om den primära redundansen också misslyckas. Den primära förblir otillgänglig för läs- eller skrivtransaktioner tills den felande sekundära återhämtar sig och återansluter till tillgänglighetsgruppen. Ingen replika att växla över till om den primära också slutar fungera.
Konfigurationsbaserat replikavbrott R/W är primär. Ingen automatisk redundansväxling om den primära redundansen också misslyckas. R/W är primär. Ingen automatisk redundansväxling om den primära redundansen också misslyckas.
Synkront sekundär- och konfigurationsendast replikaavbrott Den primära noden är inte tillgänglig för läs- och skrivoperationer. Ingen automatisk redundansväxling. Den primära noden är inte tillgänglig för läs- och skrivoperationer. Ingen replika att växla över till om den primära också slutar fungera.

1 Förval

Anmärkning

Instansen av SQL Server som endast är värd för konfigurationsrepliken kan också vara värd för andra databaser. Den kan också delta som en databas för endast konfiguration för mer än en tillgänglighetsgrupp.

Kravspecifikation

  • Alla repliker i en tillgänglighetsgrupp med en konfigurationsreplik måste vara SQL Server 2017 (14.x) CU 1 eller senare versioner.
  • Alla versioner av SQL Server kan vara värd för en konfigurationsreplik, inklusive SQL Server Express.
  • Tillgänglighetsgruppen behöver minst en sekundär replik – utöver den primära repliken.
  • Endast repliker för konfiguration räknas inte mot det maximala antalet repliker per instans av SQL Server. SQL Server Standard Edition tillåter upp till tre repliker, SQL Server Enterprise Edition tillåter upp till 9.

Överväganden

  • Högst en konfigurationsreplik per tillgänglighetsgrupp.
  • En konfigurationsreplik får inte vara en primär replik.
  • Du kan inte ändra tillgänglighetsläget för en endast konfigurationsreplik. Om du vill ändra från en konfigurationsreplik till en synkron eller asynkron sekundär replik tar du bort konfigurationsrepliken och lägger till en sekundär replik med det tillgänglighetsläge som krävs.
  • En konfigurationsreplik är synkron med metadata för tillgänglighetsgruppen. Det finns inga användardata.
  • En tillgänglighetsgrupp med en primär replik och en enda konfigurationsreplik, men ingen sekundär replik är inte giltig.
  • Du kan inte skapa en tillgänglighetsgrupp på en instans av SQL Server Express Edition.

Förstå SQL Server-resursagenten för Pacemaker

SQL Server 2017 (14.x) introducerade sequence_number i sys.availability_groups för att visa om en replik markerad som SYNCHRONOUS_COMMIT var uppdaterad. sequence_number är en monotont ökande BIGINT som representerar hur up-to-date den lokala tillgänglighetsgruppens replik är med avseende på resten av replikerna i tillgänglighetsgruppen. När du utför redundansväxlingar, lägger till eller tar bort repliker och utför andra åtgärder för tillgänglighetsgruppen uppdateras det här numret. Numret uppdateras på den primära och skickas sedan till sekundära repliker. Därför har en sekundär replik som är up-to-date samma sequence_number som den primära.

När Pacemaker bestämmer sig för att höja upp en replik till primär skickar den först ett meddelande till alla repliker för att extrahera sekvensnumret och lagra det (det här meddelandet kallas för föruppflyttad avisering). När Pacemaker sedan försöker höja upp en replik till primär, höjs repliken bara upp om dess sekvensnummer är det högsta av alla sekvensnummer från alla repliker, annars avvisas uppflyttingsåtgärden. På så sätt kan endast repliken med det högsta sekvensnumret höjas upp till primärt, vilket säkerställer att inga data går förlorade.

Befordran garanteras endast att fungera så länge minst en replik som är tillgänglig för befordran har samma sekvensnummer som föregående primära. Standardbeteendet är att Pacemaker-resursagenten automatiskt ställer in REQUIRED_COPIES_TO_COMMIT så att minst en synkron kommits sekundärreplika är uppdaterad och tillgänglig, som mål för en automatisk failover. Med varje övervakningsåtgärd beräknas värdet av REQUIRED_COPIES_TO_COMMIT (och uppdateras om det behövs) som ('antalet synkrona commit-repliker' / 2). Vid redundansväxlingen kräver resursagenten sedan (total number of replicas - required_copies_to_commit repliker) för att svara på föruppflyttade meddelanden för att kunna höja upp en av dem till primär. Repliken med den högsta sequence_number uppgraderas till primär replika.

Låt oss till exempel överväga fallet med en tillgänglighetsgrupp med tre synkrona repliker – en primär replik och två synkrona commit-repliker.

  • REQUIRED_COPIES_TO_COMMIT är 3 / 2 = 1

  • Det antal repliker som krävs för att svara på föruppflyttade åtgärder är 3–1 = 2. Därför måste två repliker vara igång för att redundansväxlingen ska utlösas. När ett primärt avbrott inträffar kan resursagenten inte garantera att den sekundära repliken som svarade har högre sequence_number värde och en redundansväxling utlöses inte om en av de sekundära replikerna är okontaktbar och endast en av dem svarar på åtgärden före promotion.

En användare kan välja att åsidosätta standardbeteendet och konfigurera resursen för tillgänglighetsgruppen så att den inte anges REQUIRED_COPIES_TO_COMMIT automatiskt som tidigare.

Viktigt!

När REQUIRED_COPIES_TO_COMMIT är 0 finns det risk för dataförlust. Om det uppstår ett avbrott i det primära systemet, utlöser resursagenten inte automatiskt en övergång. Användaren måste bestämma om de vill vänta på att primärsystemet ska återställas eller genomföra en manuell redundansväxling.

Om du vill ange REQUIRED_COPIES_TO_COMMIT till 0kör du:

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

Motsvarande kommando med crm (på SLES) är:

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

Om du vill återgå till standardberäknat värde kör du:

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Anmärkning

Att uppdatera resursegenskaper orsakar att alla repliker stoppas och startas om. Det innebär att primärt tillfälligt kommer att nedgraderas till sekundärt och sedan uppgraderas igen, vilket orsakar tillfällig skrivotillgänglighet. Det nya värdet för REQUIRED_COPIES_TO_COMMIT anges bara när replikerna startas om, så det blir inte omedelbart när pcs-kommandot körs.

Balansera hög tillgänglighet och dataskydd

Ovanstående standardbeteende gäller även för två synkrona repliker (primära + sekundära). Pacemaker inställningar REQUIRED_COPIES_TO_COMMIT = 1 för att säkerställa att den sekundära kopian alltid är uppdaterad för maximalt dataskydd.

Varning

Det här medför en högre risk för att den primära repliken blir otillgänglig på grund av planerade eller oplanerade avbrott i den sekundära repliken. Användaren kan välja att ändra standardbeteendet för resursagenten och åsidosätta REQUIRED_COPIES_TO_COMMIT till 0:

sudo pcs resource update <ag1> required_copies_to_commit=0

När den har åsidosatts använder resursagenten den nya inställningen för REQUIRED_COPIES_TO_COMMIT och slutar att använda den. Användarna måste uppdatera den manuellt (till exempel om de ökar antalet repliker).

I följande tabeller beskrivs resultatet av ett avbrott för primära eller sekundära repliker i olika resurskonfigurationer för tillgänglighetsgrupper:

Tillgänglighetsgrupp - två synkrona repliker

Konfiguration Primärt avbrott Ett sekundärt replikavbrott
REQUIRED_COPIES_TO_COMMIT = 0 Användaren måste utfärda en manuell FAILOVER.
Kan ha dataförlust.
Ny primär är R/W		 Den primära funktionen är R/W, som körs med risk för dataförlust.
REQUIRED_COPIES_TO_COMMIT = 1 1 Kluster utfärdar automatiskt FAILOVER
Ingen dataförlust.
Ny primärnod avvisar alla anslutningar tills den föregående primära noden återställs och återgår till tillgänglighetsgruppen som en sekundär nod.		 Primäret avvisar alla anslutningar tills det sekundära återhämtar sig.

1 SQL Server-resursagent för Pacemakers standardbeteende.

Tillgänglighetsgrupp – tre synkrona repliker

Konfiguration Primärt avbrott Ett sekundärt replikavbrott
REQUIRED_COPIES_TO_COMMIT = 0 Användaren måste utfärda en manuell FAILOVER.
Kan ha dataförlust.
Ny primär är R/W		 Primärt är R/W
REQUIRED_COPIES_TO_COMMIT = 1 1 Kluster FAILOVER utdelas automatiskt.
Ingen dataförlust.
Ny primär är RW		 Primärt är R/W

1 SQL Server-resursagent för Pacemakers standardbeteende.

Relaterat innehåll