SQL Server Alltid på-tillgänglighetsgrupper: Komplett guide [2026]

1. Förstå Always On-tillgänglighetsgrupper

1.1 Vad det är och hur det fungerar

Always On-tillgänglighetsgrupper (AG) är en SQL Server Företag hög tillgänglighet och katastrofåterställningslösning som fungerar på databasnivå. En tillgänglighetsgrupp grupperar en eller flera användardatabaser i en enda redundansenhet och replikerar dem till upp till åtta sekundära repliker genom kontinuerlig transaktionsloggleverans. När den primära repliken slutar fungera tar en utsedd synkron sekundär automatiskt över och återställer åtkomsten på några sekunder utan delad lagring eller manuella åtgärder.

1.2 Always On-tillgänglighetsgrupper kontra redundansklusterinstanser

SQL Server Always On inkluderar två distinkta tekniker: Tillgänglighetsgrupper (AG) och Failover-klusterinstanser (FCI):

	Alltid på tillgänglighetsgrupper	Always On Failover-klusterinstanser
Redundansövergångsomfång	Databasnivå	Instansnivå (alla databaser redundansväxlas samtidigt)
Datareplikering	Loggbaserad replikering till varje sekundär	Ingen — alla noder delar samma lagring
Delad lagring	Krävs inte	Krävs (Storage Area Network (SAN), iSCSI, S2D eller SMB)
Läsbara sekundärer	Ja	Nej
Katastrofåterställning	Inbyggt (asynkrona repliker över webbplatser)	Inte inbyggd utan parkoppling med AG

När man ska använda varje: Använd FCI när du behöver redundansväxling på instansnivå och redan har delad lagringsinfrastruktur. Använd AG när du behöver granularitet på databasnivå, läsbara sekundärer eller katastrofåterställning. För most komplett skydd, kombinera båda: kör varje replik som en FCI-nod och länka dem i en AG.

1.3 Fördelar och begränsningar

Fördelar:

• Automatisk redundansväxling med nästan noll återställningstidsmål (RTO) för synkrona repliker;
• noll dataförlust (Recovery Point Objective (RPO) = 0) i synkront commit-läge;
• ingen delad lagring krävs — varje replik använder oberoende lokal lagring;
• läsbara sekundärer avlastar rapportering och säkerhetskopieringsarbetsbelastningar från primären;
• stöder både lokal hög tillgänglighet (HA) och katastrofåterställning (DR) mellan olika platser inom en enda konfiguration.

Begränsningar:

• Kräver Windows Server Failover Clustering på alla repliker;
• Enterprise Edition för fullständiga funktioner (Standard Edition stöder Basic AG med betydande begränsningar);
• synkront commit-läge lägger till latens i skrivoperationer proportionellt mot nätverkets tur-retur-tid;
• inloggningar, SQL Agent-jobb och länkade servrar synkroniseras inte automatiskt i SQL Server 2019 och tidigare (löst i SQL Server 2022 innehöll tillgänglighetsgrupper).

2. Arkitektur för alltid påslagna tillgänglighetsgrupper

2.1 Kärnkomponenter och koncept

2.1.1 Tillgänglighetsdatabaser

Tillgänglighetsdatabaser är de användardatabaser som deltar i en tillgänglighetsgrupp. Dessa databaser måste uppfylla specifika krav: de måste använda den fullständiga återställningsmodellen, ha en fullständig säkerhetskopia och finnas på den primära repliken innan de läggs till i en tillgänglighetsgrupp.

När en databas ansluts till en tillgänglighetsgrupp blir den en del av en synkroniserad uppsättning som redundansväxlar som en enhet. Alla databaser i en tillgänglighetsgrupp delar samma redundansväxlingsstatus, vilket innebär att om den primära repliken misslyckas redundansväxlar alla databaser till samma sekundära replik samtidigt. Detta säkerställer konsekvens för applikationer som är beroende av flera relaterade databaser.

2.1.2 Tillgänglighetsrepliker

Tillgänglighetsrepliker är SQL Server fall som host kopior av tillgänglighetsdatabaser. Varje replik har sin egen fysiska kopia av databaserna, synkroniserad via leverans av transaktionsloggposter. En tillgänglighetsgrupp kan innehålla upp till nio repliker: en primär replik och upp till åtta sekundära repliker.

2.1.3 Primär replika

Den primära repliken hosts läs- och skrivkopian av tillgänglighetsdatabaserna. Alla dataändringar (INSERT, UPDATE, DELETE) sker på den primära repliken. Klientprogram ansluter till den primära repliken för alla skrivåtgärder och, som standard, även för läsåtgärder.

2.1.4 Sekundära repliker

Sekundära repliker host Skrivskyddade kopior av tillgänglighetsdatabaserna, som underhålls genom kontinuerlig tillämpning av transaktionsloggposter som tas emot från den primära repliken. Varje sekundär replik tar emot, härdar och tillämpar loggposter för att hålla sina databaskopior synkroniserade med den primära.

2.2 Tillgänglighetslägen

2.2.1 Synkront commit-läge

Synkront commit-läge ger noll skydd mot dataförlust genom att kräva att den primära repliken väntar på bekräftelse att transaktionsloggposter har härdats på den sekundära repliken innan transaktioner genomförs. Detta läge är viktigt för konfigurationer med hög tillgänglighet där dataförlust är oacceptabel.

2.2.2 Asynkront commit-läge

Asynkront commit-läge prioriterar prestandan för den primära repliken genom att tillåta transaktioner att committa utan att vänta på att sekundära repliker ska bekräfta logghärdning. Det här läget är lämpligt för repliker vid katastrofåterställning eller när nätverkslatens gör synkron commit opraktisk.

