Affärskontinuitet och databasåterställning – SQL Server

gäller för: SQL Server 2016 (13.x) och senare versioner

Den här artikeln innehåller en översikt över lösningar för affärskontinuitet för hög tillgänglighet och haveriberedskap i SQL Server, i Windows och Linux.

En vanlig uppgift som alla som distribuerar SQL Server måste ta hänsyn till är att se till att alla verksamhetskritiska SQL Server-instanser och databaserna i dem är tillgängliga när företaget och slutanvändarna behöver dem, oavsett om det är 9 till 5 eller dygnet runt. Målet är att hålla verksamheten igång med minimala eller inga avbrott. Det här konceptet kallas även affärskontinuitet.

SQL Server 2017 (14.x) introducerade många nya funktioner eller förbättringar av befintliga, varav några är för tillgänglighet. Det största tillägget till SQL Server 2017 (14.x) var stödet för SQL Server på Linux-distributioner. En fullständig lista över de nya funktionerna i SQL Server finns i följande artiklar:

• Nyheter i SQL Server 2017
• Nyheter för SQL Server 2017 på Linux
• Nyheter i SQL Server 2019
• Nyheter för SQL Server 2019 i Linux
• Nyheter i SQL Server 2022

Den här artikeln fokuserar på att ta upp tillgänglighetsscenarier i SQL Server 2017 (14.x) och senare versioner, samt de nya och förbättrade tillgänglighetsfunktionerna. Scenarierna omfattar hybriddistributioner som kan omfatta SQL Server-distributioner på både Windows Server och Linux, och sådana som kan öka antalet läsbara kopior av en databas.

Även om den här artikeln inte omfattar tillgänglighetsalternativ som är externa för SQL Server, till exempel de som tillhandahålls av virtualisering, gäller allt som beskrivs här för SQL Server-installationer i en virtuell gästdator, oavsett om det är i det offentliga molnet eller som hanteras av en lokal hypervisor-server.

SQL Server-scenarier med hjälp av tillgänglighetsfunktionerna

Always On-tillgänglighetsgrupper, Always On-failover-klusterinstanser och loggöverföring kan användas på olika sätt, och inte nödvändigtvis bara i tillgänglighetssyfte. Det finns fyra huvudsakliga sätt att använda tillgänglighetsfunktionerna:

• Hög tillgänglighet
• Haveriberedskap
• Migreringar och uppgraderingar
• Skala ut läsbara kopior av en eller flera databaser

I följande avsnitt beskrivs de relevanta funktioner som kan användas för just det scenariot. Den enda funktion som inte omfattas är SQL Server-replikering. Även om det inte officiellt betecknas som en tillgänglighetsfunktion under Always On-paraplyet, används SQL Server-replikering ofta för att göra data redundant i vissa scenarier. Sammanslagningsreplikering stöds inte för SQL Server i Linux. Mer information finns i SQL Server-replikering i Linux.

Hög tillgänglighet

Det är viktigt att se till att SQL Server-instanser eller -databaser är tillgängliga i händelse av ett problem som är lokalt för ett datacenter eller en enda region i molnet. Det här avsnittet beskriver hur SQL Server-tillgänglighetsfunktionerna kan hjälpa dig med den uppgiften. Alla funktioner som beskrivs är tillgängliga både på Windows Server och i Linux.

Tillgänglighetsgrupper

Tillgänglighetsgrupper (AG) introducerades i SQL Server 2012 (11.x) och ger skydd på databasnivå genom att skicka varje transaktion av en databas till en annan instans eller replik, som innehåller en kopia av databasen i ett särskilt tillstånd. En AG kan distribueras på Standard- eller Enterprise-editioner. De instanser som deltar i en tillgänglighetsgrupp kan vara antingen fristående eller redundansklusterinstanser (FCI:er, som beskrivs i nästa avsnitt). Eftersom transaktionerna skickas till en replika när de sker, rekommenderas tillgänglighetsgrupper (AG) där det finns krav på lägre mål för återställningspunkt och återställningstid. Dataflytt mellan repliker kan vara synkron eller asynkron, med Enterprise-utgåvan som tillåter upp till tre repliker (inklusive den primära) som synkrona. En AG (tillgänglighetsgrupp) har en komplett läs- och skrivkopia av databasen som finns på den primära repliken, medan alla sekundära repliker inte kan ta emot transaktioner direkt från slutanvändare eller applikationer.

