SQL Server Always ON Availability Group är en lösning avsedd att uppnå hög tillgänglighet och katastrofåterställning för SQL Server-databaser. Vi kan konfigurera den här funktionen mellan Windows-baserade SQL Server-installationer, Linux-baserade SQL Server-installationer och till och med mellan Linux och Windows-baserade SQL Server-installationer tillsammans.
Tillgänglighetsgrupper är tätt integrerade med klusterteknologier i en form av automatisk failover och dataskydd genom att replikera data till sina respektive sekundära repliker. Det är dock inte alltid obligatoriskt att ha en klusterresurshanterare för att konfigurera tillgänglighetsgrupper.
För att konfigurera SQL Server-tillgänglighetsgrupper behöver vi WSFC – Windows Server Failover Cluster teknik för Windows -baserade SQL Server-installationer och PACEMAKER för Linux -baserade SQL Server-installationer.
PACEMAKER är en klusterresurshanterare med öppen källkod som vi kan använda för att hantera resurser och säkerställa systemtillgänglighet, om något fel på Linux-system skulle inträffa.
WSFC är en Microsoft-produkt utvecklad för att stödja Windows-baserade klusterkrav.
När du tittar på de konfigurerade tillgänglighetsgrupperna inom SQL Server för båda typerna av operativsystem, verkar det vara liknande i SQL Server Management Studio.
Den här artikeln förklarar dock tillgänglighetsgrupper mellan Ubuntu Linux-baserade SQL Server installationer med PACEMAKER klusterteknologi så jag kommer endast att överväga denna konfiguration.
Klustertypskonfiguration
Som jag har sagt ovan har vi tre varianter för att konfigurera tillgänglighetsgrupper för SQL Server, beroende på operativsystemet:
- mellan Windows-baserade SQL Server-installationer;
- mellan Linux-baserade SQL Server-installationer;
- mellan den blandade typen av Windows- och Linux-baserade SQL Server-installationer.
Microsoft har introducerat Cluster_type konfigurationsinställning för att identifiera och konfigurera en lämplig klusterteknik för tillgänglighetsgrupper. Det är ett konfigurationsobjekt som definierar vilken typ av klusterteknologi vi använder för Availability Groups, oavsett vilket OS SQL Server-instansen är baserad på.
Du kan hämta och validera den befintliga konfigurationen av klustertypen med SQL Server Dynamic Management View (DMV) sys.availability_groups . Det finns två kolumner som heter klustertyp och cluster_type_desc . Vi kan läsa dessa kolumner för att definiera klustertypskonfigurationen för tillgänglighetsgruppen.
Denna konfigurationsinställning har 3 värden för att uppfylla klusterteknikkraven för varje variant:
WSFC .Du måste använda alternativet WSFC (Windows server failover cluster) om du har Windows-baserade SQL Server-installationer. Det stöds inte för Linux-baserade SQL Server-installationer.
EXTERN . Om du konfigurerar tillgänglighetsgrupper mellan Linux-baserade SQL Server-installationer måste du använda PACEMAKER-klusterhanteraren och välja EXTERN kluster typ . Säkerhetsläget måste också vara EXTERNT (i WSFC kommer det att vara Automatiskt).
INGEN . Om du inte vill använda någon klustringsteknik för dina tillgänglighetsgrupper väljer du INGEN . Det här alternativet är tillämpligt om du vill konfigurera tillgänglighetsgrupper mellan Linux- och Windows-baserade SQL Server-instanser. Även om du har konfigurerat kluster för ditt system, när du väl har ställt in klustertypvärdet till INGEN, kommer tillgänglighetsgrupperna inte att använda klustertekniken. Säkerhetsläget för klustertypen NONE är alltid Manuellt .
En ny inställning:Synkroniserade sekundärer krävs för att begå
Från och med SQL Server 2017 har Microsoft introducerat en ny inställning som heter required_synchronized_secondaries_to_commit . Den aktiverar alternativet för automatisk failover om du har konfigurerat klustertypen som EXTERN för PACEMAKER-klusterkonfigurationen.
Den här inställningens värde ställs in som standard när du konfigurerar SQL Server-resursagenten mssql-server-ha och skapa klusterkonfigurationen.
Du kan också manuellt ändra värdet för dina krav genom att köra kommandot nedan:
--Run below commands to change value for setting required_synchronized_secondaries_to_commit
--AGResourceName is the name of the resource configured for the Availability group
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>
Obs:Vi kan endast ändra ovanstående inställning via Pacemaker på Linux. Det är omöjligt att ändra det med T-SQL-satsen för Linux-baserade distributioner. Men för Windows-baserade distributioner kan vi ändra den här inställningen med en T-SQL-sats.
Nedan finns de möjliga värdena för required_synchronized_secondaries_to_commit
0 – Det betyder att sekundära repliker inte behöver synkroniseras med respektive primär replika. Den stöder alltså inte den automatiska failover. Du måste initiera failover manuellt om den primära repliken går ner. Viktigt:det finns en risk för dataförlust när du väljer detta värde för konfiguration.
1 – Det betyder att minst en sekundär replik måste vara i synkroniserat tillstånd för att uppnå automatisk failover.
2 – Det betyder att båda sekundära replikerna måste synkroniseras med den primära repliken. Den automatiska failover stöds.
Repliker för att delta i en tillgänglighetsgrupp
Antalet repliker som kan delta i en tillgänglighetsgrupp beror på den installerade SQL Server-utgåvan.
- SQL Server Standard utgåvan stöder endast två-nodsreplik för en tillgänglighetsgrupp tillsammans med den ytterligare repliken som endast är konfigurerad.
- SQL Server Enterprise utgåvan stöder upp till nio repliker – en primär och åtta sekundära repliker.
Eftersom SQL Server Standard Edition endast stöder två repliker (en primär replik och en sekundär replik), har Microsoft introducerat ett nytt koncept som kallas replika endast för konfiguration i SQL Server 2017 CU1 för att uppnå automatisk failover för SQL-servrar som körs på Linux-system.
Det finns två möjliga designalternativ:
- Tre synkrona repliker. Denna konfiguration kan endast distribueras med SQL Server Enterprise-utgåvan. Det kommer att finnas 3 kopior av dina tillgänglighetsdatabaser. Denna arkitektur tillåter alla tre funktionerna lässkala, hög tillgänglighet och dataskydd.
- Två synkrona repliker och en konfigurationsreplika. Du kan också konfigurera den här designen med hjälp av SQL Server Standard-utgåvan, och köra två synkrona repliker på SQL Server Standard-utgåvan och de tre replikerna på SQL Server Express-utgåvan som fungerar som enbart konfigurationsreplika. Det är en kostnadseffektiv design som stöder hög tillgänglighet med automatisk failover och databasskydd.
Tvånodsreplika
replikkonfigurationer med två noder for Availability Groups är ett mycket populärt distributionsalternativ för att säkerställa hög tillgänglighet för SQL Server-databaser. Vi uppnår den automatiska failover med hjälp av Windows Server Failover Cluster-teknologin och ett fildelningsvittne i Windows-baserade SQL Server-distributioner.
Fildelningen används i allmänhet på en extra nod i WSFC för att tillhandahålla kvorumkonfiguration för replikkonfigurationer med två noder. WSFC synkroniserar all konfigurationsmetadata till både repliker och på den tredje noden eller fildelningsvittnet för smidig failover. All failover-arbitrering för Windows-baserad SQL Server-tillgänglighetsgrupp sker i WSFC-lagret.
Om vi vill uppnå den automatiska failover för Linux-baserade SQL Server Availability Group-distributioner, kommer ovanstående konfiguration inte att fungera. Det beror på att WSFC endast kan användas för Windows-baserade SQL Server-installationer.
För att komma till rätta med denna begränsning och möjliggöra automatisk failover för Linux-baserade distributioner med två repliker har Microsoft introducerat ett nytt koncept.
Replika endast för konfiguration
En replika endast för konfiguration är ett alternativ där vi installerar ytterligare en instans av SQL Server på den tredje noden. Den noden kommer att fungera som en vittnesserver för replikkonfigurationen med två noder för att stödja automatisk failover. Vi kan skapa en replik för endast konfiguration per tillgänglighetsgrupp .
För Linux-baserade SQL Server-instanser där vi använder klustertyp som EXTERN för PACEMAKER, fungerar inte failover-arbitreringen i klusterlager som WSFC. All failover-arbitrering sker i SQL Server-lagret eftersom all konfigurationsmetadata för tillgänglighetsgrupp lagras i huvuddatabaserna för varje replik.
Microsoft har introducerat replikkonceptet för endast konfiguration för att hantera kvorum för Linux-baserade SQL Server-tillgänglighetsgrupper. Detta koncept är inte värd för några användardatabaser för att delta i en tillgänglighetsgrupp. Den lagrar all konfigurationsinformation för Availability Group i huvuddatabasen för att säkerställa att all failover-arbitering sker smidigt.
Du kan använda vilken utgåva av SQL Server som helst för repliken endast för konfiguration. Även SQL Server Express-utgåvan passar för att spara din licenskostnad för den tredje repliken. Kom ihåg att repliken endast för konfiguration inte kommer att vara värd för någon databas inom tillgänglighetsgruppen. Således kommer du bara att ha två kopior av databaser i en tillgänglighetsgrupp.
Som standard är required_synchronized_secondaries_to_commit är inställd på 0 när vi använder repliken endast för konfiguration. Vi kan manuellt ändra detta värde till 1 om det behövs.
Ta en titt på designdiagrammet för den synkrona repliken med två noder och en replik som endast är konfigurerad för att uppnå automatisk failover och dataskydd.
Vi kan se att det finns 3 virtuella datorer som heter AOAGVM1, AOAGVM2 och AOAGVM3. De körs alla av Ubuntu Linux-systemet, och SQL Server är konfigurerad på alla tre Linux-systemen. Tillgänglighetsdatabaserna finns på AOAGVM1 och AOAGVM2.
AOAGVM1 fungerar som en primär replika, medan AOAGVM2 är en sekundär replik. AOAGVM3 fungerar som repliken endast för konfiguration, vilket är SQL Server Express-utgåvan. Inga användardatabaser finns på denna tredje replik.
Pacemaker-klustret har konfigurerats mellan alla tre noderna för att stödja klusterteknologin för Linux-baserad tillgänglighetsgruppkonfiguration.
För att konfigurera eller implementera ovanstående design måste vi utföra följande steg:
- Installera SQL Server på tre Ubuntu-system (SQL Server Express-utgåvan lämpar sig för repliker som endast kan konfigureras).
- Konfigurera tillgänglighetsgrupper mellan tre noder.
- Konfigurera PACEMAKER-klustret mellan tre noder.
- Lägg till eller integrera tillgänglighetsgrupp som en resurs i klustergruppen.
Ta en titt på den relaterade artikeln för att slutföra steg 1 (installera SQL Server-instanser på tre noder).
Håll utkik efter min nästa artikel där jag kommer att förklara steg-för-steg-processen för att implementera ovanstående design. Vårt mål kommer att vara att uppnå automatisk failover och dataskydd med den synkrona repliken med två noder och en replik som endast är konfigurerad.
Vi kommer gärna att höra dina tankar och praktiska tips i denna fråga. Dela dem gärna i kommentarsektionen.