Dela via

Vad är en AlwaysOn-tillgänglighetsgrupp?

gäller för:SQL Server

Den här artikeln beskriver begreppen AlwaysOn-tillgänglighetsgrupper som är centrala för att konfigurera och hantera en eller flera tillgänglighetsgrupper i Enterprise-utgåvan av SQL Server. För Standard-utgåvan, granska Basic Always On-tillgänglighetsgrupper för en enda databas.

Funktionen Always On-tillgänglighetsgrupper är en hög tillgänglighets- och katastrofåterställningslösning som erbjuder ett alternativ på företagsnivå till databasspegling. AlwaysOn-tillgänglighetsgrupper maximerar tillgängligheten för en uppsättning användardatabaser för ett företag. En tillgänglighetsgrupp stöder en failover-miljö för en diskret uppsättning användardatabaser, så kallade tillgänglighetsdatabaser, som växlar över tillsammans. En tillgänglighetsgrupp stöder en uppsättning primära läs- och skrivbara databaser och en till åtta uppsättningar motsvarande sekundära databaser. Alternativt kan sekundära databaser göras tillgängliga för skrivskyddad åtkomst och/eller vissa säkerhetskopieringsåtgärder.

Med SQL Server aktiverat av Azure Arckan du visa tillgänglighetsgrupper i Azure-portalen.

Överblick

En tillgänglighetsgrupp stöder en replikerad miljö för en diskret uppsättning användardatabaser, som kallas tillgänglighetsdatabaser. Du kan skapa en tillgänglighetsgrupp för hög tillgänglighet (HA) eller för lässkalning. En HA-tillgänglighetsgrupp är en grupp databaser som failover tillsammans. En tillgänglighetsgrupp i lässkala är en grupp databaser som kopieras till andra instanser av SQL Server för skrivskyddad arbetsbelastning. En tillgänglighetsgrupp stöder en uppsättning primära databaser och en till åtta uppsättningar motsvarande sekundära databaser. Sekundära databaser är inte säkerhetskopior. Fortsätt att säkerhetskopiera dina databaser och deras transaktionsloggar regelbundet.

Tips

Du kan skapa valfri typ av säkerhetskopiering av en primär databas. Du kan också skapa loggsäkerhetskopior och endast kopiera fullständiga säkerhetskopior av sekundära databaser. Mer information finns i Avlasta säkerhetskopieringar som stöds till sekundära repliker av en tillgänglighetsgrupp.

Varje uppsättning tillgänglighetsdatabaser hanteras av en tillgänglighetsreplik. Det finns två typer av tillgänglighetsrepliker: en enda primär replik, som är värd för de primära databaserna och en till åtta sekundära repliker, som var och en är värd för en uppsättning sekundära databaser och fungerar som potentiella redundansmål för tillgänglighetsgruppen. En tillgänglighetsgrupp växlar över på en tillgänglighetsrepliks nivå. En tillgänglighetsreplik ger endast redundans på databasnivå för uppsättningen databaser i en tillgänglighetsgrupp. Failovers orsakas inte av databasproblem som att en databas anses misstänkt på grund av förlust av en datafil eller skada på en transaktionslogg.

Den primära repliken gör de primära databaserna tillgängliga för läs- och skrivanslutningar från klienter. Den primära repliken skickar transaktionsloggposter för varje primär databas till varje sekundär databas. Den här processen – som kallas datasynkronisering – sker på databasnivå. Varje sekundär replik cachelagrar transaktionsloggposterna (härdar loggen) och tillämpar dem sedan på motsvarande sekundära databas. Datasynkronisering sker mellan den primära databasen och varje ansluten sekundär databas, oberoende av de andra databaserna. Därför kan en sekundär databas pausas eller misslyckas utan att påverka andra sekundära databaser, och en primär databas kan pausas eller misslyckas utan att påverka andra primära databaser.

Du kan också konfigurera en eller flera sekundära repliker så att de stöder skrivskyddad åtkomst till sekundära databaser, och du kan konfigurera valfri sekundär replik för att tillåta säkerhetskopior på sekundära databaser.

