Tillgänglighetsgrupper för SQL Server i Linux

gäller för:SQL Server – Linux

I den här artikeln beskrivs egenskaperna för tillgänglighetsgrupper (AG:er) under Linux-baserade SQL Server-installationer. Den omfattar även skillnader mellan WSFC-baserade AG:er (Linux- och Windows Server Failover Cluster). Se Vad är en AlwaysOn-tillgänglighetsgrupp? för grunderna i AG:er, eftersom de fungerar på samma sätt i Windows och Linux förutom WSFC.

Från en övergripande synvinkel är tillgänglighetsgrupper under SQL Server på Linux desamma som de är på WSFC-baserade implementeringar. Det innebär att alla begränsningar och funktioner är desamma, med vissa undantag. De största skillnaderna är:

• Microsoft Distributed Transaction Coordinator (DTC) stöds under Linux från och med SQL Server 2017 CU 16. DTC stöds dock inte ännu i tillgänglighetsgrupper i Linux. Om dina program kräver användning av distribuerade transaktioner och behöver en tillgänglighetsgrupp (AG) ska du distribuera SQL Server på Windows.
• Linux-baserade distributioner som kräver hög tillgänglighet använder Pacemaker för klustring i stället för en WSFC.
• Till skillnad från de flesta konfigurationer för AG:er i Windows förutom scenariot arbetsgruppskluster kräver Pacemaker aldrig Active Directory Domain Services (AD DS).
• Hur du växlar över en tillgänglighetsgrupp från en nod till en annan skiljer sig mellan Linux och Windows.
• Vissa inställningar som required_synchronized_secondaries_to_commit kan bara ändras via Pacemaker i Linux, medan en WSFC-baserad installation använder Transact-SQL.

Antal repliker och klusternoder

En tillgänglighetsgrupp i SQL Server Standard Edition kan ha två repliker totalt: en primär och en sekundär som endast kan användas för tillgänglighet. Det kan inte användas för något annat, till exempel läsbara frågor. En tillgänglighetsgrupp i SQL Server Enterprise-utgåvan kan ha upp till totalt nio repliker: en primär och upp till åtta sekundärer, varav upp till tre (inklusive den primära) kan vara synkrona. Om du använder ett underliggande kluster kan det finnas högst 16 noder totalt när Corosync ingår. En tillgänglighetsgrupp kan sträcka sig över högst nio av de 16 noderna med SQL Server Enterprise Edition och två med SQL Server Standard Edition.

En konfiguration med två repliker som kräver möjligheten att automatiskt redundansväxla till en annan replik kräver användning av en konfigurationsreplik, enligt beskrivningen i Replik och kvorum med endast konfiguration. Repliker med endast konfiguration introducerades i SQL Server 2017 (14.x) Kumulativ uppdatering 1 (CU 1), så det bör vara den minimiversion som distribueras för den här konfigurationen.

Om Pacemaker används måste den vara korrekt konfigurerad så att den förblir igång. Det innebär att kvorum och fencing av en felaktig nod måste implementeras korrekt från ett Pacemaker-perspektiv, utöver alla SQL Server-krav, som till exempel en replik med endast konfiguration.

Läsbara sekundära repliker stöds endast med SQL Server Enterprise Edition.

Klustertyp och redundansläge

Nytt för SQL Server 2017 (14.x) är introduktionen av en klustertyp för AG:er. För Linux finns det två giltiga värden: Extern och Ingen. En klustertyp av Extern innebär att Pacemaker används under tillgänglighetsgruppen. Om du använder Extern för klustertyp måste även redundansläget vara inställt på Externt (även nytt i SQL Server 2017 (14.x)). Automatisk redundans stöds, men till skillnad från en WSFC är redundansläget inställt på Externt, inte automatiskt, när Pacemaker används. Till skillnad från en WSFC skapas Pacemaker-delen av AG när AG har konfigurerats.

