Replicas van beschikbaarheidsgroepen bijwerken

van toepassing op:SQL Server-

Wanneer u een SQL Server-exemplaar bijwerkt die een host is voor een Always On-beschikbaarheidsgroep (AG) naar een nieuwe SQL Server-versie, naar een nieuw SQL Server-servicepack of cumulatieve update, of wanneer u installeert naar een nieuw Windows-servicepack of cumulatieve update, kunt u de downtime voor de primaire replica beperken tot slechts één handmatige failover door een rolling upgrade uit te voeren (of twee handmatige failovers als u een failback naar de oorspronkelijke primaire replica uitvoert).

Tijdens het upgradeproces is een secundaire replica niet beschikbaar voor failover- of alleen-lezenbewerkingen. Na de upgrade kan het enige tijd duren voordat de secundaire replica het primaire replicaknooppunt bijwerkt, afhankelijk van het volume van de activiteit op het primaire replicaknooppunt (dus verwacht veel netwerkverkeer).

Houd er ook rekening mee dat na de eerste failover naar een secundaire replica waarop een nieuwere versie van SQL Server wordt uitgevoerd, de databases in die AG een upgradeproces doorlopen om ze naar de nieuwste versie te brengen. Gedurende deze tijd zijn er geen leesbare replica's voor een van deze databases. Downtime na de eerste failover is afhankelijk van het aantal databases in de beschikbaarheidsgroep. Als u van plan bent om een failback uit te voeren naar de oorspronkelijke primaire versie, wordt deze stap niet herhaald wanneer u een failback uitvoert.

Notitie

In dit artikel wordt de discussie beperkt tot de upgrade van SQL Server zelf. Het heeft geen betrekking op het upgraden van het besturingssysteem met het Windows Server Failover Cluster (WSFC). Het upgraden van het Windows-besturingssysteem dat als host fungeert voor het failovercluster wordt niet ondersteund voor besturingssystemen van vóór Windows Server 2012 R2. Als u een clusterknooppunt wilt upgraden dat wordt uitgevoerd op Windows Server 2012 R2, raadpleegt u Rolling Upgrade van het clusterbesturingssysteem.

Voorwaarden

Bekijk voordat u begint de volgende belangrijke informatie:

• Ondersteunde versie- en editie-upgrades: controleer of u vanaf uw versie van het Windows-besturingssysteem en de versie van SQL Server kunt upgraden naar de nieuwste versie van SQL Server. Als u bijvoorbeeld rechtstreeks een upgrade uitvoert vanaf een SQL Server 2005-exemplaar, wordt uw databasecompatibiliteitsniveau bijgewerkt.

• Kies een upgrademethode voor een database-engine: als u een upgrade wilt uitvoeren in de juiste volgorde, selecteert u de juiste upgrademethode en stappen op basis van uw beoordeling van ondersteunde versie- en editie-upgrades, en ook op basis van andere onderdelen die in uw omgeving zijn geïnstalleerd.

• het upgradeplan voor de database-engine plannen en testen: bekijk de releaseopmerkingen en bekende upgradeproblemen, de controlelijst vóór de upgrade en ontwikkel en test het upgradeplan.

• Hardware- en softwarevereisten voor het installeren van SQL Server: controleer de softwarevereisten voor het installeren van SQL Server. Als er extra software vereist is, installeert u deze op elk knooppunt voordat u begint met het upgradeproces om downtime te minimaliseren.

• Controleer of er gebruik wordt gemaakt van wijzigingsgegevens vastlegging of replicatie voor AG-databases: als er databases in de AG zijn die zijn ingeschakeld voor het vastleggen van wijzigingsgegevens (CDC), voer dan deze instructiesuit.

Notitie

Het combineren van versies van SQL Server-exemplaren in dezelfde AG wordt niet ondersteund buiten een rolling upgrade en mag niet voor langere tijd in die toestand verkeren, omdat de upgrade snel moet plaatsvinden. De andere optie voor het upgraden van SQL Server 2016 (13.x) en latere versies is via het gebruik van een gedistribueerde beschikbaarheidsgroep.

Notitie

Het gebruik van de functie Cluster-Aware Update (CAU) Windows om AlwaysOn-beschikbaarheidsgroepen bij te werken, wordt niet ondersteund.

Basisbeginselen van rolling upgrades voor beschikbaarheidsgroepen

Bekijk de volgende richtlijnen bij het uitvoeren van serverupgrades of updates om downtime en gegevensverlies voor uw AG's te minimaliseren:

• Voordat u de stapsgewijze upgrade start:

  • Voer een handmatige failover uit op ten minste één van uw synchrone commit-replica's

  • Uw gegevens beveiligen door een volledige databaseback-up uit te voeren op elke beschikbaarheidsdatabase

  • DBCC CHECKDB uitvoeren op elke beschikbaarheidsdatabase

• Upgrade altijd eerst de externe secundaire replica-exemplaren, vervolgens lokale secundaire replica-exemplaren daarna en het primaire replica-exemplaar voor het laatst.

• Back-ups kunnen niet worden uitgevoerd op een database die bezig is met het upgraden. Voordat u de secundaire replica's bijwerken, configureert u de automatische back-upvoorkeur om alleen back-ups uit te voeren op de primaire replica. Tijdens een versie-upgrade zijn er geen replica's leesbaar of beschikbaar voor back-ups. Tijdens een upgrade zonder versie kunt u geautomatiseerde back-ups configureren voor uitvoering op secundaire replica's voordat u de primaire replica bijwerken.

• Tijdens een versie-upgrade kunnen leesbare secundaire bestanden niet worden gelezen na een upgrade van de leesbare secundaire en voordat een failover van de primaire replica wordt uitgevoerd naar een bijgewerkte secundaire replica of de primaire replica wordt bijgewerkt.

• Als u wilt voorkomen dat de beschikbaarheidsgroep onbedoelde failovers tijdens het upgradeproces uitvoert, verwijdert u de beschikbaarheidsfailover van alle synchrone doorvoerreplica's voordat u begint.

• Werk het primaire replica-exemplaar niet bij voordat u een failover van de AG uitvoert naar een bijgewerkt exemplaar met een secundaire replica. Anders kunnen clienttoepassingen langere downtime ondervinden tijdens de upgrade op het primaire replica-exemplaar.

• Voer altijd een failover uit van de AG naar een secundair replica-exemplaar met synchrone doorvoer. Als u een failover uitvoert naar een secundair replica-exemplaar met asynchrone doorvoer, zijn de databases kwetsbaar voor gegevensverlies en wordt de gegevensverplaatsing automatisch opgeschort totdat u de gegevensverplaatsing handmatig hervat.

• Werk het primaire replica-exemplaar niet bij voordat u een ander secundair replica-exemplaar bijwerkt of bijwerkt. Een bijgewerkte primaire replica kan geen logboeken meer verzenden naar een secundaire replica waarvan het SQL Server-exemplaar dat nog niet is bijgewerkt naar dezelfde versie. Wanneer gegevensverplaatsing naar een secundaire replica wordt onderbroken, kan er geen automatische failover plaatsvinden voor die replica en zijn uw beschikbaarheidsdatabases kwetsbaar voor gegevensverlies. Dit geldt ook tijdens een rolling upgrade waarbij u handmatig een failover uitvoert van een oude primaire naar een nieuwe primaire. Als zodanig moet u mogelijk de synchronisatie hervatten nadat u de oude primaire versie hebt bijgewerkt.

• Voordat u een failover uitvoert voor een beschikbaarheidsgroep, controleert u of de synchronisatiestatus van het failoverdoel is SYNCHRONIZED.

  Waarschuwing

  Het installeren van een nieuw exemplaar of een nieuwe versie van SQL Server op een server waarop een oudere versie van SQL Server is geïnstalleerd, kan per ongeluk een storing veroorzaken voor een beschikbaarheidsgroep die wordt gehost door de oudere versie van SQL Server. Dit komt doordat tijdens de installatie van het exemplaar of de versie van SQL Server de module voor hoge beschikbaarheid van SQL Server (RHS.EXE) wordt bijgewerkt. Dit resulteert in een tijdelijke onderbreking van uw bestaande beschikbaarheidsgroepen die de primaire rol op de server vervullen. Daarom wordt het ten zeerste aanbevolen om een van de volgende handelingen uit te voeren bij het installeren van een nieuwere versie van SQL Server op een systeem dat al een oudere versie van SQL Server host met een beschikbaarheidsgroep:

  • Installeer de nieuwe versie van SQL Server tijdens een onderhoudsvenster.

  • Failover van de beschikbaarheidsgroep naar de secundaire replica, zodat deze niet primair is tijdens de installatie van het nieuwe SQL Server-exemplaar.

Rolling upgradeproces

In de praktijk is het exacte proces afhankelijk van factoren zoals de implementatietopologie van uw AG's en de doorvoermodus van elke replica. Maar in het eenvoudigste scenario is een rolling upgrade een proces met meerdere fasen dat in de eenvoudigste vorm de volgende stappen omvat:

1. Automatische failover verwijderen voor alle synchrone doorvoerreplica's
2. Werk alle asynchrone secundaire replica-exemplaren bij.
3. Upgrade alle secundaire replica-instanties met synchronisatie-commit op afstand.
4. Upgrade alle lokale synchrone commit secundaire replica-instanties.
5. Handmatig een failover van de AG uitvoeren naar een lokaal synchrone-commit secundaire replica (recent bijgewerkt).
6. Werk het lokale replica-exemplaar dat vroeger de primaire replica hostte, bij of upgrade deze.
7. Configureer automatische failoverpartners naar wens.

Indien nodig kunt u een extra handmatige failover uitvoeren om de beschikbaarheidsgroep terug te keren naar de oorspronkelijke configuratie.

Notitie

Bij het bijwerken en offline halen van een synchrone-commit-replica worden de transacties op de primaire replica niet vertraagd. Zodra de verbinding met de secundaire replica is verbroken, worden transacties doorgevoerd op de primaire replica zonder te wachten tot logboeken worden beveiligd op de secundaire replica.

Als REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT is ingesteld op 1 of 2, is de primaire replica mogelijk niet beschikbaar voor lees-/schrijfbewerkingen wanneer een bijbehorend aantal secundaire replica's van synchronisatie niet beschikbaar is tijdens het updateproces.

Notitie

Wanneer u een in-place upgrade uitvoert van een secundaire replica naar een nieuwere versie van SQL Server, blijft de database in de beschikbaarheidsgroep in de status Synchroniseren/In herstel of Gesynchroniseerd/In herstel totdat de beschikbaarheidsgroep handmatig wordt overgeschakeld, waarmee het herstel wordt voltooid en de database wordt bijgewerkt. Een bijgewerkte primaire replica kan geen logboeken meer verzenden naar een secundaire replica van een lagere versie en gegevensverplaatsing stopt en er kan geen automatische failover plaatsvinden voor die replica en uw beschikbaarheidsdatabases zijn kwetsbaar voor gegevensverlies. Nadat u de oude primaire versie hebt bijgewerkt, moet u mogelijk de synchronisatie hervatten. Het is raadzaam om alle secundaire replica's bij te werken voordat u een failover naar een replica met de nieuwe versie uitvoert. Op die manier hebt u de mogelijkheid om een failover uit te voeren nadat de database(en) zijn bijgewerkt naar de nieuwe indeling.

AG met één externe secundaire replica

Als u een AG alleen hebt geïmplementeerd voor herstel na noodgevallen, moet u mogelijk een failover van de AG uitvoeren naar een secundaire replica met asynchrone doorvoer. Deze configuratie wordt geïllustreerd door de volgende afbeelding:

In dit geval moet u de AG-failover uitvoeren naar de secundaire replica met asynchrone commit tijdens de geleidelijke upgrade. Als u gegevensverlies wilt voorkomen, wijzigt u de doorvoermodus in synchrone doorvoer en wacht u tot de secundaire replica is gesynchroniseerd voordat u een failover van de beschikbaarheidsgroep uitvoert. Daarom kan het rolling upgradeproces er als volgt uitzien:

1. Het secundaire replica-exemplaar op de externe site bijwerken
2. De doorvoermodus wijzigen in synchrone doorvoer
3. Wacht totdat de synchronisatiestatus is SYNCHRONIZED
4. Voer een failover uit van de AG naar de secundaire replica op de externe site
5. Het lokale (primaire site) replica-exemplaar upgraden of bijwerken
6. Failover van de beschikbaarheidsgroep naar de primaire site uitvoeren
7. De doorvoermodus wijzigen in asynchrone doorvoer

Omdat de synchrone doorvoermodus geen aanbevolen instelling is voor gegevenssynchronisatie naar een externe site, kunnen clienttoepassingen een onmiddellijke toename van de databaselatentie merken nadat de instelling is gewijzigd. Bovendien zorgt het uitvoeren van een failover ervoor dat alle niet-bekende logboekberichten worden verwijderd. Het aantal genegeerde logboekberichten kan aanzienlijk zijn vanwege de hoge netwerklatentie tussen de twee sites, waardoor clients een groot aantal transactionele fouten ondervinden. U kunt het effect op clienttoepassingen minimaliseren door de volgende acties uit te voeren:

• Selecteer zorgvuldig een onderhoudsvenster tijdens weinig clientverkeer

• Wijzig tijdens het upgraden of bijwerken van SQL Server op de primaire site de beschikbaarheidsmodus terug naar asynchrone doorvoer en keer vervolgens terug naar synchrone doorvoer wanneer u weer een failover naar de primaire site wilt uitvoeren