Avvägningen är potentiell dataförlust under redundansväxlingen. Om den primära repliken misslyckas kanske vissa bekräftade transaktioner inte har nått den sekundära repliken. Mängden potentiell dataförlust beror på nätverksbandbredd, den sekundära replikens prestanda och tidpunkten för felet. Organisationer måste acceptera denna risk när de använder asynkront läge.

2.3 Failover-typer

2.3.1 Automatisk redundansväxling

Automatisk redundansväxling gör det möjligt för tillgänglighetsgruppen att upptäcka fel på den primära repliken och automatiskt befordra en sekundär replik till primär utan administratörsintervention. Denna funktion minimerar RTO genom att eliminera behovet av manuell respons på fel.

Automatisk redundansväxling kräver synkront commit-läge för att säkerställa noll dataförlust. När tillgänglighetsgruppen är aktiverad övervakar den kontinuerligt den primära replikens tillstånd. Om den primära repliken slutar svara eller misslyckas initierar Windows Server Failover Cluster automatisk redundansväxling till en angiven sekundär replik.

2.3.2 Manuell redundansväxling

Manuell redundansväxling gör det möjligt för administratörer att avsiktligt byta den primära replikrollen till en sekundär replik, vanligtvis för planerat underhåll eller teständamål. Till skillnad från automatisk redundansväxling kräver manuell redundansväxling uttrycklig administratörsåtgärd för att initiera.

Manuell redundansväxling utan dataförlust är tillgänglig för synkrona commit-repliker. Administratören initierar redundansväxlingen genom SQL Server Management Studio, Transact-SQL eller PowerShell. Den primära repliken slutför bearbetningen av aktuella transaktioner och skickar alla återstående loggposter till tarbli sekundär och väntar på bekräftelse innan den primära rollen överförs.

Manuell redundansväxling kan också inträffa med asynkrona repliker, men detta kräver tvingad redundansväxling med potentiell dataförlust. Administratörer bör endast använda tvingad manuell redundansväxling under faktiska katastrofscenarier när den primära repliken inte är tillgänglig och dataförlust är acceptabel jämfört med förlängd driftstopp.

2.3.3 Tvingad redundansväxling

Tvingad redundansväxling möjliggör redundansväxling till en asynkron sekundär replik eller till en sekundär replik som inte är helt synkroniserad, med uttrycklig medgivande om potentiell dataförlust. Detta alternativ fungerar som en sista utväg när den primära repliken inte är tillgänglig och ingen synkroniserad sekundär replik finns.

2.4 Datasynkronisering

2.4.1 Hur datasynkronisering fungerar

Datasynkronisering i Always On Availability Groups sker genom kontinuerlig leverans av transaktionsloggposter från den primära repliken till alla sekundära repliker. Denna loggbaserade synkronisering säkerställer konsekvens samtidigt som den tillåter oberoende lagring för varje replik.

2.4.2 Transaktionsloggposter och härdning

Transaktionsloggshärdning är det kritiska steget där loggposter skrivs till varaktig lagring på sekundära repliker. Härdning säkerställer att loggposter överlever sekundära replikfel och kan spelas upp under återställning.

2.5 Lässkaliga och läsbara sekundära repliker

2.5.1 Avlastning av skrivskyddade arbetsbelastningar

Läsbara sekundära repliker gör det möjligt för organisationer att avlasta läsintensiva arbetsbelastningar från den primära repliken, vilket förbättrar den totala systemets prestanda och resursutnyttjande. Denna lässkaliga funktion är en av de viktigaste fördelarna med tillgänglighetsgrupper jämfört med äldre lösningar med hög tillgänglighet.

Organisationer bör beakta krav på skrivskyddad arbetsbelastning när de utformar konfigurationer för tillgänglighetsgrupper. Flera läsbara sekundärservrar kan fördela rapporteringsbelastningen över flera servrar. Skrivskyddade routningslistor definierar i vilken ordning sekundärservrar tar emot läsintent-anslutningar, vilket möjliggör strategier för lastbalansering.

2.5.2 Säkerhetskopieringsåtgärder på sekundära repliker

Att köra säkerhetskopior på sekundära repliker minskar belastningen på input/output (I/O) och centralprocessorn (CPU) på den primära repliken, vilket gör att den kan fokusera på transaktionella arbetsbelastningar. Denna funktion hjälper organisationer att uppfylla säkerhetskopieringskrav utan att påverka produktionsprestanda.

SQL Server stöder fullständiga säkerhetskopior av databaser, differentiella säkerhetskopior och säkerhetskopior av transaktionsloggar på sekundära repliker. Säkerhetskopieringsinställningar kan konfigureras för att prioritera sekundära repliker, primära repliker, endast sekundära repliker eller valfri replik. Säkerhetskopieringssystemet väljer automatiskt en lämplig replik baserat på dessa inställningar och aktuell tillgänglighet.

För mer information om SQL Server säkerhetskopiering, se vår omfattande guide.

2.6 Lyssnare för tillgänglighetsgruppen

2.6.1 Vad är en lyssnare?

En lyssnare för tillgänglighetsgrupper är ett virtuellt nätverksnamn (VNN) och en IP-adress som klientprogram använder för att ansluta till tillgänglighetsgruppernas databaser. Lyssnaren omdirigerar automatiskt anslutningar till den aktuella primära repliken, vilket eliminerar behovet för program att spåra vilken server som för närvarande är primär.

2.6.2 Klientanslutningsroutning

Klientanslutningsroutning genom lyssnaren stöder både läs- och skrivskyddade anslutningsavsikter. Lyssnaren undersöker anslutningsbegäran och dirigerar den till lämplig replik baserat på programmets avsikt.

3. Förkunskapskrav och krav

3.1 Windows Server-redundanskluster för tillgänglighetsgrupper

3.1.1 Grunderna i Windows Server-failover-kluster