SQL Server 2017 introducerade två olika arkitekturer för tillgänglighetsgrupper. Always On-tillgänglighetsgrupper tillhandahåller hög tillgänglighet, haveriberedskap och lässkalningsutjämning. Dessa tillgänglighetsgrupper kräver en klusterhanterare. I Windows tillhandahåller funktionen för failoverklustring klusterhanteraren. I Linux kan du använda Pacemaker. Den andra arkitekturen är en tillgänglighetsgrupp för lässkala. En läsoptimerad tillgänglighetsgrupp tillhandahåller repliker för skrivskyddade arbetsbelastningar men inte hög drifttillgänglighet. I en tillgänglighetsgrupp för lässkalning finns det ingen klusterhanterare, eftersom failover inte kan vara automatisk.

För att distribuera AlwaysOn-tillgänglighetsgrupper för HA i Windows krävs ett Windows Server-redundanskluster (WSFC). Varje tillgänglighetsreplik av en viss tillgänglighetsgrupp måste finnas på en annan nod i samma WSFC. Det enda undantaget är att när en tillgänglighetsgrupp migreras till ett annat WSFC-kluster kan den tillfälligt korsa två kluster.

Not

Information om tillgänglighetsgrupper i Linux finns i Tillgänglighetsgrupper för SQL Server på Linux.

I en HA-konfiguration skapas en klusterroll för varje tillgänglighetsgrupp som du skapar. WSFC-klustret övervakar den här rollen för att utvärdera hälsan hos den primära kopian. Kvorumet för AlwaysOn-tillgänglighetsgrupper baseras på alla noder i WSFC-klustret oavsett om en viss klusternod är värd för några tillgänglighetsrepliker. Till skillnad från databasspegling finns det ingen vittnesroll i AlwaysOn-tillgänglighetsgrupper.

Not

Information om relationen mellan SQL Server AlwaysOn-komponenter och WSFC-klustret finns i Windows Server-redundansklustring med SQL Server.

Följande bild visar en tillgänglighetsgrupp som innehåller en primär replik och fyra sekundära repliker. Upp till åtta sekundära repliker stöds, inklusive en primär replik och fyra synkrona sekundära repliker.

diagram över en tillgänglighetsgrupp med fem repliker.

Konfigurera TLS 1.3-kryptering

Förhandsversionen av SQL Server 2025 (17.x) introducerar stöd för Tabelldataström 8.0 , vilket gör att du kan framtvinga TLS 1.3-kryptering för kommunikation mellan Windows Server-redundansklustret och dina AlwaysOn-tillgänglighetsgrupprepliker. Kom igång genom att läsa Anslut med strikt kryptering.

Termer och definitioner

Begrepp Beskrivning
tillgänglighetsgrupp En container för en uppsättning databaser, tillgänglighetsdatabaser, som redundansväxlar tillsammans.
tillgänglighetsdatabas En databas som tillhör en tillgänglighetsgrupp. För varje tillgänglighetsdatabas har tillgänglighetsgruppen en enda skrivskyddad kopia (den primära databasen) och en till åtta skrivskyddade kopior (sekundära databaser).
primär databas Skrivbar kopia av en disponibilitetsdatabas.
sekundär databas En skrivskyddad kopia av en tillgänglighetsdatabas.
tillgänglighetsreplik En instans av en tillgänglighetsgrupp som en specifik instans av SQL Server är värd för och underhåller en lokal kopia av varje tillgänglighetsdatabas som tillhör tillgänglighetsgruppen. Det finns två typer av tillgänglighetsrepliker: en enda primär replik och en till åtta sekundära repliker.
primär replik Tillgänglighetsrepliken som gör de primära databaserna tillgängliga för skriv-läsanslutningar från klienter och skickar transaktionsloggposter för varje primär databas till varje sekundär replika.
sekundär kopia En tillgänglighetsreplik som underhåller en sekundär kopia av varje tillgänglighetsdatabas och fungerar som ett potentiellt failover-mål för tillgänglighetsgruppen. Alternativt kan en sekundär replik ha stöd för skrivskyddad åtkomst till sekundära databaser som kan användas för att skapa säkerhetskopior på sekundära databaser.
tillgänglighetsgruppslyssnare Ett servernamn som klienter kan ansluta till för att få åtkomst till en databas i en primär eller sekundär replik av en tillgänglighetsgrupp. Tillgänglighetsgrupplyssnare dirigerar inkommande anslutningar till den primära repliken eller till en skrivskyddad sekundär replik.