En klustertyp av "None" innebär att det inte finns något krav på Pacemaker, och att tillgänglighetsgruppen inte använder det. Även på servrar som har Pacemaker konfigurerat, om en tillgänglighetsgrupp har konfigurerats med en klustertyp av Ingen, ser eller hanterar Pacemaker inte den tillgänglighetsgruppen. En klustertyp av None stöder endast manuell redundans från en primär till en sekundär replik. En tillgänglighetsgrupp som skapats med None är främst avsedd för uppgraderingar och utskalning. Även om det kan fungera i scenarier som haveriberedskap eller lokal tillgänglighet där ingen automatisk redundans krävs, rekommenderas det inte. Lyssnarberättelsen är också mer komplex utan Pacemaker.

Klustertypen lagras i SQL Server dynamic management view (DMV) sys.availability_groups, i kolumnerna cluster_type och cluster_type_desc.

krävs_synkroniserade_sekunder_för_att_begå

Nytt i SQL Server 2017 (14.x) är en inställning som används av AG:er med namnet required_synchronized_secondaries_to_commit. Detta meddelar AG hur många sekundära repliker som måste vara synkroniserade med den primära. Detta möjliggör till exempel automatisk redundans (endast när det är integrerat med Pacemaker med en klustertyp av extern) och styr beteendet för saker som tillgängligheten för den primära om rätt antal sekundära repliker antingen är online eller offline. Mer information om hur detta fungerar finns i Hög tillgänglighet och dataskydd för konfigurationer av tillgänglighetsgrupper. Värdet required_synchronized_secondaries_to_commit anges som standard och underhålls av Pacemaker/SQL Server. Du kan åsidosätta det här värdet manuellt.

Kombinationen av required_synchronized_secondaries_to_commit och det nya sekvensnumret (som lagras i sys.availability_groups) informerar Pacemaker och SQL Server om att en automatisk failover, till exempel, kan ske. I så fall skulle en sekundär replik ha samma sekvensnummer som det primära, vilket innebär att den är uppdaterad med all den senaste konfigurationsinformationen.

Det finns tre värden som kan anges för required_synchronized_secondaries_to_commit: 0, 1 eller 2. De kontrollerar hur det går till när en replik blir otillgänglig. Talen motsvarar antalet sekundära repliker som måste synkroniseras med den primära repliken. Beteendet är följande under Linux:

required_synchronized_secondaries_to_commit styr inte bara beteendet för failover med synkrona repliker, utan även dataförlust. Med värdet 1 eller 2 måste en sekundär replik alltid synkroniseras för att säkerställa dataredundans. Det innebär ingen dataförlust.

Om du vill ändra värdet required_synchronized_secondaries_to_commitför använder du följande syntax:

Red Hat Enterprise Linux (RHEL) och Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>

SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

I det här exemplet <AGResourceName> är namnet på resursen som konfigurerats för Tillgänglighetsgruppen och <value> är 0, 1 eller 2. Om du vill återställa den till standardinställningen där Pacemaker hanterar parametern, utför samma kommando utan värde.

Automatisk överflyttning av en tillgänglighetsgrupp (AG) är möjlig när följande villkor uppfylls:

• Den primära och den sekundära repliken är inställda på synkron dataförflyttning.
• Den sekundära har tillståndet synkroniserad (synkroniseras inte), vilket innebär att de två är på samma datapunkt.
• Klustertypen är inställd på Extern. Automatisk redundans är inte möjligt med klustertypen Ingen.
• Den sequence_number sekundära repliken som ska bli den primära har det högsta sekvensnumret , med andra ord matchar den sekundära repliken sequence_number den från den ursprungliga primära repliken.

Om dessa villkor är uppfyllda och servern som hostar den primära repliken misslyckas, skiftar tillgänglighetsgruppen ägarskapet till en synkron replik. Beteendet för synkrona repliker (varav det kan finnas tre totalt: en primär och två sekundära repliker) kan styras ytterligare av required_synchronized_secondaries_to_commit. Detta fungerar med AG:er på både Windows och Linux, men har konfigurerats på olika sätt. I Linux konfigureras värdet automatiskt av klustret på själva tillgänglighetsgruppens resurs.

Konfigurationsendast replik och kvorum