Windows Server Failover Clustering (WSFC) utgör grunden för Always On Availability Groups genom att hantera klustermedlemskap, hälsoövervakning och redundansorkestrering. Till skillnad från redundansklusterinstanser använder tillgänglighetsgrupper WSFC endast för klusterkoordinering, inte för hantering av delad lagring.

Varje SQL Server Instansen som deltar i en tillgänglighetsgrupp måste vara en nod i ett WSFC-kluster. Klustret hanterar kvorumröstning, nodhälsoidentifiering och tillgänglighetsgruppens resurstillstånd. När den primära repliken misslyckas koordinerar WSFC redundansväxlingsprocessen och uppdaterar klusterresurser för att återspegla den nya primära repliken.

3.1.2 Konfiguration av klusterkvorum

Klusterkvorum avgör vilka noder som kan fungera när problem med nätverksanslutningen uppstår, vilket förhindrar split-brain-scenarier där flera noder oberoende av varandra hävdar att de är primära. Kvorumkonfigurationen definierar vad som utgör en majoritetsröstning för klusterbeslut.

Flera kvorumlägen är tillgängliga för tillgänglighetsgrupper:

• Nodmajoritet använder endast klusternodröster och fungerar bra för kluster med ett udda antal noder.
• Nod- och fildelningsmajoritet lägger till en omröstning för fildelningsvittnen, lämplig för nodkluster med jämna nummer.
• Node- och diskmajoritet använder ett diskvittne men är mindre vanligt för tillgänglighetsgrupper eftersom delad lagring inte krävs.

3.1.3 Kluster med flera delnät

Kluster med flera undernät gör det möjligt för repliker av tillgänglighetsgrupper att spänna över olika nätverksundernät, vilket stöder geografiskt distribuerade distributioner över datacenter. Denna funktion är avgörande för konfigurationer för katastrofåterställning där repliker finns på separata platser.

3.2 SQL Server Utgåvakrav

3.2.1 Funktioner i Enterprise Edition

SQL Server Enterprise Edition erbjuder fullständig funktionalitet för tillgänglighetsgrupper utan begränsningar. Enterprise Edition stöder upp till åtta sekundära repliker, läsbara sekundärer, automatisk seedning, distribuerade tillgänglighetsgrupper och alla avancerade funktioner.

3.2.2 Funktioner i standardutgåvan (grundläggande tillgänglighetsgrupper)

SQL Server Standardutgåvan från 2016 och senare stöder grundläggande tillgänglighetsgrupper med betydande begränsningar. Grundläggande tillgänglighetsgrupper ger hög tillgänglighetsfunktionalitet till lägre kostnad.ost, lämplig för organisationer med enklare krav.

4. Konfigurera Always On-tillgänglighetsgrupper

4.1 Förbereda miljön

Innan en tillgänglighetsgrupp skapas måste miljön förberedas ordentligt med Active Directory-konton, serverkonfigurationer och nätverksinfrastruktur på plats.

4.1.1 Konfiguration av domänkontrollant

Active Directory-domänkontrollanten måste konfigureras för att stödja tillgänglighetsgruppklustret och SQL Server servicekonton.

1. Logga in på domänkontrollanten med domänadministratörsuppgifter.
2. Öppet server manager och navigera till Verktyg -> Active Directory-användare och datorer.
3. Skapa en organisatorisk enhet för SQL Server objekt om ett sådant inte existerar.
4. Kontrollera att datorobjekt för alla klusternoder finns i Active Directory.
5. Se till att DNS-tjänsterna (Domain Name System) är korrekt konfigurerade och att alla servernamn matchas korrekt.

4.1.2 Skapa servicekonton

Skapa dedikerade Active Directory-tjänstkonton för SQL Server tjänster på varje nod.

1. Öppet Active Directory-användare och datorer på domänkontrollanten.
2. Högerklicka på lämplig organisationsenhet och välj Nytt -> Användare.
3. Ange tjänstkontots namn (till exempel svc_SQLServer) och ange Användarinloggningsnamn.
4. Klicka Nästa och ange ett starkt lösenord.
5. Välja Användaren kan inte ändra lösenord och Lösenordet upphör aldrig att gälla.
6. Klicka Nästa och då Finish för att skapa kontot.
7. Upprepa för eventuella ytterligare servicekonton som behövs (SQL Server Agent, SSRS, etc.).

4.1.3 Konfigurera administratörsbehörigheter

Tjänstkonton och de konton som används för att konfigurera SQL Server måste ha lämpliga behörigheter på alla klusternoder.

1. Logga in på varje klusternodserver.
2. Öppet Datorhantering från Start menyn eller Serverhanteraren.
3. Bygga ut Lokala användare och grupper och välj Grupper.
4. Högerklicka Administratörer och välj Våra Bostäder.
5. Klicka Lägg till och ange servicekontots namn.
6. Klicka Kontrollera namn för att validera kontot, klicka sedan på OK.
7. Klicka OK för att stänga dialogrutan Administratörsegenskaper.
8. Upprepa på alla klusternoder.

4.2 Installera och konfigurera WSFC

Windows Server Failover Clustering måste installeras och konfigureras på alla noder innan Always On Availability Groups aktiveras.

4.2.1 Installera funktionen för redundanskluster

Installera funktionen för redundanskluster på varje server som ska delta i tillgänglighetsgruppen.

1. Öppet server manager på den första klusternoden.
2. Klicka hantera -> Lägg till roller och funktioner.
3. Klicka Nästa genom introduktionsskärmarna.
4. Välja Rollbaserad eller funktionsbaserad installation och klicka Nästa.
5. Välj den lokala servern och klicka på Nästa.
6. Hoppa över skärmen Roller och klicka på Nästa.
7. På skärmen Funktioner väljer du Failover-kluster.
8. Klicka Lägg till funktioner när de uppmanas att inkludera hanteringsverktyg.
9. Klicka Nästa och då installera.
10. Vänta tills installationen är klar och klicka på Stäng.
11. Upprepa på alla servrar som ska delta i klustret.