Tillgänglighetsdatabaser

Om du vill lägga till en databas i en tillgänglighetsgrupp måste databasen vara en onlinedatabas med läs- och skrivbehörighet som finns på den serverinstans som är värd för den primära repliken. När du lägger till en databas ansluter den till tillgänglighetsgruppen som en primär databas, samtidigt som den är tillgänglig för klienter. Det finns ingen motsvarande sekundär databas förrän du återställer säkerhetskopior av den nya primära databasen till den serverinstans som är värd för den sekundära repliken (med RESTORE WITH NORECOVERY). Den nya sekundära databasen är i återställningsläge tills den är ansluten till tillgänglighetsgruppen. Mer information finns i Starta dataflytt på en Always On-sekundär databas (SQL Server).

Genom att koppla den sekundära databasen till onlinetillståndet initieras datasynkronisering med motsvarande primära databas. Datasynkronisering är den process genom vilken ändringar i en primär databas återskapas på en sekundär databas. Datasynkronisering innebär att den primära databasen skickar transaktionsloggposter till den sekundära databasen.

Viktig

En tillgänglighetsdatabas kallas ibland för en databasreplik i namnen Transact-SQL, PowerShell och SQL Server Management Objects (SMO). Termen "databasreplik" används till exempel i namnen på de dynamiska hanteringsvyerna AlwaysOn som returnerar information om tillgänglighetsdatabaser: sys.dm_hadr_database_replica_states och sys.dm_hadr_database_replica_cluster_states. Men i SQL Server Books Online refererar termen "replik" vanligtvis till tillgänglighetsrepliker. Till exempel refererar "primär replik" och "sekundär replik" alltid till tillgänglighetsrepliker.

Tillgänglighetsrepliker

Varje tillgänglighetsgrupp definierar en uppsättning med två eller flera failover-partners som kallas tillgänglighetsrepliker. tillgänglighetsrepliker är komponenter i tillgänglighetsgruppen. Varje tillgänglighetsreplik är värd för en kopia av tillgänglighetsdatabaserna i tillgänglighetsgruppen. För en viss tillgänglighetsgrupp måste separata instanser av SQL Server som finns på olika noder i ett WSFC-kluster vara värd för tillgänglighetsreplikerna. Var och en av dessa serverinstanser måste vara aktiverad för AlwaysOn.

SQL Server 2019 (15.x) ökar det maximala antalet synkrona repliker till 5, upp från 3 i SQL Server 2017 (14.x). Du kan konfigurera den här gruppen med fem repliker så att den har automatisk redundans i gruppen. Det finns en primär replik, plus fyra synkrona sekundära repliker.

En viss instans kan bara vara värd för en tillgänglighetsreplik per tillgänglighetsgrupp. Du kan dock använda varje instans för många tillgänglighetsgrupper. En viss instans kan vara antingen en fristående instans eller en SQL Server-redundansklusterinstans (FCI). Om du behöver redundans på servernivå använder du redundansklusterinstanser.

Varje tillgänglighetsreplik tilldelas en inledande roll – antingen den primära rollen eller den sekundära rollen, som tillgänglighetsdatabaserna för repliken ärver. Rollen för en viss replik avgör om den värdar läsa och skriva databaser eller skrivskyddade databaser. En replik, som kallas primära repliken, tilldelas den primära rollen och är värd för läs- och skrivbara databaser, som kallas primära databaser. Minst en annan replica, känd som en sekundär replica, tilldelas den sekundära rollen. En sekundär replik hostar skrivskyddade databaser, så kallade sekundära databaser.

Not

När rollen för en tillgänglighetsreplika är obestämd, till exempel vid en failover, är dess databaser tillfälligt i tillståndet INTE SYNKRONISERAR. Deras roll är inställd på RESOLVEING tills rollen för tillgänglighetsrepliken har lösts. Om en tillgänglighetsreplik övergår till den primära rollen blir dess databaser de primära databaserna. Om en tillgänglighetsreplik matchar den sekundära rollen blir dess databaser sekundära databaser.