En konfigurationsreplik introducerades för att åtgärda begränsningar i kvorumhanteringen med Pacemaker, särskilt när en misslyckad nod stängs. En konfiguration med bara två noder fungerar inte för en AG. För en FCI kan kvorummekanismerna som tillhandahålls av Pacemaker vara bra eftersom all FCI-failover-arbitrering sker på klusternivån. För en AG sker arbitrering under Linux i SQL Server, där all metadata lagras. Det är här som den konfigurationsbaserade repliken spelar in.

Utan något annat krävs en tredje nod och minst en synkroniserad replik. Konfigurations-endast-repliken lagrar tillgänglighetsgruppens konfiguration i master-databasen, precis som de andra replikerna i tillgänglighetsgruppens konfiguration. Den konfigurationsspecifika repliken har inte de användardatabaser som deltar i tillgänglighetsgruppen. Konfigurationsdata skickas synkront från den primära. Dessa konfigurationsdata används sedan under redundansväxlingar, oavsett om de är automatiska eller manuella.

För att en tillgänglighetsgrupp ska kunna underhålla kvorum och aktivera automatiska redundansväxlingar med klustertypen Extern måste den antingen:

• Ha tre synkrona repliker (endast SQL Server Enterprise Edition); eller
• Ha två repliker (primär och sekundär) och en endast konfigurationsreplik.

Manuella redundansväxlingar kan inträffa, oavsett om du använder klustertyperna Externa eller Inga för AG-konfigurationer. Även om en konfigurationsreplik kan konfigureras med en tillgänglighetsgrupp som har en klustertyp av Ingen, rekommenderas den inte eftersom den komplicerar distributionen. För dessa konfigurationer ändrar du required_synchronized_secondaries_to_commit manuellt för att ha ett värde på minst 1, så att det finns minst en synkroniserad replik.

En konfigurationsreplik kan finnas på valfri utgåva av SQL Server, inklusive SQL Server Express. Detta minimerar licenskostnaderna och säkerställer att det fungerar med AG:er i SQL Server Standard Edition. Det innebär att den tredje obligatoriska servern bara behöver uppfylla de minimikrav för SQL Server, eftersom den inte tar emot användartransaktionstrafik för AG.

När en endast konfigurationsreplik används har den följande beteenden:

• Som standard required_synchronized_secondaries_to_commit är värdet 0. Detta kan ändras manuellt till 1 om du vill.

• Om den primära misslyckas och required_synchronized_secondaries_to_commit är 0 blir den sekundära repliken den nya primära och blir tillgänglig för både läsning och skrivning. Om värdet är 1 sker automatisk failover, men systemet accepterar inte nya transaktioner förrän den andra repliken är online.

• Om en sekundär replik misslyckas och required_synchronized_secondaries_to_commit är 0 accepterar den primära repliken fortfarande transaktioner, men om det primära misslyckas just nu finns det inget skydd för data eller redundans (manuell eller automatisk), eftersom en sekundär replik inte är tillgänglig.

• Om konfigurationsrepliken misslyckas fungerar tillgänglighetsgruppen normalt, men ingen automatisk redundansväxling är möjlig.

• Om den synkrona sekundära repliken och den endast konfigurationsrepliken misslyckas kan den primära inte acceptera transaktioner, och det finns ingenstans för den primära att redundansväxla till.

Flera tillgänglighetsgrupper

Fler än en AG kan skapas per Pacemaker-kluster eller uppsättning servrar. Den enda begränsningen är systemresurser. AG:s ägarskap visas av huvudenheten. Olika AG:er kan ägas av olika noder. alla behöver inte köras på samma nod.

Enhet och mappplats för databaser

Precis som i Windows-baserade AG:er bör enhets- och mappstrukturen för användardatabaserna som deltar i en AG vara identisk. Om användardatabaserna till exempel finns i /var/opt/mssql/userdata server A bör samma mapp finnas på Server B. Det enda undantaget till detta anges i avsnittet Interoperabilitet med Windows-baserade tillgänglighetsgrupper och repliker.

Lyssnaren under Linux