Före SQL Server 2022 (16.x) tillhandahåller AG:er endast skydd på databasnivå och inte instansnivå. Allt som inte samlas in i transaktionsloggen eller som konfigurerats i databasen måste synkroniseras manuellt för varje sekundär replik. Några exempel på objekt som måste synkroniseras manuellt är inloggningar på instansnivå, länkade servrar och SQL Server Agent-jobb.

I SQL Server 2022 (16.x) och senare versioner kan du hantera metadataobjekt som användare, inloggningar, behörigheter och SQL Server Agent-jobb på ag-nivå utöver instansnivån. Mer information finns i Vad är en innesluten tillgänglighetsgrupp?

En tillgänglighetsgrupp har också en annan komponent som kallas lyssnaren, vilket gör att program och slutanvändare kan ansluta utan att behöva veta vilken SQL Server-instans som hanterar den primära repliken. Varje AG skulle ha en egen lyssnare. Implementeringarna av lyssnaren skiljer sig något åt på Windows Server jämfört med Linux, men funktionerna som den tillhandahåller och hur den används är desamma. Följande diagram visar en Windows Server-baserad tillgänglighetsgrupp som använder ett Windows Server-redundanskluster (WSFC). Ett underliggande kluster på OS-lagret krävs för tillgänglighet oavsett om det finns på Linux eller Windows Server. Exemplet visar en enkel konfiguration med två servrar, eller noder, med en WSFC som det underliggande klustret.

Standard- och Enterprise-utgåvan har olika maxantal när det gäller repliker. En tillgänglighetsgrupp i Standard Edition, som kallas för en grundläggande tillgänglighetsgrupp, stöder två repliker (en primär och en sekundär) med endast en enda databas i tillgänglighetsgruppen. Enterprise edition möjliggör inte bara att flera databaser konfigureras i en enda tillgänglighetsgrupp, utan kan också ha upp till nio repliker totalt (en primär, åtta sekundära). Enterprise Edition ger också andra valfria fördelar som läsbara sekundära repliker, möjligheten att göra säkerhetskopior av en sekundär replik med mera.

När det gäller tillgänglighet kan AG:er tillhandahålla antingen automatisk eller manuell redundans. Automatisk failover kan inträffa om synkron datarörelse har konfigurerats och databasen på den primära och sekundära repliken är i synkroniserat läge. Så länge lyssnaren används och programmet använder en senare version av .NET Framework (3.5 med en uppdatering eller 4.0 och senare), bör redundansväxlingen hanteras med minimal till ingen effekt på slutanvändarna om en lyssnare används. Växla över till en sekundär replik för att göra den till den nya primära repliken kan konfigureras att vara automatisk eller manuell och mäts vanligtvis i sekunder.

I följande lista visas några skillnader med AG:er på Windows Server jämfört med Linux:

• På grund av skillnader i hur det underliggande klustret fungerar på Linux och Windows Server utförs alla redundansväxlingar (manuella eller automatiska) av AG:er via klustret i Linux. Vid Windows Server-baserade AG-distributioner måste manuella redundansväxlingar utföras via SQL Server. Automatiska redundansväxlingar hanteras av det underliggande klustret på både Windows Server och Linux.
• För SQL Server i Linux är den rekommenderade konfigurationen för AG:er minst tre repliker. Detta beror på hur den underliggande klustring fungerar.
• I Linux definieras det gemensamma namn som används av varje lyssnare i DNS och inte i klustret som det är på Windows Server.

SQL Server 2017 (14.x) introducerar följande funktioner och förbättringar av AG:er:

• Klustertyper
• REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
• Förbättrat stöd för Microsoft Distributor Transaction Coordinator (DTC) för Windows Server-baserade konfigurationer
• Ytterligare scale-out-scenarier för skrivskyddade databaser (beskrivs senare i den här artikeln)

Klustertyper för tillgänglighetsgrupp

Den inbyggda tillgänglighetsformen för klustring i Windows Server är aktiverad via en funktion med namnet Redundansklustring. Det möjliggör att du kan bygga en WSFC för användning med en AG eller FCI. Integrering för AG:er och FCI:er tillhandahålls av klustermedvetna resurs-DLL:er som levereras av SQL Server.

SQL Server på Linux stöder flera klustertekniker. Microsoft stöder SQL Server-komponenterna, medan våra partner stöder relevant klustringsteknik. Tillsammans med Pacemaker stöder SQL Server på Linux till exempel HPE Serviceguard och DH2i DxEnterprise som en klusterlösning.