Tillgänglighetslägen

Varje tillgänglighetsreplik har en egenskap för tillgänglighetsläge. Tillgänglighetsläget bestämmer huruvida den primära repliken väntar med att bekräfta transaktioner i databasen tills en viss sekundär replik skriver transaktionsloggposterna till disk. AlwaysOn-tillgänglighetsgrupper stöder två tillgänglighetslägen: asynkront incheckningsläge och synkront incheckningsläge.

  • Asynkront kommitteringsläge

    En tillgänglighetsreplik som använder det här tillgänglighetsläget kallas för en asynkron incheckningsreplik. I asynkron incheckningsläge genomför den primära repliken transaktioner utan att vänta på bekräftelse från de asynkrona sekundära replikerna för att säkra sina transaktionsloggar. Asynkront incheckningsläge minimerar transaktionsfördröjningen på de sekundära databaserna, men gör att de kan släpa efter de primära databaserna, vilket gör vissa dataförluster möjliga.

  • synkront commit-läge

    En tillgänglighetsreplik som använder det här tillgänglighetsläget kallas en synkron commit-replik. I läget synkron incheckning väntar en synkron incheckningsreplik innan transaktionerna genomförs, på att en synkron-incheckningsreplik ska bekräfta att loggen har hårdnat. Synkront incheckningsläge säkerställer att när en viss sekundär databas har synkroniserats med den primära databasen skyddas de incheckade transaktionerna fullständigt. Det här skyddet sker på bekostnad av ökad transaktionsfördröjning. Alternativt introducerade SQL Server 2017 en nödvändiga synkroniserade sekundärfiler funktion för att ytterligare öka säkerheten på bekostnad av svarstid när så önskas. Funktionen REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT kan aktiveras för att kräva ett angivet antal synkrona repliker att genomföra en transaktion innan en huvudreplik tillåts genomföra den.

Mer information finns i Skillnader mellan tillgänglighetslägen för en AlwaysOn-tillgänglighetsgrupp.

Typer av failöver

Sessionen mellan den primära repliken och en sekundär replik kan innebära en omkoppling där de primära och sekundära rollerna byts i en process som kallas omkoppling. Vid en redundansväxling övergår den sekundära replikan till rollen som primär och blir den nya primära replikan. Den nya primära repliken tar sina databaser online som primära databaser, och klientapplikationer kan ansluta till dem. När den tidigare primära repliken är tillgänglig byter den till en sekundär roll och blir en sekundär replica. De tidigare primära databaserna blir sekundära databaser och datasynkroniseringen återupptas.

En tillgänglighetsgrupp växlar över på en tillgänglighetsrepliks nivå. Övergångar inträffar inte på grund av databasproblem som att en databas flaggas som misstänkt på grund av förlust av en datafil, borttagandet av en databas eller korruption av en transaktionslogg.

