Uppgradera repliker i tillgänglighetsgrupp

gäller för:SQL Server

När du uppgraderar en SQL Server-instans som är värd för en AlwaysOn-tillgänglighetsgrupp (AG) till en ny SQL Server-version, till ett nytt SQL Server-servicepaket eller en kumulativ uppdatering, eller när du installerar till ett nytt Windows Service Pack eller en kumulativ uppdatering, kan du minska stilleståndstiden för den primära repliken till endast en enda manuell redundansväxling genom att utföra en löpande uppgradering (eller två manuella redundansväxlingar om du misslyckas tillbaka till den ursprungliga primära repliken).

Under uppgraderingsprocessen kommer en sekundär replik inte att vara tillgänglig för redundans eller för skrivskyddade åtgärder, och efter uppgraderingen kan det ta lite tid för den sekundära repliken att komma ikapp den primära repliknoden beroende på aktivitetsvolymen på den primära repliknoden (så förvänta dig hög nätverkstrafik).

Tänk också på att efter den första redundansväxlingen till en sekundär replik som kör en nyare version av SQL Server, kommer databaserna i den tillgänglighetsgruppen att köras genom en uppgraderingsprocess för att ta dem till den senaste versionen. Under den här tiden kommer det inte att finnas några läsbara repliker för någon av dessa databaser. Stilleståndstid efter den första överflyttningen beror på antalet databaser i AG. Om du planerar att återgå till den ursprungliga primären, kommer detta steg inte att upprepas när du återgår.

Anmärkning

Den här artikeln begränsar diskussionen till uppgraderingen av själva SQL Server. Det omfattar inte uppgradering av operativsystemet som innehåller Windows Server-redundansklustret (WSFC). Uppgradering av Windows-operativsystemet som är värd för redundansklustret stöds inte för operativsystem före Windows Server 2012 R2. Information om hur du uppgraderar en klusternod som körs på Windows Server 2012 R2 finns i Löpande uppgradering av klusteroperativsystem.

Förutsättningar

Läs följande viktiga information innan du börjar:

• versions- och versionsuppgraderingar som stöds: Kontrollera att du kan uppgradera till den senaste versionen av SQL Server från din version av Windows-operativsystemet och versionen av SQL Server. Om du till exempel uppgraderar direkt från en SQL Server 2005-instans uppgraderas databasens kompatibilitetsnivå.

• Välj en uppgraderingsmetod för databasmotorn: Om du vill uppgradera i rätt ordning väljer du lämplig uppgraderingsmetod och steg baserat på din granskning av version och versionsuppgraderingar som stöds, och även baserat på andra komponenter som är installerade i din miljö.

• Planera och testa uppgraderingsplanen för databasmotorn: Granska viktig information och kända uppgraderingsproblem, checklistan före uppgraderingen och utveckla och testa uppgraderingsplanen.

• maskinvaru- och programvarukrav för installation av SQL Server-: Granska programvarukraven för att installera SQL Server. Om ytterligare programvara krävs installerar du den på varje nod innan du påbörjar uppgraderingsprocessen för att minimera eventuella driftstopp.

• Kontrollera om ändringsdatainsamling eller replikering används för AG-databaser: Om några databaser i AG är aktiverade för ändringsdatainsamling (CDC), slutför du dessa instruktioner.

Anteckning

Blandning av versioner av SQL Server-instanser i samma tillgänglighetsgrupp stöds inte utanför en löpande uppgradering och bör inte finnas i det tillståndet under längre tidsperioder eftersom uppgraderingen bör ske snabbt. Det andra alternativet för att uppgradera SQL Server 2016 (13.x) och senare versioner är genom att använda en distribuerad tillgänglighetsgrupp.

Notera

Det går inte att använda funktionen Cluster-Aware Update (CAU) Windows för att uppdatera AlwaysOn-tillgänglighetsgrupper.

Grundläggande om rullande uppgradering för tillgänglighetsgrupper

Observera följande riktlinjer när du utför serveruppgraderingar eller uppdateringar för att minimera stilleståndstid och dataförlust för dina AG:er:

• Innan du påbörjar den löpande uppgraderingen:

  • Utför en manuell redundansväxling på minst en av dina synkrona replikinstanser

  • Skydda dina data genom att utföra en fullständig databassäkerhetskopia på varje tillgänglighetsdatabas

  • Kör DBCC CHECKDB på alla tillgänglighetsdatabaser

• Uppgradera alltid de sekundära fjärrreplikinstanserna först, sedan lokala sekundära replikinstanser och den primära replikinstansen sist.

• Säkerhetskopieringar kan inte ske på en databas som håller på att uppgraderas. Innan du uppgraderar de sekundära replikerna konfigurerar du inställningen för automatisk säkerhetskopiering så att endast säkerhetskopieringar körs på den primära repliken. Under en versionsuppgradering är inga repliker läsbara eller tillgängliga för säkerhetskopior. Under en icke-versionsuppgradering kan du konfigurera automatiserade säkerhetskopieringar så att de körs på sekundära repliker innan du uppgraderar den primära repliken.

• Under en versionsuppgradering kan läsbara sekundärer inte läsas efter en uppgradering av den läsbara sekundären och innan antingen den primära repliken växlas över till en uppgraderad sekundär, eller den primära repliken uppgraderas.

• För att förhindra oavsiktliga överflyttningar av AG under uppgraderingsprocessen, tar du bort överflyttning av tillgänglighet från alla synkrona kommiterade repliker innan du börjar.

• Uppgradera inte den primära replikinstansen innan du växlar över tillgänglighetsgruppen till en uppgraderad instans med en sekundär replik först. Annars kan klientprogram drabbas av längre stilleståndstid under uppgraderingen på den primära replikinstansen.

• Redundansväxla alltid AG till en sekundär replikinstans med synkront åtagande. Om du redundansväxlar till en sekundär replikinstans med asynkron incheckning är databaserna sårbara för dataförlust och dataflytten pausas automatiskt tills du återupptar dataflytten manuellt.

• Uppgradera inte den primära replikinstansen innan du uppgraderar eller uppdaterar någon annan sekundär replikinstans. En uppgraderad primär replik kan inte längre skicka loggar till en sekundär replik vars SQL Server-instans ännu inte har uppgraderats till samma version. När dataflytten till en sekundär replik pausas kan ingen automatisk redundansväxling ske för repliken och dina tillgänglighetsdatabaser är sårbara för dataförlust. Detta gäller även under en löpande uppgradering där du manuellt redundansväxlar från en gammal primär till en ny primär. När du har uppgraderat den gamla primära databasen kan du därför behöva återuppta synkroniseringen.

• Innan du redundansväxlar en tillgänglighetsgrupp kontrollerar du att synkroniseringstillståndet för redundansmålet är SYNCHRONIZED.

  Varning

  Om du installerar en ny instans eller en ny version av SQL Server på en server som har en äldre version av SQL Server installerad kan det oavsiktligt orsaka ett avbrott för alla tillgänglighetsgrupper som hanteras av den äldre versionen av SQL Server. Detta beror på att sql Server-modulen (RHS.EXE) uppgraderas under installationen av instansen eller versionen av SQL Server. Detta resulterar i ett tillfälligt avbrott i dina befintliga tillgänglighetsgrupper i den primära rollen på servern. Därför rekommenderar vi starkt att du gör något av följande när du installerar en nyare version av SQL Server till ett system som redan är värd för en äldre version av SQL Server med en tillgänglighetsgrupp:

  • Installera den nya versionen av SQL Server under ett underhållsperiod.

  • Växla över tillgänglighetsgruppen till den sekundära repliken för att se till att den inte är primär under installationen av den nya SQL Server-instansen.

Löpande uppgraderingsprocess

I praktiken beror den exakta processen på faktorer som distributionstopologin för dina AG:er och committillståndet för varje replika. Men i det enklaste scenariot är en löpande uppgradering en process i flera steg som i sin enklaste form omfattar följande steg:

1. Ta bort automatisk failover på alla synkrona commit-repliker
2. Uppgradera alla sekundära replikinstanser med asynkront commit.
3. Uppgradera alla sekundära replikinstanser med fjärrsynkron incheckning.
4. Uppgradera alla lokala synkrona åtagande sekundära replikor.
5. Utför manuell failover av den tillgänglighetsgruppen till en (nyligen uppgraderad) lokal sekundär replik med synkron commit.
6. Uppgradera eller uppdatera den lokala replikinstansen som tidigare var värd för den primära repliken.
7. Konfigurera automatiska failover-partners vid behov.

Om det behövs kan du utföra en extra manuell redundansväxling för att återgå till den ursprungliga konfigurationen.

Observera

Om du uppgraderar en synkroniserad commit-replika och tar den offline, kommer transaktionerna på den primära servern inte att fördröjas. När den sekundära repliken är frånkopplad utförs transaktioner på den primära utan att vänta på att loggarna ska hårdna på den sekundära repliken.

Om REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT är inställt på antingen 1 eller 2kan den primära repliken vara otillgänglig för läsning/skrivningar när ett motsvarande antal sekundära synkroniseringsrepliker inte är tillgängliga under uppdateringsprocessen.

Not

När du utför en direktuppgradering av en sekundär replik till en nyare version av SQL Server finns databasen i tillgänglighetsgruppen kvar i Synkronisering / Vid återställning eller Synkroniserad / Vid återställning tillstånd tills tillgänglighetsgruppen omväxlas manuellt, vilket slutför återställningen och uppgraderar databasen. En uppgraderad primär replik kan inte längre skicka loggar till sekundära repliker med lägre version, och dataflyttning stoppas. Ingen automatisk överflyttning kan ske för den repliken, och dina tillgänglighetsdatabaser är sårbara för dataförlust. När du har uppgraderat den gamla primära databasen kan du behöva återuppta synkroniseringen. Vi rekommenderar att du uppgraderar alla sekundära repliker innan du växlar över till en replik med den nya versionen. På så sätt kan du göra en redundansväxling efter att databasen(es) har uppgraderats till det nya formatet.

AG med en fjärransluten sekundär replik

Om du har implementerat en tillgänglighetsgrupp enbart i syfte att skydda mot katastrofer kan du behöva växla över till en sekundär replik med asynkron bekräftelse. Den här konfigurationen illustreras med följande bild:

I det här fallet måste du växla över tillgänglighetsgruppen till den sekundära repliken i asynkron kopplingsläge under den löpande uppgraderingen. För att förhindra dataförlust ändrar du incheckningsläget till synkron incheckning och väntar tills den sekundära repliken synkroniseras innan du redundansväxlar tillgänglighetsgruppen. Därför kan den löpande uppgraderingsprocessen se ut så här:

1. Uppgradera den sekundära replikinstansen på fjärrplatsen
2. Ändra incheckningsläget till synkron incheckning
3. Vänta tills synkroniseringstillståndet är SYNCHRONIZED
4. Växla tillgänglighetsgruppen till den sekundära repliken på fjärrplatsen
5. Uppgradera eller uppdatera replikinstansen för den lokala primärsidan
6. Växla över tillgänglighetsgruppen tillbaka till den primära platsen
7. Ändra incheckningsläget till asynkron incheckning

Eftersom synkron-kommitteringsläge inte är en rekommenderad inställning för datasynkronisering till en fjärrplats kan klientapplikationer märka en omedelbar ökning av databaslatens efter att inställningen har ändrats. Dessutom medför en redundansväxling att alla oerkända loggmeddelanden slängs. Antalet borttagna loggmeddelanden kan vara betydande på grund av den höga nätverksfördröjningen mellan de två platserna, vilket gör att klienterna upplever en stor mängd transaktionsfel. Du kan minimera effekten på klientprogram genom att utföra följande åtgärder:

• Välj noggrant en underhållsperiod under låg kundtrafik

• När du uppgraderar eller uppdaterar SQL Server på den primära platsen ändrar du tillbaka tillgänglighetsläget till asynkron incheckning och återgår sedan till synkron incheckning när du är redo att växla över till den primära platsen igen

Tillgänglighetsgrupp med instansnoder för failover-kluster