Ett Windows-baserat failoverkluster och en Linux-klusterlösning är mer lika än olika. Båda ger ett sätt att ta enskilda servrar och kombinera dem i en konfiguration för att ge tillgänglighet och har begrepp som resurser, begränsningar (även om de implementeras annorlunda), redundans och så vidare.

För att till exempel stödja Pacemaker för både AG- och FCI-konfigurationer, inklusive saker som automatisk övergång, tillhandahåller Microsoft paketet mssql-server-ha, som liknar men är inte exakt densamma som de resurs-DLL:er som används i en WSFC, för Pacemaker. En av skillnaderna mellan en WSFC och Pacemaker är att det inte finns någon nätverksnamnresurs i Pacemaker, vilket är komponenten som hjälper till att abstrahera namnet på lyssnaren (eller namnet på FCI) på en WSFC. DNS tillhandahåller den namnmatchningen i Linux.

På grund av skillnaden i klusterstacken behövde vissa ändringar göras för AG:er eftersom SQL Server måste hantera vissa av de metadata som hanteras internt av en WSFC. En sådan betydande förändring är införandet av en klustertyp för en tillgänglighetsgrupp. Detta lagras i sys.availability_groups kolumnerna cluster_type och cluster_type_desc . Det finns tre klustertyper:

• WSFC
• Externt
• Ingen

Alla AG:er som kräver hög tillgänglighet måste använda ett underliggande kluster, som när det gäller SQL Server 2017 (14.x) och senare versioner innebär WSFC eller en Linux-klustringsagent. För Windows Server-baserade AG:er som använder en underliggande WSFC är standardklustertypen WSFC och behöver inte anges. För Linux-baserade AG:er måste klustertypen ställas in på Extern när AG:en skapas. Integreringen med en extern klusterlösning i Linux konfigureras efter att tillgänglighetsgruppen (AG) har skapats, medan konfigurationen görs under skapandet på en WSFC.

En klustertyp av Ingen kan användas med både Windows Server- och Linux-AG:er. Om du ställer in klustertypen på Ingen innebär det att AG:n (tillgänglighetsgruppen) inte kräver något underliggande kluster. Det innebär att SQL Server 2017 (14.x) är den första versionen av SQL Server som stöder AG:er utan kluster, men kompromissen är att den här konfigurationen inte stöds som en lösning med hög tillgänglighet.

För dem som bara vill lägga till ytterligare skrivskyddade kopior av en databas eller som uppskattar vad en tillgänglighetsgrupp tillhandahåller för migrering och uppgraderingar men inte vill vara bundna till den ytterligare komplexiteten i ett underliggande kluster eller till och med replikering, är en tillgänglighetsgrupp med klustertypen 'Ingen' en perfekt lösning. Mer information finns i avsnitten Migreringar och uppgraderingar och lässkalning.

Följande skärmbild visar stöd för olika typer av klustertyper i SQL Server Management Studio (SSMS). Du måste köra version 17.1 eller senare. Följande skärmbild är från version 17.2:

KRÄVD_SYNKRONISERADE_SEKUNDÄRA_FÖR_ATT_FULLBORDAS

SQL Server 2016 (13.x) ökade stödet för antalet synkrona repliker från två till tre i Enterprise-utgåvan. Men om en sekundär replik synkroniserades men den andra hade ett problem, fanns det inget sätt att kontrollera beteendet för att tala om för den primära att antingen vänta på den felaktiga repliken eller låta den gå vidare. Det innebär att den primära repliken någon gång skulle fortsätta att ta emot skrivtrafik även om den sekundära repliken inte skulle vara i ett synkroniserat tillstånd, vilket innebär att det finns dataförlust på den sekundära repliken.

I SQL Server 2017 (14.x) och senare versioner kan du styra beteendet för vad som händer när det finns synkrona repliker med REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. Det här alternativet fungerar på följande sätt:

• Det finns tre möjliga värden: 0, 1och 2
• Värdet är antalet sekundära repliker som måste synkroniseras, vilket har konsekvenser för dataförlust, AG-tillgänglighet och omkoppling.
• För WSFCs och en klustertyp av Ingen är 0standardvärdet , och kan anges manuellt till 1 eller 2
• För en klustertyp av Extern anger klustermekanismen som standard det här värdet och kan åsidosättas manuellt. För tre synkrona repliker är 1standardvärdet .

I Linux är värdet för REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT konfigurerat på AG-resursen i klustret. På Windows anges det via Transact-SQL.