AG met failover-cluster-knooppunten

Als een AG FCI-knooppunten (failoverclusterexemplaar) bevat, moet u de inactieve knooppunten upgraden voordat u de actieve knooppunten bijwerken. In de volgende afbeelding wordt een algemeen AG-scenario geïllustreerd met FCI's voor lokale hoge beschikbaarheid en asynchrone commits tussen de FCI's voor extern herstel na noodgevallen en de upgradevolgorde.

1. REMOTE2 upgraden of bijwerken
2. Failover van FCI2 naar REMOTE2
3. REMOTE1 upgraden of bijwerken
4. PRIMARY2 upgraden of bijwerken
5. Voer een failover van FCI1 uit naar PRIMARY2
6. PRIMARY1 upgraden of bijwerken

SQL Server-exemplaren upgraden of bijwerken met meerdere beschikbaarheidsgroepen

Als u meerdere AG's met primaire replica's uitvoert op afzonderlijke serverknooppunten (een actief/actief-configuratie), omvat het upgradepad meer failoverstappen om hoge beschikbaarheid in het proces te behouden. Stel dat u drie AG's uitvoert op drie serverknooppunten met alle replica's in de synchrone doorvoermodus, zoals wordt weergegeven in de volgende tabel:

AG	Node1	Node2	Node3
AG1	Primair
AG2		Primair
AG3			Primair

Het kan geschikt zijn in uw situatie om een rolling upgrade met gelijke taakverdeling uit te voeren in de volgende volgorde:

1. Failover van AG2 naar Node3 (om Node2vrij te maken)
2. Node2 upgraden of bijwerken
3. Overschakelen van AG1 naar Node2 (om Node1vrij te maken)
4. Node1 upgraden of bijwerken
5. Failover uitvoeren van zowel AG2 als AG3 naar Node1 (om Node3vrij te maken)
6. Node3 upgraden of bijwerken
7. Failover van AG3 naar Node3

Deze upgradereeks heeft een gemiddelde downtime van minder dan twee failovers per AG. De resulterende configuratie wordt weergegeven in de volgende tabel.

AG	Node1	Node2	Node3
AG1		Primair
AG2	Primair
AG3			Primair

Op basis van uw specifieke implementatie kan uw upgradepad variëren en de downtime die clienttoepassingen ervaren, kan ook variëren.

Notitie

In veel gevallen voert u een failback uit naar de oorspronkelijke primaire replica nadat de rolling upgrade is voltooid.

Rolling upgrade van een gedistribueerde beschikbaarheidsgroep

Als u een rolling upgrade van een gedistribueerde beschikbaarheidsgroep wilt uitvoeren, moet u eerst alle secundaire replica's upgraden. Vervolgens voert u een failover uit van de doorstuurserver en voert u een upgrade uit van het laatste resterende exemplaar van de tweede beschikbaarheidsgroep. Zodra alle andere replica's zijn bijgewerkt, voert u een failover uit van de globale primaire replica en voert u een upgrade uit van het laatste resterende exemplaar van de eerste beschikbaarheidsgroep. Hieronder vindt u een gedetailleerd diagram met stappen.

Op basis van uw specifieke implementatie kan uw upgradepad variëren en de downtime die clienttoepassingen ervaren, kan ook variëren.

Notitie

In veel gevallen schakelt u, nadat de rolling upgrade is voltooid, terug naar de oorspronkelijke primaire replica's.

Algemene stappen voor het upgraden van een gedistribueerde beschikbaarheidsgroep

1. Maak een back-up van alle databases, inclusief systeemdatabases en de databases die deelnemen aan de beschikbaarheidsgroep.
2. Upgrade en start alle secundaire replica's van de tweede beschikbaarheidsgroep (downstream) opnieuw op.
3. Voer een upgrade uit en start alle secundaire replica's van de eerste beschikbaarheidsgroep opnieuw op (de upstream).
4. Failover van de primaire doorstuurserver naar een bijgewerkte secundaire replica van de secundaire beschikbaarheidsgroep.
5. Wacht op gegevenssynchronisatie. De databases moeten worden weergegeven als gesynchroniseerd op alle synchronous-commit replicas, en de global primary moet worden gesynchroniseerd met de forwarder.
6. Voer een upgrade uit en start het laatste resterende exemplaar van de secundaire beschikbaarheidsgroep opnieuw.
7. Voer een failover uit van de globale primaire node naar een bijgewerkte secundaire node van de eerste beschikbaarheidsgroep.
8. Werk de laatste resterende instantie van de primaire beschikbaarheidsgroep bij.
9. Start de zojuist bijgewerkte server opnieuw op.
10. (optioneel) Failback van beide beschikbaarheidsgroepen naar de oorspronkelijke primaire replica's.