Om en tillgänglighetsgrupp innehåller noder för redundansklusterinstanser (FCI) bör du uppgradera de inaktiva noderna innan du uppgraderar de aktiva noderna. Följande bild illustrerar ett vanligt AG-scenario med FCI:er för lokal hög tillgänglighet och asynkron commit mellan FCI:erna för fjärrkatastrofåterställning, samt uppgraderingssekvensen.

1. Uppgradera eller uppdatera REMOTE2
2. Växla över FCI2 till REMOTE2
3. Uppgradera eller uppdatera REMOTE1
4. Uppgradera eller uppdatera PRIMARY2
5. Växla över FCI1 till PRIMARY2
6. Uppgradera eller uppdatera PRIMARY1

Uppgradera eller uppdatera SQL Server-instanser med flera AG:er

Om du kör flera AG:er med primära repliker på separata servernoder (en aktiv/aktiv konfiguration) omfattar uppgraderingssökvägen fler redundanssteg för att bevara hög tillgänglighet i processen. Anta att du kör tre AG:er på tre servernoder med alla repliker i synkront incheckningsläge enligt följande tabell:

AG	Node1	Node2	Nod3
AG1	Primär
AG2		Primär
AG3			Primär

I din situation kan det vara lämpligt att utföra en belastningsbalanserad löpande uppgradering i följande sekvens:

1. Växla över AG2 till Node3 (för att frigöra Node2)
2. Uppgradera eller uppdatera Node2
3. Överför ansvaret för AG1 till Node2 (för att frigöra Node1)
4. Uppgradera eller uppdatera Node1
5. Överför både AG2 och AG3 till Node1 för att frigöra Node3.
6. Uppgradera eller uppdatera Node3
7. Överlåt AG3 till Node3

Den här uppgraderingssekvensen har en genomsnittlig stilleståndstid på färre än två redundansväxlingar per tillgänglighetsgrupp. Den resulterande konfigurationen visas i följande tabell.

AG	Node1	Node2	Nod3
AG1		Primär
AG2	Primär
AG3			Primär

Baserat på din specifika implementering kan uppgraderingsvägen variera och den stilleståndstid som klientprogram upplever kan också variera.

Not

I många fall kommer du att växla tillbaka till den ursprungliga primära repliken när den löpande uppgraderingen har slutförts.

Löpande uppgradering av en distribuerad tillgänglighetsgrupp

Om du vill utföra en löpande uppgradering av en distribuerad tillgänglighetsgrupp uppgraderar du först alla sekundära repliker. Nästa, växla över till redundansläge för vidarebefordraren och uppgradera den sista återstående instansen av den andra tillgänglighetsgruppen. När alla andra repliker har uppgraderats, växla över den globala primära instansen och uppgradera den sista återstående instansen i den första tillgänglighetsgruppen. Ett detaljerat diagram med steg finns nedan.

Baserat på din specifika implementering kan uppgraderingsvägen variera och den stilleståndstid som klientprogram upplever kan också variera.

Not

I många fall kommer du att återgå till de ursprungliga primära kopiorna när den löpande uppgraderingen har slutförts.

Allmänna steg för att uppgradera en distribuerad tillgänglighetsgrupp

1. Säkerhetskopiera alla databaser, inklusive systemdatabaser, och de som deltar i tillgänglighetsgruppen.
2. Uppgradera och starta om alla sekundära repliker i den andra tillgänglighetsgruppen (nedströms).
3. Uppgradera och starta om alla sekundära repliker i den första tillgänglighetsgruppen (uppströms).
4. Redundansväxla vidarebefordrarens primära till en uppgraderad sekundär replik av den sekundära tillgänglighetsgruppen.
5. Vänta på datasynkronisering. Databaserna ska visas som synkroniserade på alla synkrona commit-repliker och den globala primär ska synkroniseras med vidarebefordraren.
6. Uppgradera och starta om den sista återstående instansen av den sekundära tillgänglighetsgruppen.
7. Växla över den globala huvudservern till en uppgraderad sekundärserver för den första tillgänglighetsgruppen.
8. Uppgradera den sista återstående instansen av den primära tillgänglighetsgruppen.
9. Starta om den nyligen uppgraderade servern.
10. (valfritt) Återställ båda tillgänglighetsgrupperna till sina ursprungliga primära repliker.