Ett värde som är högre än 0 säkerställer högre dataskydd, för om det nödvändiga antalet sekundära repliker inte är tillgängligt blir den primära inte tillgänglig förrän den har lösts. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT påverkar också failover-beteendet eftersom automatisk failover inte kunde utföras om rätt antal sekundära repliker inte befann sig i rätt tillstånd. I Linux tillåter inte ett värde 0 för automatisk redundans, så när du använder synkron med automatisk redundans måste värdet anges högre än 0 för att uppnå automatisk redundans. 0 på Windows Server är det beteende som finns i SQL Server 2016 (13.x) och tidigare versioner.

Förbättrat stöd för Microsoft Distributed Transaction Coordinator

Innan SQL Server 2016 (13.x) var det enda sättet att få tillgänglighet i SQL Server för program som kräver distribuerade transaktioner, som använder DTC under täcket, att distribuera FCI:er. En distribuerad transaktion kan göras på något av två sätt:

• En transaktion som sträcker sig över mer än en databas i samma SQL Server-instans
• En transaktion som omfattar mer än en SQL Server-instans eller som eventuellt omfattar en datakälla som inte är SQL Server

SQL Server 2016 (13.x) introducerade partiellt stöd för DTC med AG:er som omfattade det senare scenariot. SQL Server 2017 (14.x) slutför berättelsen genom att stödja båda scenarierna med DTC.

I SQL Server 2017 (14.x) och senare versioner kan DTC-stöd också läggas till i en tillgänglighetsgrupp när den har skapats. I SQL Server 2016 (13.x) kunde stöd för DTC till tillgänglighetsgruppen endast aktiveras när tillgänglighetsgruppen skapades.

Klusterinstanser för failover

Klustrade installationer har varit en funktion i SQL Server sedan version 6.5. FCI:er är en beprövad metod för att tillhandahålla tillgänglighet för hela installationen av SQL Server, som kallas för en instans. Det innebär att allt i instansen, inklusive databaser, SQL Server Agent-jobb, länkade servrar och så vidare, flyttas till en annan server om den underliggande servern skulle stöta på ett problem. Alla FCI:er kräver någon form av delad lagring, även om den tillhandahålls via nätverk. FCI:ns resurser kan bara köras och ägs av en nod vid en viss tidpunkt. I följande diagram äger den första noden i klustret FCI, vilket också innebär att den äger de delade lagringsresurser som är associerade med den som anges av den solida linjen till lagringen.

Efter en redundansväxling ändras ägarskapet enligt följande diagram:

Det finns ingen dataförlust med en FCI, men den underliggande delade lagringen är en enskild felpunkt eftersom det finns en kopia av data. FCI:er kombineras ofta med en annan tillgänglighetsmetod, till exempel en tillgänglighetsgrupp eller loggöverföring, för att ha redundanta kopior av databaser. Den ytterligare metod som implementeras bör använda fysiskt separat lagring jämfört med den som används av FCI. När FCI redundansväxlar till en annan nod avbryts den på en nod och startar på en annan, likt att stänga av en server och sedan starta den. En FCI genomgår den normala återställningsprocessen, vilket innebär att alla transaktioner som behöver flyttas framåt kommer att rullas framåt, och alla transaktioner som är ofullständiga kommer att rullas tillbaka. Därför är databasen konsekvent från en datapunkt till tidpunkten för felet eller den manuella redundansväxlingen, och därmed ingen dataförlust. Databaser är bara tillgängliga när återställningen har slutförts, så återställningstiden beror på många faktorer och kommer i allmänhet att vara längre än att växla över en tillgänglighetsgrupp. Kompromissen är att när du redundansväxlar en tillgänglighetsgrupp kan det krävas extra uppgifter för att göra en databas användbar, till exempel att aktivera ett SQL Server Agent-jobb.

Precis som en tillgänglighetsgrupp döljer FCIs vilken nod i det underliggande klustret som hanterar det. En FCI behåller alltid samma namn. Program och slutanvändare ansluter aldrig till noderna. det unika namn som tilldelats till FCI används. En FCI kan delta i en tillgänglighetsgrupp som en av de instanser som är värd för antingen en primär eller sekundär replik.

I följande lista visas några skillnader med FCI:er på Windows Server jämfört med Linux:

• På Windows Server ingår en FCI i installationsprocessen. En FCI på Linux konfigureras efter installation av SQL Server.
• Linux stöder endast en enskild installation av SQL Server per värd, så alla FCI:er är en standardinstans. Windows Server stöder upp till 25 FCI:er per WSFC.
• Det gemensamma namn som används av FCI:er i Linux definieras i DNS och bör vara samma som resursen som skapats för FCI.