4.2.2 Skapa redundansklustret

När du har installerat funktionen för redundanskluster på alla noder skapar du klustret från en nod.

1. Öppet Failover Cluster Manager från server manager -> Verktyg.
2. Klicka Skapa kluster i åtgärdspanelen.
3. Klicka Nästa på sidan Innan du börjar.
4. Klicka Bläddra och lägg till alla servrar som kommer att vara klusternoder.
5. Klicka Nästa efter att alla noder har lagts till.
6. Lämna Kör alla tester (rekommenderas) valt och klicka Nästa.
7. Granska resultaten av valideringstestet och åtgärda eventuella fel eller varningar.
8. Klicka Finish efter att valideringen har slutförts.
9. Ange ett namn för klustret och en IP-adress.
10. Avmarkera Lägg till all kvalificerad lagring i klustret eftersom delad lagring inte krävs.
11. Klicka Nästa och granska bekräftelsen.
12. Klicka Finish för att skapa klustret.

4.2.3 Validera klusterkonfigurationen

Validera klusterkonfigurationen för att säkerställa att alla noder kan kommunicera korrekt och att klustret fungerar korrekt.

1. In Failover Cluster Manager, högerklicka på klusternamnet.
2. Välja Validera kluster från menyn.
3. Klicka Nästa på sidan Innan du börjar.
4. Välja Kör alla tester (rekommenderas) och klicka Nästa.
5. Klicka Nästa för att påbörja valideringstester.
6. Granska valideringsrapporten när testerna är klara.
7. Åtgärda eventuella fel eller varningar som identifierats i rapporten.
8. Klicka Finish för att stänga guiden.

4.3 Installation SQL Server för tillgänglighetsgrupper

installera SQL Server på varje nod som ska delta i tillgänglighetsgruppen med hjälp av alternativet för fristående installation.

1. Kör SQL Server installationsmedia på den första noden.
2. Välja Nytt SQL Server fristående installation.
3. Ange produktnyckeln eller välj utvärderingsversionen.
4. Acceptera licensvillkoren och klicka Nästa.
5. Slutför förkunskapskontroller och åtgärda eventuella problem.
6. På sidan Funktionsval väljer du Databasmotortjänster.
7. Konfigurera instansnamn (använd samma instansnamn på alla noder).
8. På sidan Serverkonfiguration anger du inloggningsuppgifterna för tjänstkontot.
9. Konfigurera tjänstertartuptyper som Automat.
10. På sidan Konfiguration av databasmotorn väljer du autentiseringsläge.
11. Lägg till administratörskonton.
12. Konfigurera datakataloger med konsekventa sökvägar över alla noder.
13. Slutför installationen och verifiera att den lyckades.
14. Upprepa installationen på alla andra klusternoder med identiska inställningar.

4.4 Aktivera funktionen för alltid påslagna tillgänglighetsgrupper

När du har installerat SQL Server Aktivera funktionen Always On Availability Groups på alla noder för varje instans.

4.4.1 Aktivering via SQL Server Konfigurationshanteraren

Använda SQL Server Konfigurationshanteraren för att aktivera Always On-tillgänglighetsgrupper via det grafiska gränssnittet.

1. Öppet SQL Server Konfigurationshanteraren på den första noden.
2. Bygga ut SQL Server Tjänster i den vänstra rutan.
3. Högerklicka på SQL Server exempel och välj Våra Bostäder.
4. Klicka på AlwaysOn hög tillgänglighet fliken.
5. Kolla upp Aktivera AlwaysOn-tillgänglighetsgrupper.
6. Kontrollera att namnet på Windows-failover-klustret är korrekt.
7. Klicka OK för att spara ändringarna.
8. Klicka OK på varningen att tjänsten måste återställastarted.
9. Högerklicka på SQL Server service och välj Restart.
10. Vänta tills tjänsten återställstarframgångsrikt.
11. Upprepa på alla klusternoder.

4.4.2 Aktivera via PowerShell

PowerShell tillhandahåller en skriptad metod för att aktivera Always On-tillgänglighetsgrupper över flera noder.

1. Öppna PowerShell som administratör på den första noden.
2. Importera SQL Server PowerShell-modul:

   Import-Module SQLPS -DisableNameChecking

3. Aktivera alltid-på-tillgänglighetsgrupper:

   Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force

4. Tjänsten återställs automatiskttart när du använder Force-parametern.
5. Kontrollera att funktionen är aktiverad:

   Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled

6. Upprepa för varje klusternod och ersätt med lämpliga server- och instansnamn.

4.4.3 Verifiera att funktionen är aktiverad

Kontrollera att Always On Availability Groups är aktiverat på alla instanser innan du fortsätter med konfigurationen.

1. Anslut till varje SQL Server exempel med hjälp av SQL Server ManagementStudio.
2. Öppna ett nytt frågefönster och kör:

   SELECT SERVERPROPERTY('IsHadrEnabled')

3. Verifiera att resultatet är 1 (aktiverat).
4. Kontrollera att SQL Server instansen visas i Failover Cluster Manager under klusterroller.
5. Verifiera att tillgänglighetsgruppens slutpunkt finns genom att köra:

   SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'

6. Om slutpunkten inte finns skapas den när tillgänglighetsgruppen skapas.

4.5 Förbereda databaser för tillgänglighetsgrupper

Databaser måste uppfylla specifika krav innan de kan läggas till i en tillgänglighetsgrupp.

4.5.1 Krav för databasåterställningsmodell

Ändra databasens återställningsmodell till FULL på den primära repliken innan du lägger till den i en tillgänglighetsgrupp.