Viktig

Kontrollera synkroniseringen mellan varje steg. Innan du fortsätter till nästa steg, kontrollera att dina synkrona åtaganderepliker är synkroniserade i tillgänglighetsgruppen och att din globala primär är synkroniserad med vidarebefordraren i den distribuerade tillgänglighetsgruppen.

Rekommendation: Varje gång du verifierar synkroniseringen uppdaterar du både databasnoden och den distribuerade AG-noden i SQL Server Management Studio. När allt har synkroniserats sparar du en skärmbild av statusen för varje replik. Detta hjälper dig att hålla reda på vilket steg du är på, ge bevis för att allt fungerade korrekt före nästa steg och hjälpa dig med felsökning om något går fel.

Diagramexempel för en löpande uppgradering av en distribuerad tillgänglighetsgrupp

Tillgänglighetsgrupp	Primär kopia	Sekundär kopia
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistribueradAG	AG1 (global)	AG2 (speditör)

Stegen för att uppgradera instanserna i det här diagrammet:

1. Säkerhetskopiera alla databaser, inklusive systemdatabaser, och de som deltar i tillgänglighetsgruppen.
2. Uppgradera NODE4\SQLAG (sekundär för AG2) och starta om servern.
3. Uppgradera NODE2\SQLAG (sekundär för AG1) och starta om servern.
4. Felöverskiftning AG2 från NODE3\SQLAG till NODE4\SQLAG.
5. Uppgradera NODE3\SQLAG och starta om servern.
6. Felkör ag1 från NODE1\SQLAG till NODE2\SQLAG.
7. Uppgradera NODE1\SQLAG och starta om servern.
8. (valfritt) Växla tillbaka till de ursprungliga primära replikerna.
   1. Misslyckande för AG2 över från NODE4\SQLAG tillbaka till NODE3\SQLAG.
   2. Växla över AG1 från NODE2\SQLAG tillbaka till NODE1\SQLAG.

Om en tredje replik fanns i varje tillgänglighetsgrupp skulle den uppgraderas innan NODE3\SQLAG och NODE1\SQLAG.

Viktig

Kontrollera synkroniseringen mellan varje steg. Innan du fortsätter till nästa steg kontrollerar du att dina synkrona commit-repliker synkroniseras i tillgänglighetsgruppen, och att den globala primära noden synkroniseras med förmedlaren i den distribuerade tillgänglighetsgruppen.

Rekommendation: Varje gång du verifierar synkroniseringen uppdaterar du både databasnoden och noden för den Distribuerade Tillgänglighetsgruppen i SQL Server Management Studio. Om allt har synkroniserats tar du en skärmbild och sparar det. Detta hjälper dig att hålla reda på vilket steg du är på, ge bevis för att allt fungerade korrekt före nästa steg och hjälpa dig med felsökning om något går fel.

Särskilda steg för ändring av datainsamling eller replikering

Beroende på vilken uppdatering som tillämpas kan ytterligare steg krävas för AG-replikeringsdatabaser som är aktiverade för insamling eller replikering av ändringsdata. Se versionsinformationen för uppdateringen för att avgöra om följande steg krävs:

1. Uppgradera varje sekundär replik.

2. När alla sekundära repliker har uppgraderats redundansväxlar du tillgänglighetsgruppen till en uppgraderad instans.

3. Kör följande Transact-SQL på den instans som är värd för den primära repliken:

   EXECUTE [master].[sys].[sp_vupgrade_replication];
   

   Notera

   Det kan ta flera minuter att köra det här kommandot. Hoppa över det här steget om du använder SQL Server 2019 CU1 eller senare. För mer information, se KB4530283

4. Uppgradera den instans som ursprungligen var den primära repliken.

Bakgrundsinformation finns i . CDC-funktioner kan sluta fungera efter uppgradering till den senaste CU.

Se även

• Uppgradera SQL Server med installationsguiden (installation)
• Installera SQL Server från kommandotolken