Loggöverföring

Om målen för återställningspunkter och återställningstider är mer flexibla, eller om databaser inte anses vara mycket verksamhetskritiska, är loggöverföring en annan beprövad tillgänglighetsfunktion i SQL Server. Baserat på SQL Server-inbyggda säkerhetskopior genererar processen för loggleverans automatiskt säkerhetskopior av transaktionsloggar, kopierar dem till en eller flera instanser som kallas för ett varmt vänteläge och tillämpar automatiskt säkerhetskopieringarna av transaktionsloggen på det vänteläget. Loggleverans använder SQL Server Agent-jobb för att automatisera processen för säkerhetskopiering, kopiering och tillämpning av säkerhetskopieringar av transaktionsloggar.

Förmodligen är den största fördelen med att använda loggöverföring i någon kapacitet att det tar hänsyn till mänskliga fel. Tillämpningen av transaktionsloggar kan fördröjas. Om någon utfärdar något som liknar en UPDATE utan en WHERE sats kanske vänteläget därför inte har ändringen så att du kan växla till den när du reparerar det primära systemet. Loggöverföring är lätt att konfigurera, men det är alltid manuellt att växla över från den primära servern till ett värmeberedskapsläge, vilket kallas för ett rollbyte. En rolländring initieras via Transact-SQL, och precis som med en tillgänglighetsgrupp måste alla objekt som inte har registrerats i transaktionsloggen synkroniseras manuellt. Loggöverföring måste också konfigureras per databas, medan en enskild tillgänglighetsgrupp (AG) kan innehålla flera databaser.

Till skillnad från en tillgänglighetsgrupp eller FCI har loggöverföring ingen mekanism för att hantera ett rollbyte, vilket applikationer måste kunna hantera. Tekniker som ett DNS-alias (CNAME) kan användas, men det finns för- och nackdelar, till exempel den tid det tar för DNS att förnyas efter bytet.

Haveriberedskap

När din primära tillgänglighetsplats drabbas av en katastrofal händelse som en jordbävning eller översvämning, måste företaget vara berett att få sina system online någon annanstans. Det här avsnittet beskriver hur SQL Server-tillgänglighetsfunktionerna kan hjälpa till med affärskontinuitet.

Tillgänglighetsgrupper

En av fördelarna med AG:er är att både hög tillgänglighet och haveriberedskap kan konfigureras med hjälp av en enda funktion. Utan kravet på att säkerställa att delad lagring också är mycket tillgänglig blir det mycket enklare att ha lokala repliker i ett datacenter för hög tillgänglighet, samt avlägsna repliker i andra datacenter för katastrofåterställning, var och en med separat lagring. Att ha extra kopior av databasen är kompromissen för att säkerställa redundans. Ett exempel på en tillgänglighetsgrupp som sträcker sig över flera datacenter visas i följande diagram. En primär replik ansvarar för att alla sekundära repliker synkroniseras.

Utanför en tillgänglighetsgrupp med klustertypen 'ingen' kräver det att tillgänglighetsgruppen att alla repliker ingår i samma underliggande kluster, oavsett om det är en WSFC eller en extern klusterlösning. Det innebär att WSFC i diagrammet ovan är utsträckt för att fungera i två olika datacenter, vilket ökar komplexiteten. oavsett plattform (Windows Server eller Linux). Att sträcka kluster över avstånd ökar komplexiteten.

En distribuerad tillgänglighetsgrupp introducerades i SQL Server 2016 (13.x) och gör att en tillgänglighetsgrupp kan omfatta AG:er som konfigurerats i olika kluster. Distribuerade AG:er frikopplar kravet på att alla noder ska delta i samma kluster, vilket gör det mycket enklare att konfigurera haveriberedskap. Mer information om distribuerade AG:er finns i Distribuerade tillgänglighetsgrupper.

Klusterinstanser för failover

FCI:er kan användas för katastrofåterställning. Precis som med en normal tillgänglighetsgrupp måste den underliggande klustermekanismen också utökas till alla platser, vilket ökar komplexiteten. Det finns ytterligare ett övervägande för FCI:er: den delade lagringen. Samma diskar måste vara tillgängliga på de primära och sekundära platserna. En extern metod, till exempel funktioner som tillhandahålls av lagringsleverantören på maskinvarulagret eller med lagringsreplik i Windows Server, krävs för att säkerställa att de diskar som används av FCI finns någon annanstans.

Loggöverföring