Lyssnaren är en valfri funktion för en AG. Den tillhandahåller en enda inträdespunkt för alla anslutningar (läs/skriv till den primära repliken och/eller skrivskyddad åtkomst till sekundära repliker) så att program och slutanvändare inte behöver veta vilken server som är värd för data. I en WSFC är detta kombinationen av en nätverksnamnsresurs och en IP-resurs, som sedan registreras i AD DS (om det behövs) och DNS. I kombination med själva AG-resursen tillhandahåller den abstraktionen. Mer information om en lyssnare finns i Ansluta till en AlwaysOn-tillgänglighetsgrupplyssnare.

Lyssnaren under Linux är konfigurerad på olika sätt, men dess funktioner är desamma. Det finns inget begrepp för en nätverksnamnsresurs i Pacemaker, inte heller ett objekt som skapats i AD DS. Det finns bara en IP-adressresurs som skapats i Pacemaker som kan köras på någon av noderna. En post associerad med IP-resursen för lyssnaren i DNS med ett "vänligt namn" måste skapas. IP-resursen för lyssnaren är bara aktiv på servern som är värd för den primära repliken för tillgänglighetsgruppen.

Om Pacemaker används och en IP-adressresurs skapas som är associerad med lyssnaren uppstår ett kort avbrott när IP-adressen stoppas på den ena servern och startar på den andra, oavsett om det är automatisk eller manuell redundansväxling. Även om detta ger abstraktion genom kombinationen av ett enda namn och en IP-adress, maskerar det inte avbrott. Ett program måste kunna hantera frånkopplingen genom att ha någon form av funktioner för att identifiera detta och återansluta.

Kombinationen av DNS-namnet och IP-adressen räcker dock fortfarande inte för att tillhandahålla alla funktioner som en lyssnare på en WSFC tillhandahåller, till exempel skrivskyddad routning för sekundära repliker. När du konfigurerar en tillgänglighetsgrupp måste du fortfarande konfigurera en lyssnare i SQL Server. Detta kan ses i guiden och Transact-SQL-syntaxen. Det finns två sätt att konfigurera detta så att det fungerar på samma sätt som i Windows:

• För en tillgänglighetsgrupp med en klustertyp av extern bör IP-adressen som är associerad med lyssnaren som skapats i SQL Server vara IP-adressen för resursen som skapades i Pacemaker.
• För en tillgänglighetsgrupp som skapats med klustertypen None använder du IP-adressen som är associerad med den primära repliken.

Den instans som är associerad med den angivna IP-adressen blir sedan koordinator för saker som skrivskyddade routningsbegäranden från program.

Samverkan med Windows-baserade tillgänglighetsgrupper och repliker

En tillgänglighetsgrupp som har en klustertyp av extern eller en som är WSFC kan inte ha sina repliker mellan plattformar. Detta gäller oavsett om tillgänglighetsgruppen (AG) är SQL Server Standard Edition eller SQL Server Enterprise Edition. Det innebär att i en traditionell AG-konfiguration med ett underliggande kluster kan en replik inte finnas på en WSFC och den andra på Linux med Pacemaker.

En tillgänglighetsgrupp med klustertypen NONE kan ha sina repliker över OS-gränser, så det kan finnas både Linux- och Windows-baserade repliker i samma tillgänglighetsgrupp. Ett exempel visas här där den primära repliken är Windows-baserad, medan den sekundära är på en av Linux-distributionerna.

En distribuerad tillgänglighetsgrupp kan också korsa operativsystemgränser. De underliggande tillgänglighetsgrupperna (AG:erna) är bundna av reglerna för hur de konfigureras, till exempel en som är konfigurerad med "Extern" uteslutande för Linux, men den tillgänglighetsgrupp som den är ansluten till kan konfigureras med hjälp av en WSFC. Tänk på följande exempel:

Relaterat innehåll

• Konfigurera SQL Server-tillgänglighetsgrupp för hög tillgänglighet i Linux
• Konfigurera en SQL Server-tillgänglighetsgrupp för lässkalning i Linux
• Konfigurera ett Pacemaker-kluster för SQL Server-tillgänglighetsgrupper
• Konfigurera SQL Server AlwaysOn-tillgänglighetsgrupp i Windows och Linux (plattformsoberoende)