1. Anslut till den primära repliken med hjälp av SQL Server ManagementStudio.
2. Högerklicka på databasen och välj Våra Bostäder.
3. Välj Montering sida.
4. Ändra Återhämtningsmodell till full.
5. Klicka OK för att rädda förändringen.
6. Alternativt kan du använda Transact-SQL:

   ALTER DATABASE DatabaseName SET RECOVERY FULL;

4.5.2 Ta fullständiga säkerhetskopior av databasen

Ta en fullständig säkerhetskopia av databasen för att upprätta den säkerhetskopieringskedja som krävs för tillgänglighetsgrupper.

1. In SQL Server Management Studio, högerklicka på databasen.
2. Välja Uppgifter -> BACKA UPP.
3. Verifiera Säkerhetskopieringstyp är inställd på full.
4. Välj en säkerhetskopia eller lägg till en ny destination.
5. Klicka OK för att utföra säkerhetskopieringen.
6. Alternativt kan du använda Transact-SQL:

   BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

4.5.3 Säkerhetskopiera transaktionsloggar

Säkerhetskopiera transaktionsloggen för att säkerställa att loggkedjan är upprättad och minimera initialiseringstiden.

1. In SQL Server Management Studio, högerklicka på databasen.
2. Välja Uppgifter -> BACKA UPP.
3. Ändra Säkerhetskopieringstyp till Transaktionslogg.
4. Välj en säkerhetskopia.
5. Klicka OK för att utföra säkerhetskopieringen.
6. Alternativt kan du använda Transact-SQL:

   BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

4.6 Skapa tillgänglighetsgruppen

Skapa tillgänglighetsgruppen med hjälp av en av flera tillgängliga metoder beroende på dina preferenser och automatiseringskrav.

4.6.1 Använda guiden Ny tillgänglighetsgrupp

Guiden Ny tillgänglighetsgrupp tillhandahåller ett grafiskt gränssnitt för att skapa tillgänglighetsgrupper.

1. In SQL Server Management Studio, anslut till instansen som ska host den primära repliken.
2. Bygga ut AlwaysOn hög tillgänglighet i Objektutforskaren.
3. Högerklicka Tillgänglighetsgrupper och välj Ny guide för tillgänglighetsgrupp.
   
4. Klicka Nästa på introduktionssidan.
5. Ange ett namn för tillgänglighetsgruppen och klicka på Nästa.
6. På sidan Välj databaser väljer du de databaser som ska inkluderas.
7. Kontrollera att databaserna uppfyller alla krav och klicka på Nästa.
8. På sidan Ange repliker klickar du på Lägg till replika.
9. Anslut till varje sekundär replikinstans.
10. Konfigurera replikegenskaper för varje instans (tillgänglighetsläge, redundansläge).
11. Klicka på endpoints fliken och granska slutpunktskonfigurationen.
12. Klicka på Säkerhetskopieringsinställningar fliken och konfigurera prioriteringar för säkerhetskopiering.
13. Klicka på Lyssnare fliken och valfritt skapa en lyssnare.
14. Klicka Nästa och välj datasynkroniseringsmetod.
15. Granska valideringsresultaten och åtgärda eventuella problem.
16. Klicka Nästa och granska sammanfattningen.
17. Klicka Finish för att skapa tillgänglighetsgruppen.
18. Övervaka framstegen och verifiera att skapandet lyckades.

4.6.2 Använda Transact-SQL

Skapa tillgänglighetsgrupper med Transact-SQL för skriptbara, repeterbara distributioner.

1. Skapa tillgänglighetsgruppen på den primära repliken:

   CREATE AVAILABILITY GROUP AG_Name
   FOR DATABASE DatabaseName
   REPLICA ON
     'PrimaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
     'SecondaryServer\Instance' WITH
       (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
        AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
        FAILOVER_MODE = AUTOMATIC,
        SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));

2. Gå med i den sekundära repliken i tillgänglighetsgruppen:

   ALTER AVAILABILITY GROUP AG_Name JOIN;

3. Gå med i den sekundära databasen:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 Använda PowerShell

PowerShell tillhandahåller skriptfunktioner för att skapa och hantera tillgänglighetsgrupper.

1. Skapa tillgänglighetsgruppobjektet:

   $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"

2. Lägg till databaser:

   Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"

3. Konfigurera repliker med önskade egenskaper med hjälp av cmdlet:en New-SqlAvailabilityReplica.
4. Koppla sekundära repliker med hjälp av cmdlet:en Join-SqlAvailabilityGroup.

4.7 Lägga till repliker i tillgänglighetsgruppen

Konfigurera replikspecifika egenskaper som styr hur varje instans deltar i tillgänglighetsgruppen.

4.7.1 Konfigurera replikegenskaper

Ange egenskaper för varje replik för att definiera dess roll och funktioner inom tillgänglighetsgruppen.

1. In SQL Server Management Studio, expandera AlwaysOn hög tillgänglighet -> Tillgänglighetsgrupper.
2. Expandera tillgänglighetsgruppen och expandera sedan Tillgänglighetsreplikor.
   
3. Högerklicka på en replik och välj Våra Bostäder.
4. Granska och ändra anslutningsinställningarna för den primära och sekundära rollen.
5. Konfigurera timeout-värden för sessionen om det behövs.
6. Klicka OK för att spara ändringar.

4.7.2 Ställa in tillgänglighetslägen

Konfigurera tillgänglighetsläge för att styra synkroniseringsbeteendet mellan repliker.

1. Högerklicka på tillgänglighetsgruppen och välj Våra Bostäder.
2. I Allmänt sida, gå till Tillgänglighetsreplikor sektion.
3. För varje replik, välj Synkron commit or Asynkron commit från rullgardinsmenyn.
4. Använd synkron commit för lokala repliker med hög tillgänglighet.
5. Använd asynkron commit för geografiskt avlägsna repliker efter katastrofåterställning.
6. Klicka OK för att spara konfigurationen.