Loggleverans är en av de äldsta metoderna för att tillhandahålla haveriberedskap för SQL Server-databaser. Loggleverans används ofta med AG:er och FCI:er för att tillhandahålla kostnadseffektiv och enklare haveriberedskap där andra alternativ kan vara utmanande på grund av miljö, administrativa färdigheter eller budget. På samma sätt som med konceptet för hög tillgänglighet vid loggöverföring, fördröjer många miljöer inläsningen av en transaktionslogg för att ta hänsyn till mänskliga fel.

Migreringar och uppgraderingar

När du distribuerar nya instanser eller uppgraderar gamla kan ett företag inte tolerera långa avbrott. I det här avsnittet beskrivs hur tillgänglighetsfunktionerna i SQL Server kan användas för att minimera stilleståndstiden vid en planerad arkitekturändring, serverväxling, plattformsändring (till exempel Windows Server till Linux eller vice versa) eller under korrigeringar.

Tillgänglighetsgrupper

En befintlig instans som innehåller en eller flera AG:er kan uppgraderas till senare versioner av SQL Server. Även om detta kräver viss stilleståndstid, med rätt planeringsmängd, kan det minimeras.

Om målet är att migrera till nya servrar och inte ändra konfigurationen (inklusive operativsystemet eller SQL Server-versionen) kan dessa servrar läggas till som noder i det befintliga underliggande klustret och läggas till i tillgänglighetsgruppen. När repliken eller replikerna är i rätt tillstånd kan en manuell redundansväxling ske på en ny server, och sedan kan de gamla tas bort från tillgänglighetsgruppen och slutligen inaktiveras.

Distribuerade AG:er är också en annan metod för att migrera till en ny konfiguration eller uppgradera SQL Server. Eftersom en distribuerad tillgänglighetsgrupp stöder olika underliggande AG:er i olika arkitekturer kan du till exempel ändra från SQL Server 2016 (13.x) som körs på Windows Server 2012 R2 till SQL Server 2017 (14.x) som körs på Windows Server 2016.

Slutligen kan AG:er med klustertypen None också användas för migrering eller uppgradering. Du kan inte blanda och matcha klustertyper i en typisk tillgänglighetsgruppskonfiguration, så alla repliker måste vara av typen Ingen. En distribuerad tillgänglighetsgrupp (AG) kan användas för att omfatta AG:er som konfigurerats med olika klustertyper. Den här metoden stöds också på de olika operativsystemplattformarna.

Alla varianter av AG:er för migreringar och uppgraderingar gör att den mest tidskrävande delen av arbetet kan utföras över tid – datasynkronisering. När det är dags att initiera växlingen till den nya konfigurationen är snabbheten ett kort avbrott jämfört med en lång stilleståndstid där allt arbete, inklusive datasynkronisering, skulle behöva slutföras.

AG:er kan ge minimal stilleståndstid vid korrigering av det underliggande operativsystemet genom att manuellt växla över den primära till en sekundär replik medan korrigeringen slutförs. Från ett operativsystemsperspektiv skulle det vara vanligare att göra detta på Windows Server eftersom det ofta, men inte alltid, kan krävas en omstart för att underhålla det underliggande operativsystemet. Uppdatering av Linux kräver ibland en omstart, men det kan vara ovanligt.

Uppdatering av SQL Server-instanser som deltar i en tillgänglighetsgrupp kan också minimera driftstopp beroende på komplexiteten i AG-arkitekturen. För att uppdatera servrar som deltar i en tillgänglighetsgrupp (AG) uppdateras en sekundär replik först. När rätt antal repliker har korrigerats flyttas den primära repliken manuellt till en annan nod för att uppgraderingen ska kunna genomföras. Eventuella återstående sekundära repliker vid den tidpunkten kan också uppgraderas.

Klusterinstanser för failover

FCI:er på egen hand kan inte hjälpa till med en traditionell migrering eller uppgradering; en AG (tillgänglighetsgrupp) eller loggshipping (loggleverans) måste konfigureras för databaserna i FCI och alla andra objekt måste tas med i beräkningen. FCI:er under Windows Server är dock fortfarande ett populärt alternativ för när de underliggande Windows-servrarna måste korrigeras. En manuell redundansväxling kan initieras, vilket innebär ett kort avbrott i stället för att instansen inte är tillgänglig under hela den tid som Windows Server korrigeras. En FCI kan uppgraderas till senare versioner av SQL Server. Mer information finns i Uppgradera en redundansklusterinstans.

Loggöverföring