Det finns tre former av redundans: automatisk, manuell och tvingad (med möjlig dataförlust). De former av failover som en given sekundär replika stöder beror på dess tillgänglighetsläge. För synkront incheckningsläge beror det också på redundansläget på den primära repliken och den sekundära målrepliken enligt följande.

  • Läget Synkrona avsändningsläge stöder två former av failover: planerad manuell failover och automatisk failover, om målsekundärreplikan för närvarande är synkroniserad med den primära replikan. Inställningen för egenskapen för redundansläge på redundanspartner avgör stöd för dessa former av redundans. Om du ställer in redundansläget till manuellt på antingen den primära eller sekundära repliken stöder den sekundära repliken endast manuell redundans. Om du ställer in redundansläget på automatiskt på både de primära och sekundära replikerna stöder den sekundära repliken både automatisk och manuell redundans.

    • Planerad manuell failover (utan dataförlust)

    En manuell redundansväxling sker efter att en databasadministratör utfärdar ett failover-kommando. Det gör att en synkroniserad sekundär replik övergår till den primära rollen (med garanterat dataskydd) och att den primära repliken ändras till den sekundära rollen. En manuell redundans kräver att både den primära repliken och den sekundära målrepliken körs i synkront incheckningsläge och att den sekundära repliken redan måste synkroniseras.

    • Automatisk redundansväxling (utan dataförlust)

    En automatisk redundansväxling sker som svar på ett fel. Det gör att en synkroniserad sekundär replik övergår till den primära rollen (med garanterat dataskydd). När den tidigare primära repliken blir tillgänglig ändras den till den sekundära rollen. Automatisk redundans kräver att både den primära repliken och den sekundära målrepliken körs i synkront incheckningsläge med redundansläget inställt på Automatisk. Dessutom måste den sekundära repliken redan vara synkroniserad, ha WSFC-kvorum och uppfylla de villkor som anges av flexibel failover-policy för tillgänglighetsgruppen.

  • I läget asynkron commit är den enda formen av failover tvingad manuell failover (med möjlig dataförlust), som vanligtvis kallas tvingad failover. Tvingad övertagning är en form av manuell övertagning eftersom du måste initiera den själv. Tvingad redundans är ett alternativ för haveriberedskap. Det är den enda formen av redundans som är möjlig när den sekundära målrepliken inte synkroniseras med den primära repliken.

Mer information finns i redundans- och redundanslägen (AlwaysOn-tillgänglighetsgrupper).

Viktig

  • SQL Server failover-klusterinstanser (FCIs) stöder inte automatisk failover av tillgänglighetsgrupper, så du kan bara konfigurera manuell failover för alla tillgänglighetsrepliker som en FCI är värd för.
  • Om du utfärdar ett framtvingat överflyttningskommando på en synkroniserad sekundär replik beter sig den sekundära repliken på samma sätt som vid en planerad manuell överflyttning.

Fördelar

AlwaysOn-tillgänglighetsgrupper ger en omfattande uppsättning alternativ som förbättrar databasens tillgänglighet och förbättrar resursanvändningen. Nyckelkomponenterna är följande:

Klientanslutningar

Du kan tillhandahålla klientanslutning till den primära repliken för en viss tillgänglighetsgrupp genom att skapa en tillgänglighetsgruppslyssnare. En tillgänglighetsgruppslyssnare tillhandahåller en uppsättning resurser som är kopplade till en viss tillgänglighetsgrupp för att dirigera klientanslutningar till lämplig tillgänglighetsreplik.

En lyssnare för tillgänglighetsgrupper är associerad med ett unikt DNS-namn som fungerar som ett virtuellt nätverksnamn (VNN), en eller flera virtuella IP-adresser (VIP) och ett TCP-portnummer. Mer information finns i Anslut till en AlwaysOn-tillgänglighetsgruppslyssnare.

Om en tillgänglighetsgrupp bara har två tillgänglighetsrepliker och inte är konfigurerad för att tillåta läsåtkomst till den sekundära repliken kan klienterna ansluta till den primära repliken med hjälp av en anslutningssträng för databasspegling. Den här metoden kan vara användbar tillfälligt när du har migrerat en databas från databasspegling till AlwaysOn-tillgänglighetsgrupper. Innan du lägger till sekundära repliker måste du skapa en tillgänglighetsgruppslyssnare för tillgänglighetsgruppen och uppdatera dina program så att de använder lyssnarens nätverksnamn.

Not

Förhandsversionen av SQL Server 2025 (17.x) introducerar TDS 8.0-stöd, vilket gör det möjligt att framtvinga strikt TLS 1.3-kryptering för anslutningar till dina AlwaysOn-tillgänglighetsgrupprepliker och lyssnare. Kom igång genom att läsa Anslut med strikt kryptering.

Aktiva sekundära repliker