4.7.3 Ställa in redundanslägen

Konfigurera redundansväxlingsläge för att styra hur redundansväxlingen sker för varje replik.

1. Högerklicka på tillgänglighetsgruppen och välj Våra Bostäder.
2. I Allmänt sida, gå till Tillgänglighetsreplikor sektion.
3. För synkrona commit-repliker, välj Automat or Manuell redundansläge.
4. Automatisk redundansväxling kräver synkront commit-läge och aktiverar obevakad redundansväxling.
5. För asynkrona commit-repliker är endast manuell redundansväxling tillgänglig.
6. Konfigurera upp till tre repliker för automatisk redundansväxling (en primär och två sekundära).
7. Klicka OK för att tillämpa inställningarna.

4.7.4 Konfigurera säkerhetskopieringsinställningar

Ställ in säkerhetskopieringsinställningar för att styra var säkerhetskopiering ska ske.

1. Högerklicka på tillgänglighetsgruppen och välj Våra Bostäder.
2. Välja Säkerhetskopieringsinställningar i den vänstra rutan.
3. Välj en av säkerhetskopieringsinställningarna:
   • Föredrar sekundärtSäkerhetskopior på sekundär om tillgänglig, annars primär
   • Endast sekundärtSäkerhetskopiering endast på sekundära repliker
   • PrimäraSäkerhetskopiering endast på primär replik
   • Vilken replik som helstSäkerhetskopieringar på alla tillgängliga repliker
4. Ange prioritetsvärden för säkerhetskopiering för varje replik (0–100).
5. Högre prioritetsvärden anger önskvärd säkerhetskopiering tarblir.
6. Klicka OK för att spara inställningarna.

4.8 Konfigurera lyssnaren för tillgänglighetsgruppen

Skapa en lyssnare för att tillhandahålla en enda anslutningspunkt som automatiskt omdirigerar till den aktuella primära repliken.

4.8.1 Skapa lyssnaren

Lägg till en lyssnare i tillgänglighetsgruppen för hantering av klientanslutningar.

1. In SQL Server Management Studio, utöka tillgänglighetsgruppen.
2. Högerklicka Lyssnare för tillgänglighetsgruppen och välj Lägg till lyssnare.
   
3. Ange ett DNS-namn för lyssnaren (till exempel AG_Listener).
4. Ange portnumret (standard är 1433).
5. Välja Statisk IP för nätverksläget.
6. Klicka Lägg till för att lägga till en IP-adress för varje delnät.
7. Ange IP-adressen och välj subnätet.
8. Klicka OK att skapa lyssnaren.
9. Verifiera att lyssnaren visas i Object Explorer och är online.

4.8.2 Konfigurera DNS- och IP-inställningar

Verifiera DNS-registrering och nätverkskonfiguration för lyssnaren.

1. Öppna DNS-hanteraren på domänkontrollanten.
2. Kontrollera att lyssnarnamnet har registrerats med alla IP-adresser.
3. Testa DNS-upplösning från klientdatorer:

   nslookup ListenerName

4. Kontrollera att alla konfigurerade IP-adresser returneras.
5. I Failover Cluster Manager, expandera roller och välj tillgänglighetsgruppen.
6. Kontrollera att IP-adressresurserna är online.
7. Kontrollera att nätverksnamnsresursen är online.
   

4.8.3 Testa lyssnaranslutning

Kontrollera att klientprogram kan ansluta via lyssnaren.

1. Från en klientdator, öppna SQL Server ManagementStudio.
2. Anslut med lyssnarnamnet istället för ett servernamn.
3. Kör en fråga för att verifiera anslutningen till den aktuella primära repliken:

   SELECT @@SERVERNAME;

4. Testa routning för läsintention genom att lägga till ApplicationIntent=ReadOnly i anslutningssträngen.
5. Verifiera omdirigeringar av anslutningar till en läsbar sekundär replik.
6. Testa redundansväxlingen genom att manuellt redundansväxla tillgänglighetsgruppen och verifiera återanslutningen.

4.9 Metoder för datasynkronisering

Välj en datasynkroniseringsmetod för att initiera sekundära repliker med databaskopior.

4.9.1 Automatisk sådd

Automatisk seeding överför databasdata över nätverket utan att manuella säkerhetskopieringar och återställningar krävs.

1. När du skapar en tillgänglighetsgrupp, välj Automatisk sådd som synkroniseringsmetod.
   
2. Säkerställ nätverksanslutning och tillräcklig bandbredd mellan repliker.
3. Den primära repliken strömmar automatiskt databasdata till sekundära repliker.
4. Övervaka seeding-förloppet med hjälp av tillgänglighetsgruppens instrumentpanel eller DMV:er.
5. Automatisk sådd kräver SQL Server 2016 eller senare.
6. För stora databaser, beakta nätverkspåverkan och schemalägg under perioder med låg användning.

4.9.2 Manuell seeding (säkerhetskopiering och återställning)

Manuell sådd innebär att säkerhetskopior tas på den primära och återställs på sekundära repliker.

1. Gör en fullständig säkerhetskopia på den primära repliken:

   BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';

2. Ta en säkerhetskopia av transaktionsloggen:

   BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';

3. Återställ den fullständiga säkerhetskopian på varje sekundär replik:

   RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;

4. Återställ säkerhetskopian av loggfilen:

   RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;

5. Gå med i databasen i tillgänglighetsgruppen:

   ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

6. Verifiera att synkroniseringen börjar och att databasen når tillståndet SYNKRONISERAD.

4.9.3 Databas-snapshotfiler

Använd databas-snapshot-filer för att initiera sekundära repliker från befintliga databasfiler.