Loggleverans är fortfarande ett populärt alternativ för att både migrera och uppgradera databaser. Precis som med AG:er, men den här gången med transaktionsloggen som synkroniseringsmetod, kan dataspridningen startas i god tid före serverväxeln. Vid tidpunkten för övergången, efter att all trafik har stoppats vid källan, behöver en slutlig transaktionslogg tas, kopieras och tillämpas på den nya konfigurationen. Då kan databasen tas i drift. Loggleverans är ofta mer tolerant mot långsammare nätverk, och även om växeln kan vara något längre än en som görs med hjälp av en tillgänglighetsgrupp eller en distribuerad tillgänglighetsgrupp mäts den vanligtvis i minuter, inte timmar, dagar eller veckor.

I likhet med AG:er kan loggöverföring ge ett sätt att växla till en annan server vid patchning.

Andra SQL Server-distributionsmetoder och -tillgänglighet

Det finns två andra distributionsmetoder för SQL Server i Linux: containrar och användning av Azure (eller en annan offentlig molnleverantör). Det allmänna behovet av tillgänglighet som presenteras i det här dokumentet finns oavsett hur SQL Server distribueras. Dessa två metoder har vissa särskilda överväganden när det gäller att göra SQL Server mycket tillgängligt.

SQL Server-containrar och HA/DR-alternativ

Distribution av SQL Server-containrar är ett nytt sätt att distribuera SQL Server på Linux. En container är en fullständig avbildning av SQL Server som är redo att köras.

Beroende på vilken containerplattform du använder, till exempel när du använder en containerorkestrerare som Kubernetes, om containern förloras, kan den distribueras igen och kopplas till den delade lagring som användes. Även om detta ger viss återhämtning, finns det viss stilleståndstid som är associerad med databasåterställning och är inte riktigt högtillgänglig som det skulle vara om du använder en tillgänglighetsgrupp eller FCI.

Om du vill konfigurera hög tillgänglighet för SQL Server-containrar som distribueras på Kubernetes- eller icke-Kubernetes-plattformar kan du använda DH2i DxEnterprise som en av klustringslösningarna, där du kan konfigurera en tillgänglighetsgrupp i läget för hög tillgänglighet. Det här alternativet ger dig mål för återställningspunkt (RPO) och mål för återställningstid (RTO) som förväntas från en lösning med hög tillgänglighet.

Linux-baserad IaaS-distribution

Virtuella Linux IaaS-datorer kan distribueras med SQL Server installerat med Azure. Precis som med lokala installationer kräver en installation som stöds användning av stängsel av en misslyckad nod som är extern för själva klusteragenten. Nodstängsel tillhandahålls via fäktningstillgänglighetsagenter. Vissa distributioner skickar dem som en del av plattformen, medan andra förlitar sig på externa maskinvaru- och programvaruleverantörer. Kontrollera med din föredragna Linux-distribution för att se vilka former av nodstängsel som tillhandahålls så att en lösning som stöds kan distribueras i det offentliga molnet.

Guider för att installera SQL Server i Linux är tillgängliga för följande distributioner:

• Snabbstart: Installera SQL Server och skapa en databas på Red Hat
• Snabbstart: Installera SQL Server och skapa en databas på Ubuntu
• Snabbstart: Installera SQL Server och skapa en databas på SUSE Linux Enterprise Server

Lässkalning

Sekundära repliker kan användas för skrivskyddade frågor. Det finns två sätt att uppnå detta med en AG: genom att tillåta direkt åtkomst till den sekundära servern och konfigurera skrivskyddad ruttning, som kräver användning av lyssnaren. SQL Server 2016 (13.x) introducerade möjligheten att belastningsutjämning av skrivskyddade anslutningar via lyssnaren med hjälp av en resursallokeringsalgoritm, vilket gör att skrivskyddade begäranden kan spridas över alla läsbara repliker.

Skalning av läsbara kopior av en databas via AG:er introducerades först med distribuerade AG:er i SQL Server 2016 (13.x). Detta skulle göra det möjligt för företag att ha skrivskyddade kopior av databasen, inte bara lokalt, utan även regionalt och globalt med minimal konfiguration och minska nätverkstrafik och svarstid genom att köra frågor lokalt. Varje primär replik av en AG kan initiera två andra AG:er även om den inte är den fullständiga läs-/skrivkopian, så att varje distribuerad AG kan stödja upp till 27 läsbara kopior av data.