Belangrijk

Controleer de synchronisatie tussen elke stap. Voordat u doorgaat met de volgende stap, controleert u of uw synchrone commit-replica's zijn gesynchroniseerd binnen de beschikbaarheidsgroep en of uw globale primaire is gesynchroniseerd met de forwarder in de gedistribueerde beschikbaarheidsgroep.

aanbeveling: telkens wanneer u synchronisatie verifieert, vernieuwt u zowel het databaseknooppunt als het gedistribueerde AG-knooppunt in SQL Server Management Studio. Nadat alles is gesynchroniseerd, slaat u een schermopname op van de statussen van elke replica. Zo kunt u bijhouden welke stap u uitvoert, bewijs leveren dat alles correct werkte voor de volgende stap en u helpen bij het oplossen van problemen als er iets misgaat.

Diagramvoorbeeld voor een rolling upgrade van een gedistribueerde beschikbaarheidsgroep

Beschikbaarheidsgroep	Primaire replica	Secundaire replica
AG1	NODE1\SQLAG	NODE2\SQLAG
AG2	NODE3\SQLAG	NODE4\SQLAG
DistributedAG	AG1 (globaal)	AG2 (doorstuurserver)

De stappen voor het upgraden van de exemplaren in dit diagram:

1. Maak een back-up van alle databases, inclusief systeemdatabases en de databases die deelnemen aan de beschikbaarheidsgroep.
2. Voer een upgrade uit NODE4\SQLAG (secundair van AG2) en start de server opnieuw op.
3. Voer een upgrade uit NODE2\SQLAG (secundair van AG1) en start de server opnieuw op.
4. Failover van AG2 van NODE3\SQLAG naar NODE4\SQLAG.
5. Voer een upgrade uit NODE3\SQLAG en start de server opnieuw op.
6. Het uitvoeren van een failover van AG1 van NODE1\SQLAG naar NODE2\SQLAG.
7. Voer een upgrade uit NODE1\SQLAG en start de server opnieuw op.
8. (optioneel) Failback naar de oorspronkelijke primaire replica's.
   1. Failover van AG2 vanaf NODE4\SQLAG terug naar NODE3\SQLAG.
   2. Failover van AG1 van NODE2\SQLAG terug naar NODE1\SQLAG.

Als er in elke beschikbaarheidsgroep een derde replica bestaat, wordt deze bijgewerkt voordat NODE3\SQLAG en NODE1\SQLAG.

Belangrijk

Controleer de synchronisatie tussen elke stap. Voordat u doorgaat met de volgende stap, controleert u of uw synchronous commit-replica's zijn gesynchroniseerd binnen de beschikbaarheidsgroep en of uw globale primaire gesynchroniseerd is met de forwarder in de gedistribueerde beschikbaarheidsgroep.

aanbeveling: telkens wanneer u synchronisatie verifieert, vernieuwt u zowel het databaseknooppunt als het distributed AG-knooppunt in SQL Server Management Studio. Als alles is gesynchroniseerd, maakt u een schermopname en slaat u deze op. Zo kunt u bijhouden welke stap u uitvoert, bewijs leveren dat alles correct werkte voor de volgende stap en u helpen bij het oplossen van problemen als er iets misgaat.

Speciale stappen voor het vastleggen of repliceren van gegevenswijziging

Afhankelijk van de update die wordt toegepast, zijn er mogelijk extra stappen vereist voor AG-replicadatabases die zijn ingeschakeld voor het vastleggen of repliceren van gegevens. Raadpleeg de releaseopmerkingen voor de update om te bepalen of de volgende stappen vereist zijn:

1. Voer een upgrade uit voor elke secundaire replica.

2. Nadat alle secundaire replica's zijn bijgewerkt, zet u de Availability Group over naar een geüpgradede instantie.

3. Voer de volgende Transact-SQL uit op het exemplaar dat als host fungeert voor de primaire replica:

   SQL

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

   Notitie

   Het uitvoeren van deze opdracht kan enkele minuten duren. Sla deze stap over als u sql Server 2019 CU1 of hoger gebruikt. Raadpleeg KB4530283 voor meer informatie

4. Voer een upgrade uit van het exemplaar dat oorspronkelijk de primaire replica was.

Zie voor achtergrondinformatie , aangezien de CDC-functionaliteit kan worden verstoord na een upgrade naar de meest recente CU.

Zie ook

• SQL Server upgraden met behulp van de installatiewizard (Setup)
• SQL Server installeren vanaf de opdrachtprompt