1. Koppla bort eller säkerhetskopiera databasen på den primära repliken.
2. Kopiera databasfiler till varje sekundär replik med samma sökvägar.
3. På sekundära repliker, koppla databasen eller återställ utan återställning.
4. Se till att databasen är i tillståndet ÅTERSTÄLLER.
5. Gå med i databasen i tillgänglighetsgruppen.
6. Den här metoden är användbar för mycket stora databaser där nätverksöverföring skulle vara opraktisk.

5. FAQ

5.1 Allmänna frågor

F: Vad är skillnaden mellan Always On FCI och Always On AG?

A: Always On Failover-klusterinstanser ger hög tillgänglighet på instansnivå med delad lagring, medan Always On Availability Groups ger hög tillgänglighet på databasnivå utan delad lagring. AG erbjuder läsbara sekundärer och mer flexibel geografisk distribution.

F: Kan jag använda Always On-tillgänglighetsgrupper med SQL Server Standardutgåva?

A: Ja, SQL Server 2016 Standard Edition och senare stöder grundläggande tillgänglighetsgrupper med begränsningar inklusive en databas per AG, maximalt två repliker och inget läsbart sekundärt stöd.

F: Behöver jag delad lagring för Always On-tillgänglighetsgrupper?

A: Nej, tillgänglighetsgrupper kräver inte delad lagring. Varje replik hanterar oberoende kopior av databaser på lokal lagring, synkroniserade via leverans av transaktionsloggar.

F: Vad är det maximala antalet repliker i en tillgänglighetsgrupp?

A: SQL Server Enterprise Edition stöder upp till nio repliker (en primär och åtta sekundära). Distribuerade tillgänglighetsgrupper kan stödja upp till 18 repliker totalt över två tillgänglighetsgrupper.

5.2 Konfigurationsfrågor

F: Hur väljer jag mellan synkrona och asynkrona commit-lägen?

A: Använd synkron commit för att undvika dataförlust inom samma datacenter eller nätverk med låg latens. Använd asynkron commit för fjärrrepliker efter katastrofåterställning där synkron commit skulle påverka prestandan.

F: Kan jag blanda synkrona och asynkrona repliker i samma tillgänglighetsgrupp?

A: Ja, tillgänglighetsgrupper stöder blandade konfigurationer med både synkrona och asynkrona repliker. Detta möjliggör lokal hög tillgänglighet med synkrona repliker och fjärråterställning efter haveri med asynkrona repliker.

F: Vad händer med mina anslutningar under redundansväxlingen?

A: Befintliga anslutningar bryts vid redundansväxling. Program med logik för återförsök av anslutningar återansluter automatiskt till den nya primära anslutningen via lyssnaren. Redundansväxlingsprocessen slutförs vanligtvis inom sekunder till minuter.

F: Behöver jag synkronisera inloggningar och jobb mellan repliker?

A: I SQL Server 2019 och tidigare, ja – inloggningar, SQL Agent-jobb och länkade servrar måste synkroniseras manuellt. SQL Server 2022 introducerar inneslutna tillgänglighetsgrupper som automatiskt inkluderar dessa objekt.

5.3 Ledningsfrågor

F: Kan jag köra säkerhetskopior på sekundära repliker?

A: Ja, sekundära repliker stöder fullständiga, differentiella och transaktionsloggssäkerhetskopior. Konfigurera säkerhetskopieringsinställningar för att avlasta säkerhetskopior från den primära repliken och minska dess resursanvändning.

F: Hur patchar jag SQL Server med minimal driftstopp?

A: Använd löpande uppgraderingar genom att först uppdatera sekundära repliker, sedan utföra en manuell redundansväxling till en uppdaterad sekundär och slutligen uppdatera den tidigare primära enheten. Detta minimerar driftstopp under redundansväxlingens varaktighet.

F: Kan jag lägga till databaser i en befintlig tillgänglighetsgrupp?

A: Ja, databaser kan läggas till i aktiva tillgänglighetsgrupper. Databasen måste vara i fullständig återställningsmodell med en fullständig säkerhetskopia, och sekundära repliker måste seedas med automatisk seeding eller manuell säkerhetskopiering och återställning.

F: Vad är automatisk sådd och bör jag använda det?

A: Automatisk seeding överför databasdata över nätverket för att initiera sekundära repliker utan manuella säkerhetskopior. Använd det för mindre databaser eller när nätverksbandbredden är tillräcklig. För mycket stora databaser kan manuell seeding vara snabbare.

F: Var ska jag köra DBCC CHECKDB i en tillgänglighetsgrupp?

A: Du bör köra DBCC CHECKDB på sekundära repliker för att minska belastningen på den primära repliken. Databaskonsekvenskontroller kan köras mot sekundära databaser utan att påverka den primära replikens prestanda.

För mer information om DBCC CHECKDB, se vår omfattande guide.

5.4 Felsökningsfrågor

F: Varför är min databas i tillståndet INTE SYNKRONISERAR?

A: Vanliga orsaker inkluderar problem med nätverksanslutningen, pausad dataförflyttning, otillräckligt diskutrymme på sekundära repliker eller problem med slutpunkten. Kontrollera beskrivningen av synkroniseringshälsan och SQL Server felloggar för specifika detaljer. Om den sekundära databasen har angett en återställningsläge eller visar återkrav väntar, se de länkade guiderna för tarfick korrigeringar.

F: Hur tvingar jag fram redundansväxling när den primära enheten inte är tillgänglig?

A: Anslut till en sekundär replik och kör ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. Detta bekräftar potentiell dataförlust och flyttar den sekundära till primära omedelbart.

F: Varför kan inte klienter ansluta till min lyssnare?

A: Kontrollera att lyssnaren är online i Failover Cluster Manager, att DNS-registreringen har lyckats, att alla lyssnar-IP-adresser är nåbara från klienter och att brandväggsregler tillåter trafik till lyssnarporten.

F: Vad betyder en lång redo-kö?