I SQL Server 2017 (14.x) och senare versioner kan du skapa en nästan realtidslösning med skrivskyddad lösning med AG:er som konfigurerats med klustertypen Ingen. Om målet är att använda AG:er för sekundära repliker som ska vara läsbara snarare än för tillgänglighet, eliminerar detta komplexiteten i att använda en WSFC eller en extern klusterlösning på Linux och ger fördelen av läsbarhet i en enklare implementeringsmetod.

Den enda större varningen är att på grund av att det inte finns något underliggande kluster med klustertypen None är det lite annorlunda att konfigurera skrivskyddad routning. Ur ett SQL Server-perspektiv krävs fortfarande en lyssnare för att dirigera begäranden även om det inte finns något kluster. I stället för att konfigurera en traditionell lyssnare används IP-adressen eller namnet på den primära repliken. Den primära repliken används sedan för att dirigera skrivskyddade begäranden.

En varm vänteläge för loggleverans kan tekniskt konfigureras för läsbar användning genom att återställa databasen WITH STANDBY. Men eftersom transaktionsloggarna kräver exklusiv användning av databasen för återställning innebär det att användarna inte kan komma åt databasen medan det sker. Detta gör loggöverföring till en mindre idealisk lösning – särskilt om det krävs data i nära realtid.

En sak som bör noteras för alla lässkalningsscenarier med AGs är att till skillnad från transaktionsreplikering, där alla data är aktuella, är varje sekundär replik inte i ett tillstånd där unika index kan användas; replikan är en exakt kopia av den primära repliken. Om det krävs index för rapportering eller om data behöver manipuleras måste de skapas på databaserna på den primära repliken. Om du behöver den flexibiliteten är replikering en bättre lösning för läsbara data.

Samverkan mellan plattformar och Linux-distribution

Med SQL Server som nu stöds på både Windows Server och Linux, beskriver det här avsnittet scenarier om hur de kan arbeta tillsammans för tillgänglighet utöver andra syften, och artikeln om lösningar som kommer att innehålla mer än en Linux-distribution.

Distribuerade tillgänglighetsgrupper

Distribuerade AG:er är utformade för att omfatta ag-konfigurationer, oavsett om de två underliggande klustren under AG:erna är två olika WSFCs, Linux-distributioner eller en på en WSFC och det andra på Linux. En distribuerad AG kommer att vara den primära metoden för att uppnå en plattformsoberoende lösning. En distribuerad tillgänglighetsgrupp är också den primära lösningen för migreringar, till exempel konvertering från en Windows Server-baserad SQL Server-infrastruktur till en Linux-baserad infrastruktur om det är vad företaget vill göra. Som nämnts ovan skulle AG:er, och särskilt distribuerade AG:er, minimera tiden då ett program inte skulle vara tillgängligt för användning. Ett exempel på en distribuerad tillgänglighetsgrupp som sträcker sig över en WSFC och Pacemaker visas i följande diagram:

Om en tillgänglighetsgrupp har konfigurerats med en klustertyp av Ingen kan den sträcka sig över Windows Server och Linux samt flera Linux-distributioner. Eftersom detta inte är en sann hög tillgänglighetskonfiguration bör den inte användas för verksamhetskritiska distributioner, utan snarare för scenarier som ökning av läsprestanda, migrering eller uppgradering.

Loggöverföring

Eftersom loggöverföring baseras på säkerhetskopiering och återställning och det inte finns några skillnader i databaser, filstrukturer osv., för SQL Server på Windows Server versus SQL Server på Linux. Det innebär att loggöverföring kan konfigureras mellan en Windows Server-baserad SQL Server-installation och en Linux-installation, samt mellan distributioner av Linux. Allt annat förblir detsamma. Det enda förbehållet är att loggöverföring, precis som en AG (tillgänglighetsgrupp), inte kan fungera när källan har en högre SQL Server-huvudversion jämfört med när målet har en lägre SQL Server-version.

Sammanfattning

Instanser och databaser i SQL Server 2017 (14.x) och senare versioner kan göras mycket tillgängliga med samma funktioner på både Windows Server och Linux. Förutom standardtillgänglighetsscenarier med lokal hög tillgänglighet och haveriberedskap kan stilleståndstid som är associerad med uppgraderingar och migreringar minimeras med tillgänglighetsfunktionerna i SQL Server. AG:er kan också tillhandahålla ytterligare kopior av en databas som en del av samma arkitektur för att skala ut läsbara kopior. Oavsett om du distribuerar en ny lösning eller överväger en uppgradering har SQL Server den tillgänglighet och tillförlitlighet du behöver.

Relaterat innehåll

• Vad är en AlwaysOn-tillgänglighetsgrupp?
• Installation av SQL Server-redundanskluster