AlwaysOn-tillgänglighetsgrupper stöder aktiva sekundära repliker. Aktiva sekundära funktioner omfattar stöd för:

  • Utföra säkerhetskopieringsåtgärder på sekundära repliker

    De sekundära replikerna stöder säkerhetskopiering av loggar och endast kopiering säkerhetskopior av en fullständig databas, fil eller filgrupp. Du kan konfigurera tillgänglighetsgruppen för att ange en inställning för var säkerhetskopior ska utföras. Det är viktigt att förstå att SQL Server inte tillämpar inställningarna, så det har ingen effekt på ad hoc-säkerhetskopior. Tolkningen av den här inställningen beror på logiken, om någon, som du integrerar i dina säkerhetskopieringsjobb för varje databas i en specifik tillgänglighetsgrupp. För en enskild tillgänglighetsreplik kan du ange din prioritet för att utföra säkerhetskopior på den här repliken i förhållande till de andra replikerna i samma tillgänglighetsgrupp. Mer information finns i Avlasta säkerhetskopieringar som stöds till sekundära repliker av en tillgänglighetsgrupp.

  • skrivskyddad åtkomst till en eller flera sekundära repliker (läsbara sekundära repliker)

    Du kan konfigurera valfri sekundär tillgänglighetsreplik för att endast tillåta skrivskyddad åtkomst till dess lokala databaser, även om vissa åtgärder inte stöds fullt ut. Den här konfigurationen förhindrar läs-skrivanslutningsförsök till den sekundära repliken. Det går också att förhindra skrivskyddade arbetsbelastningar på den primära repliken genom att endast tillåta skrivskyddad åtkomst. Den här konfigurationen förhindrar att skrivskyddade anslutningar görs till den primära repliken. Mer information finns i Avlasta enbart läsbar arbetsbelastning till en sekundär replik i en Always On-tillgänglighetsgrupp.

    Om en tillgänglighetsgrupp för närvarande har en tillgänglighetsgrupplyssnare och en eller flera läsbara sekundära repliker kan SQL Server dirigera anslutningsbegäranden med läsavsikt till en av dem (skrivskyddad routning). Mer information finns i Anslut till en AlwaysOn-tillgänglighetsgruppslyssnare.

Tidsgräns för session

Tidsgränsen för sessionen är en egenskap för tillgänglighetsreplik som avgör hur länge en anslutning med en annan tillgänglighetsreplik kan förbli inaktiv innan anslutningen stängs. De primära och sekundära replikerna pingar varandra för att signalera att de fortfarande är aktiva. Att ta emot en ping från den andra repliken under tidsgränsen anger att anslutningen fortfarande är öppen och att serverinstanserna kommunicerar. När du tar emot en ping återställer en tillgänglighetsreplik sin timeout-räknare för sessionen på den anslutningen.

Tidsgränsen för sessionen förhindrar att någon av replikerna väntar på obestämd tid för att få en ping från den andra repliken. Om ingen ping tas emot från den andra repliken inom sessionens tidsgräns, går repliken in i timeout-läge. Anslutningen stängs och den time-outade repliken försätts i frånkopplat läge. Även om en frånkopplad replika har konfigurerats för synkront commit-läge, väntar transaktioner inte på att den ska återansluta och synkronisera om.

Standardinställningen för session-timeout-perioden för varje tillgänglighetsreplik är 10 sekunder. Du kan konfigurera det här värdet till minst 5 sekunder. Håll vanligtvis tidsgränsen på 10 sekunder eller högre. Om du ställer in värdet på mindre än 10 sekunder kan ett system med hög belastning ange ett falskt fel.

Not

I löserollen gäller inte sessionens tidsgräns eftersom det inte sker någon pingning.

Automatisk sidreparation

Varje tillgänglighetsreplik försöker automatiskt återställa från skadade sidor i en lokal databas genom att lösa vissa typer av fel som förhindrar läsning av en datasida. Om en sekundär replik inte kan läsa en sida begär repliken en ny kopia av sidan från den primära repliken. Om den primära repliken inte kan läsa en sida sänder repliken en begäran om en ny kopia till alla sekundära repliker och hämtar sidan från den första för att svara. Om den här begäran lyckas ersätts den oläsliga sidan av kopian, vilket vanligtvis löser felet.

Mer information finns i Automatisk sidreparation (tillgänglighetsgrupper: Databasspegling).

Samverkan och samexistens med andra funktioner i databasmotorn

AlwaysOn-tillgänglighetsgrupper fungerar med följande funktioner eller komponenter i SQL Server:

Nästa steg

Komma igång med AlwaysOn-tillgänglighetsgrupper