A: En lång redo-kö indikerar att den sekundära repliken inte kan tillämpa loggposter lika snabbt som de anländer. Detta kan tyda på flaskhalsar för disk-I/O, CPU-begränsningar eller blockering från skrivskyddade frågor på den sekundära repliken.

F: Vad ska jag göra om en katastrof påverkar alla repliker och mina säkerhetskopior också är skadade?

A: Detta värsta tänkbara scenario, även om det är extremt rart.ex. kan uppstå på grund av ransomware-attacker, utbredda lagringsfel eller kaskadkatastrofer. Ditt primära försvar är förebyggande: underhåll geografiskt distribuerade repliker, lagra säkerhetskopior på separata platser och
Testa regelbundet dina katastrofåterställningsprocedurer. Om alla standardåterställningsalternativ misslyckas, kontakta en specialiserad SQL-dataåterställningsverktyg kan försöka extrahera data från skadade MDF-filer som en sista utväg.

5.5 Licensiering och Cost Frågor

F: Hur licensieras Always On Availability Groups?

A: SQL Server Licensiering beror på utgåva och distributionsmodell. Tillgänglighetsgrupper för Enterprise Edition kräver Enterprise-licenser för alla repliker. Passiva sekundära repliker kan kvalificera sig för gratis licensiering under vissa villkor.

F: Kan jag använda SQL Server Utvecklarutgåvan för tillgänglighetsgrupper?

A: Ja, Developer Edition inkluderar alla funktioner i Enterprise Edition, inklusive fullständigt stöd för tillgänglighetsgrupper. Den är dock endast licensierad för utveckling och testning, inte för produktionsanvändning.

F: Kräver läsbara sekundärfiler ytterligare licenser?

A: Licensiering beror på scenariot. Passiva sekundärer för katastrofåterställning kräver vanligtvis inte licenser. Aktiva sekundärer som hanterar skrivskyddade arbetsbelastningar kräver vanligtvis licenser, även om specifika villkor varierar.

F: Finns det ett gratis sätt att få hög tillgänglighet med SQL Server?

A: SQL Server Express Edition stöder inte tillgänglighetsgrupper. SQL Server Standardutgåvan stöder grundläggande tillgänglighetsgruppertarting med SQL Server 2016, vilket ger grundläggande hög tillgänglighet vid Standard Edition-licenseringosts.

F: Vad är distribuerade tillgänglighetsgrupper?

A: Distribuerade tillgänglighetsgrupper är en speciell typ av tillgänglighetsgrupp som sträcker sig över två separata tillgänglighetsgrupper, vilket möjliggör scenarier som överskrider möjligheterna hos traditionella tillgänglighetsgrupper. Introducerades i SQL Server 2016 tar distribuerade tillgänglighetsgrupper upp skalnings- och geografiska distributionskrav.

6. Slutsats

6.1 Sammanfattning av nyckelpunkter

SQL Server Always On Availability Groups representerar Microsofts främsta lösning för hög tillgänglighet och katastrofåterställning för verksamhetskritiska databaser. De tillhandahåller redundansväxling på databasnivå utan krav på delad lagring, läsbara sekundära repliker för avlastning av arbetsbelastningar och flexibel geografisk distribution för omfattande dataskydd. För organisationer som fortfarande kör lösningar som timmertransport or replikation, tillgänglighetsgrupper erbjuder en mer robust och operativt enklare uppgraderingsväg.

6.2 När ska man använda Always On-tillgänglighetsgrupper

Välj tillgänglighetsgrupper när du behöver hög tillgänglighet på databasnivå med automatisk redundansväxling. Organisationer som behöver noll dataförlustskydd för kritiska databaser drar nytta av synkrona commit-repliker med automatisk redundansväxling. Program som kräver lässkalafunktioner utnyttjar läsbara sekundära repliker för att distribuera frågearbetsbelastningar.

6.3 Att få Starmed din implementering

Börja planeringen av tillgänglighetsgruppen genom att bedöma affärskrav inklusive RTO, RPO och budgetbegränsningar. Dokumentera aktuell databasinfrastruktur, applikationsberoenden och höga tillgänglighetsgap. Utforma en arkitektur för tillgänglighetsgruppen som tillgodoser kraven samtidigt som den håller sig inom resursbegränsningarna.

Referensprojekt

• Microsofts officiella dokument: Vad är en Always On-tillgänglighetsgrupp?
• Microsofts officiella dokument: Få Started med Always On-tillgänglighetsgrupper
• Microsofts officiella dokument: Distribuerade tillgänglighetsgrupper

---

Om författaren

Yuan Sheng är en senior databasadministratör (DBA) med över 10 års erfarenhet av SQL Server miljöer och hantering av företagsdatabaser. Han har framgångsrikt löst hundratals scenarier för databasåterställning inom finansiella tjänster, hälso- och sjukvård och tillverkningsorganisationer.

Yuan specialiserar sig på SQL Server Databasåterställning, lösningar för hög tillgänglighet och prestandaoptimering. Hans omfattande praktiska erfarenhet inkluderar hantering av databaser på flera terabyte, implementering av Always On Availability Groups och utveckling av automatiserade säkerhetskopierings- och återställningsstrategier för verksamhetskritiska affärssystem.

Genom sin tekniska expertis och praktiska tillvägagångssätt fokuserar Yuan på att skapa omfattande guider som hjälper databasadministratörer och IT-proffs att lösa komplexa problem. SQL Server utmaningar effektivt. Han håller sig uppdaterad med det senaste SQL Server utgåvor och Microsofts ständigt föränderliga databastekniker, och testar regelbundet återställningsscenarier för att säkerställa att hans rekommendationer återspeglar bästa praxis i verkligheten.

Har frågor om SQL Server återställning eller behöver du ytterligare vägledning om felsökning av databasen? Yuan välkomnar feedback och förslag för att förbättra dessa tekniska resurser.