Dela via

Vad är en AlwaysOn-tillgänglighetsgrupp?

  • Artikel

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.

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 instansiering av en tillgänglighetsgrupp som hanteras av en specifik instans av SQL Server och som 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 säkerhetskopior av den nya primära databasen återställs 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 tillgänglighetsreplikerna hanteras av separata instanser av SQL Server som finns på olika noder i ett WSFC-kluster. 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. Varje instans kan dock användas 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 ärvs av tillgänglighetsdatabaserna för repliken. 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.

Obs.

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

Tillgänglighetsläget är en egenskap för varje tillgänglighetsreplik. Tillgänglighetsläget avgör om den primära repliken väntar på att checka in transaktioner i en databas tills en viss sekundär replik har skrivit transaktionsloggposterna till disken (härdade loggen). 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 synkront förpliktelseläge väntar en synkron huvudreplika innan transaktionerna förpliktas på att en synkron sekundär replika ska bekräfta att den har slutfört logghärdningen. 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

Inom ramen för en session mellan den primära repliken och en sekundär replik kan rollerna vara potentiellt utbytbara i en process som kallas felhantering. Vid ett felövergång övergår den sekundära målreplikan till den primära rollen 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 övergår den till den sekundära rollen och blir en sekundär replik. De tidigare primära databaserna blir sekundära databaser och datasynkroniseringen återupptas.

En tillgänglighetsgrupp växlar över på nivå med en tillgänglighetsreplika. Övergångar orsakas inte av databasproblem som att en databas blir osäker på grund av förlust av en datafil, borttagning av en databas eller skada på en transaktionslogg.

Tre former av redundans finns automatiskt, manuellt och framtvingad (med möjlig dataförlust). Formuläret eller formerna för redundans som stöds av en viss sekundär replik beror på dess tillgänglighetsläge och, för synkront incheckningsläge, på redundansläget på den primära repliken och den sekundära målrepliken enligt följande.

  • Synkront incheckningsläge stöder två former av redundans–planerad manuell redundansväxling och automatisk redundansväxling, om den sekundära målrepliken för närvarande synkroniseras med den primära repliken. Stödet för dessa former av failover beror på inställningen av failoverlägegenskapen på failover-partners. Om redundansläget är inställt på "manuell" på antingen den primära eller sekundära repliken stöds endast manuell redundans för den sekundära repliken. Om redundansläget är inställt på "automatisk" på både de primära och sekundära replikerna stöds både automatisk och manuell redundans på den sekundära repliken.

    • Planerad manuell failover (utan dataförlust)

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

    • Automatisk redundansväxling (utan dataförlust)

      En automatisk failover inträffar som svar på ett fel som gör att en synkroniserad sekundär replika överförs till den primära rollen (med garanterat dataskydd). När den tidigare primära repliken blir tillgänglig övergår 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 redundans anses vara en form av manuell redundans eftersom den bara kan initieras manuellt. 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-redundansklusterinstanser (FCIs) stöder inte automatisk redundans av tillgänglighetsgrupper, så alla tillgänglighetsrepliker som hanteras av en FCI kan bara konfigureras för manuell redundans.
  • 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.

Tips

Om en tillgänglighetsgrupp bara har två tillgänglighetsrepliker och inte har konfigurerats för att tillåta läsåtkomst till den sekundära repliken, kan klienter ansluta till den primära repliken med hjälp av en databasspeglingsanslutningssträng. 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 ytterligare sekundära repliker måste du skapa en tillgänglighetsgrupplyssnare för tillgänglighetsgruppen och uppdatera dina program så att de använder lyssnarens nätverksnamn.

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 inställningen inte tillämpas av SQL Server, 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 Överför stödda säkerhetskopior till sekundära repliker i en tillgänglighetsgrupp.

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

    En valfri sekundär tillgänglighetsreplika kan konfigureras för att tillåta enbart skrivskyddad åtkomst till sina lokala databaser, även om vissa operationer inte stöds fullt ut. Detta förhindrar läs- och 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. Detta förhindrar att endast-läsbara anslutningar görs till den primära repliken. Mer information finns i Avlasta läsbaserad arbetsbelastning till en sekundär replik av en AlwaysOn-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 avsikt att läsa till en av dem (read-only routing). 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 anslutningen 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 mottas från den andra repliken inom session-timeout-perioden löper repliken ut. Dess anslutning stängs och den tidsgränsöverskridande repliken försätts i tillståndet frånkopplad. Ä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. Det här värdet är användarkonfigurerbart, med minst 5 sekunder. I allmänhet rekommenderar vi att du behåller 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.

Notera

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 kan användas med följande funktioner eller komponenter i SQL Server:

Nästa steg

Komma igång med AlwaysOn-tillgänglighetsgrupper