Failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)

Van toepassing op:SQL Server

In dit artikel worden failover- en failovermodi voor SQL Server AlwaysOn-beschikbaarheidsgroepen beschreven.

Overzicht

Binnen de context van een beschikbaarheidsgroep zijn de primaire rol en secundaire rol van beschikbaarheidsreplica's doorgaans uitwisselbaar in een proces dat failover wordt genoemd. Er bestaan drie vormen van failover: automatische failover (zonder gegevensverlies), geplande handmatige failover (zonder gegevensverlies) en geforceerde handmatige failover (met mogelijk gegevensverlies), meestal geforceerde failover. Zowel automatische als geplande handmatige failover behouden al uw gegevens. Een failover van een beschikbaarheidsgroep gebeurt op replica-niveau. Dat wil gezegd: een failover van een beschikbaarheidsgroep naar een van de secundaire replica's (het huidige failoverdoel).

Tijdens de failover neemt het failoverdoel de primaire rol over, herstelt de databases en brengt deze online als de nieuwe primaire databases. De voormalige primaire replica, indien beschikbaar, schakelt over naar de secundaire rol en de bijbehorende databases worden secundaire databases. Mogelijk kunnen deze rollen heen en weer schakelen (of naar een ander failoverdoel) als reactie op meerdere fouten of voor administratieve doeleinden.

De vormen van failover die door een bepaalde beschikbaarheidsreplica worden ondersteund, worden opgegeven door de eigenschap failovermodus . Voor een bepaalde beschikbaarheidsreplica zijn de mogelijke failovermodi afhankelijk van de beschikbaarheidsmodus van de replica, als volgt:

• Synchrone commit-replica's ondersteunen twee instellingen, automatisch of handmatig. De instelling 'automatisch' ondersteunt zowel automatische failover als handmatige failover. Om gegevensverlies te voorkomen, vereisen automatische failover en geplande failover dat het failoverdoel een synchrone secundaire replica is met een gezonde synchronisatiestatus (dit geeft aan dat elke secundaire database op het failoverdoel wordt gesynchroniseerd met de bijbehorende primaire database). Wanneer een secundaire replica niet aan beide voorwaarden voldoet, ondersteunt deze alleen geforceerde failover. Geforceerde failover wordt ook ondersteund op replica's met de status OPLOSSEN.

• Asynchrone doorvoerreplica's ondersteunen alleen de handmatige failovermodus. Bovendien, omdat ze nooit worden gesynchroniseerd, ondersteunen ze alleen geforceerde failover.

SQL Server 2025-wijzigingen

SQL Server 2025 introduceert de volgende wijzigingen:

Snelle failover voor aanhoudende gezondheidsproblemen

In een AlwaysOn-beschikbaarheidsgroepsomgeving bewaakt het Windows Failover Cluster (WSFC) de status van de beschikbaarheidsgroep en de bijbehorende replica's. Wanneer een gezondheidsprobleem wordt gedetecteerd op de primaire replica, activeert de WSFC een reeks corrigerende acties. De WSFC start standaard de beschikbaarheidsgroepbron opnieuw op de huidige replica. Als de WSFC de resource niet weer online kan brengen, schakelt de WSFC de resource van de beschikbaarheidsgroep over naar een andere replica. Hoewel deze reeks corrigerende acties effectief is voor tijdelijke fouten, kan dit mogelijk leiden tot vertragingen in failover voor niet-tijdelijke fouten.

WSFC-failovergedrag wordt bepaald door de waarde RestartThreshold . RestartThreshold Standaard is ingesteld op 1 voor een AlwaysOn-beschikbaarheidsgroep, wat betekent dat WSFC de resource opnieuw probeert op te starten op het huidige knooppunt voordat een failover wordt uitgevoerd.

Vanaf SQL Server 2025 (17.x) Preview kunt u het RestartThreshold voor een AlwaysOn-beschikbaarheidsgroep instellen op 0, waardoor de WSFC onmiddellijk een failover van de resource van de beschikbaarheidsgroep moet uitvoeren wanneer een permanent statusprobleem wordt gedetecteerd. Dit is handig voor scenario's waarin u downtime wilt minimaliseren en ervoor wilt zorgen dat de beschikbaarheidsgroep altijd beschikbaar is op een goede replica.

Er is een duidelijk compromis:

• Door in te stellen op RestartThreshold 1, is uw beschikbaarheidsgroep toleranter voor tijdelijke fouten en komt u sneller weer online. Failover en downtime kunnen echter langer zijn voor permanente fouten.
• Door in te stellen op RestartThreshold 0, is uw beschikbaarheidsgroep minder tolerant voor tijdelijke fouten, dus kan failover onnodig worden uitgevoerd. Failover en downtime kunnen echter korter zijn voor permanente fouten.

U kunt failoverclusterbeheer of PowerShell gebruiken om de RestartThreshold resource voor een AlwaysOn-beschikbaarheidsgroep in te stellen.

Als u bijvoorbeeld de RestartThreshold op 0 wilt instellen voor de benoemde ag1beschikbaarheidsgroep, gebruikt u de volgende opdracht:

(Get-ClusterResource -Name "ag1").RestartThreshold = 0

U kunt uw huidige RestartThreshold instelling controleren door de volgende opdracht uit te voeren:

Get-ClusterResource -Name "ag1" | Format-List *

Verbetering van het asynchroon afhandelen van paginaverzoeken

Wanneer een failover van een beschikbaarheidsgroep optreedt, moet elke replica een gemeenschappelijk herstelpunt vinden om mee te synchroniseren. Het herstelpunt houdt de beschikbaarheidsgroep stabiel zodat deze wijzigingen kan blijven verzenden. Ongedaan maken of Opnieuw Uitvoeren maakt deel uit van dit synchronisatieproces. Terugdraaien van opnieuw uitvoeren gebeurt wanneer een secundaire replica transacties moet terugzetten om het gemeenschappelijke herstelpunt te bereiken. Het herstellen van voorgaande acties is het meest gebruikelijk tijdens noodherstel overschakeling naar een asynchrone replica met FAILOVER_ALLOW_DATA_LOSS.

In bepaalde situaties, wanneer bij een DR-failover de secundaire replica overgaat naar de primaire, ervaart de nieuwe primaire netwerklatentie van de oorspronkelijke primaire (nu nieuwe secundaire), wat het ongedaan maken van de redo op de nieuwe secundaire vertraagt.

Om het ongedaan maken van opnieuw uitvoeren voor dit scenario te verbeteren, introduceert SQL Server 2025 (17.x) Preview een update van het synchronisatiemechanisme, zodat de beschikbaarheidsgroep nu paginaaanvragen asynchroon en in batches uitvoert.

Houd rekening met het volgende:

• De verbetering van het synchronisatiemechanisme is standaard ingeschakeld. Als u de verbetering wilt uitschakelen en het standaardgedrag wilt herstellen, schakelt u traceringsvlag 12348 in op alle replica's in een beschikbaarheidsgroep die momenteel secundaire bestanden zijn of die in de toekomst mogelijk secundaire bestanden zijn.
• Als de AG-replica's geen netwerklatentie hebben, kan deze verbetering het ongedaan maken van opnieuw uitvoeren mogelijk niet verbeteren.

Databases schakelen over naar de oplossingsstatus na een fout

In zeldzame gevallen blijven een of meer databases van een beschikbaarheidsgroep mogelijk in de status Niet synchroniseren nadat een beschikbaarheidsgroep gedurende korte tijd offline is gegaan vanwege een tijdelijk WSFC-quorumverlies, zoals bij tijdelijke netwerkverbinding of het merendeel van de clusterknooppunten die opnieuw worden opgestart. De update van de herstellogica voor beschikbaarheidsgroepen die is geïntroduceerd in SQL Server 2025 (17.x) Preview verbetert de interne tolerantie voor dit type clusterquorumverlies en voorkomt dat databases van beschikbaarheidsgroepen vastlopen in de status Niet synchroniseren nadat de beschikbaarheidsgroep weer online is.

Termen en definities

Automatische overdracht
Een failover die automatisch optreedt bij het verlies van de primaire replica. Automatische failover wordt alleen ondersteund wanneer de huidige primaire en een secundaire replica beide zijn geconfigureerd met failovermodus ingesteld op AUTOMATISCH en de secundaire replica die momenteel is gesynchroniseerd. Als de failovermodus van de primaire of secundaire replica HANDMATIG is, kan automatische failover niet plaatsvinden.

Geplande handmatige failover (zonder gegevensverlies)
Geplande handmatige failover of handmatige failover is een failover die wordt geïnitieerd door een databasebeheerder, meestal voor administratieve doeleinden. Een geplande handmatige failover wordt alleen ondersteund als zowel de primaire replica als de secundaire replica zijn geconfigureerd voor de modus synchrone doorvoer, en zowel de primaire replica als de secundaire replica worden momenteel gesynchroniseerd (in de status GESYNCHRONISEERD). Wanneer de secundaire doelreplica wordt gesynchroniseerd, is handmatige failover (zonder gegevensverlies) mogelijk, zelfs als de primaire replica is vastgelopen omdat de secundaire databases gereed zijn voor failover. Een databasebeheerder initieert handmatig een handmatige failover.

Geforceerde failover (met mogelijk gegevensverlies)
Een failover die kan worden gestart door een databasebeheerder wanneer er geen secundaire replica wordt GESYNCHRONISEERD met de primaire replica of de primaire replica niet wordt uitgevoerd en er geen secundaire replica gereed is voor failover. Geforceerde failover riskeert mogelijk gegevensverlies en wordt strikt aanbevolen voor herstel na noodgevallen. Geforceerde failover wordt ook wel geforceerde handmatige failover genoemd, omdat deze alleen handmatig kan worden gestart. Dit is de enige vorm van failover die in de asynchroon commit beschikbaarheidsmodus wordt ondersteund.

Automatische failover-instelling

Binnen een bepaalde beschikbaarheidsgroep, een paar beschikbaarheidsreplica's (inclusief de huidige primaire replica) die zijn geconfigureerd voor de synchrone doorvoermodus met automatische failover, indien van toepassing. Een automatische failoverset wordt alleen van kracht als de secundaire replica momenteel is GESYNCHRONISEERD met de primaire replica.

Failoverset synchrone doorvoer

Binnen een bepaalde beschikbaarheidsgroep, een set van twee of drie beschikbaarheidsreplica's (inclusief de huidige primaire replica) die zijn geconfigureerd voor synchrone doorvoermodus, indien van toepassing. Een failoverset voor synchrone doorvoer wordt alleen van kracht als de secundaire replica's zijn geconfigureerd voor de handmatige failovermodus en er momenteel ten minste één secundaire replica wordt GESYNCHRONISEERD met de primaire replica.

Volledige failoverset

Binnen een bepaalde beschikbaarheidsgroep is de set met alle beschikbaarheidsreplica's waarvan de operationele status momenteel ONLINE is, ongeacht de beschikbaarheidsmodus en de failovermodus. De gehele failoverset komt in beeld wanneer er op dit moment geen secundaire replica gesynchroniseerd wordt met de primaire replica.

Overzicht van failover

De volgende tabel bevat een overzicht van welke vormen van failover worden ondersteund onder verschillende beschikbaarheids- en failovermodi. Voor elke koppeling wordt de effectieve beschikbaarheidsmodus en failovermodus bepaald door het snijpunt van de modi van de primaire replica plus de modi van een of meer secundaire replica's.

¹ Als u een opdracht voor geforceerde failover op een gesynchroniseerde secundaire replica uitvoert, gedraagt de secundaire replica zich hetzelfde als voor een handmatige failover.

De hoeveelheid tijd die de database niet beschikbaar is tijdens een failover, is afhankelijk van het type failover en de oorzaak ervan.

Failoversets

De vormen van failover die mogelijk zijn voor een bepaalde beschikbaarheidsgroep, kunnen worden begrepen in termen van failoversets. Een failoverset bestaat uit de primaire replica en secundaire replica's die ondersteuning bieden voor een bepaalde vorm van failover, als volgt:

• Automatische failover (optioneel): Binnen een bepaalde beschikbaarheidsgroep is een paar beschikbaarheidsreplica's (inclusief de huidige primaire replica) geconfigureerd voor de synchronous-commitmodus met automatische failover, indien van toepassing. Een automatische failoverset wordt alleen van kracht als de secundaire replica momenteel is GESYNCHRONISEERD met de primaire replica.

• Failoverset voor synchrone commit (optioneel): Binnen een bepaalde beschikbaarheidsgroep, een set van twee of drie beschikbaarheidsreplica's (inclusief de huidige primaire replica) die zijn geconfigureerd voor synchrone commit-modus, indien van toepassing. Een failoverset voor synchrone doorvoer wordt alleen van kracht als de secundaire replica's zijn geconfigureerd voor de handmatige failovermodus en er momenteel ten minste één secundaire replica wordt GESYNCHRONISEERD met de primaire replica.

• Volledige failoverset: Binnen een bepaalde beschikbaarheidsgroep is de set met alle beschikbaarheidsreplica's waarvan de operationele status momenteel ONLINE is, ongeacht de beschikbaarheidsmodus en de failovermodus. De gehele failoverset komt in beeld wanneer er op dit moment geen secundaire replica gesynchroniseerd wordt met de primaire replica.

Wanneer u een beschikbaarheidsreplica configureert als synchrone doorvoer met automatische failover, wordt de beschikbaarheidsreplica onderdeel van de automatische failoverset. Maar of de set van kracht wordt, is afhankelijk van de huidige primaire. De vormen van failover die op een bepaald moment daadwerkelijk mogelijk zijn, zijn afhankelijk van de failoversets die momenteel van kracht zijn.

Denk bijvoorbeeld aan een beschikbaarheidsgroep met vier beschikbaarheidsreplica's, als volgt:

Het failovergedrag voor elke secundaire replica is afhankelijk van welke beschikbaarheidsreplica momenteel de primaire replica is. In essentie is het failovergedrag voor een bepaalde secundaire replica het ergste scenario, gezien de huidige primaire replica. In de volgende afbeelding ziet u hoe het failovergedrag van secundaire replica's varieert, afhankelijk van de huidige primaire replica en of deze is geconfigureerd voor de asynchrone doorvoermodus (met alleen geforceerde failover) of synchrone doorvoermodus (met of zonder automatische failover).

Automatische failover

Een automatische failover zorgt ervoor dat een gekwalificeerde secundaire replica automatisch overgaat naar de primaire rol nadat de primaire replica niet meer beschikbaar is. Automatische failover is het meest geschikt wanneer het WSFC-knooppunt dat als host fungeert voor de primaire replica lokaal is voor het knooppunt dat als host fungeert voor de secundaire replica. Dit komt doordat gegevenssynchronisatie het beste werkt met een lage berichtlatentie tussen computers en omdat clientverbindingen lokaal kunnen blijven.

In deze sectie:

• Voorwaarden vereist voor een automatische failover

• Hoe automatische failover werkt

• Automatische failover inschakelen

Voorwaarden vereist voor een automatische failover

Automatische failover vindt alleen plaats onder de volgende omstandigheden:

• Er bestaat een automatische failover-set. Deze set bestaat uit een primaire replica en een secundaire replica (het doel voor automatische failover) die beide zijn geconfigureerd voor de synchrone doorvoermodus en ingesteld op AUTOMATISCHE failover. Als de primaire replica is ingesteld op HANDMATIGe failover, kan automatische failover niet plaatsvinden, zelfs niet als een secundaire replica is ingesteld op AUTOMATISCHE failover.

  Zie beschikbaarheidsmodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

• Het doel voor automatische failover heeft een goede synchronisatiestatus (dit geeft aan dat elke secundaire database op het failoverdoel wordt gesynchroniseerd met de bijbehorende primaire database).

  Aanbeveling

  Always On-beschikbaarheidsgroepen controleren de gezondheid van beide replica's in een automatische failoverset. Als een van beide replica's mislukt, wordt de status van de beschikbaarheidsgroep ingesteld op KRITIEK. Als de secundaire replica mislukt, is automatische failover niet mogelijk omdat het doel voor automatische failover niet beschikbaar is. Als de primaire replica mislukt, voert de beschikbaarheidsgroep een failover uit naar de secundaire replica. Totdat de voormalige primaire replica online komt, bestaat er geen automatisch failoverdoel. In beide gevallen raden we u aan om een andere secundaire replica te configureren als het doel voor automatische failover, om de beschikbaarheid in het onwaarschijnlijke geval van een sequentiële fout te garanderen.

  Zie AlwaysOn-beleid gebruiken om de status van een beschikbaarheidsgroep (SQL Server) te bekijken en de failovermodus van een beschikbaarheidsreplica (SQL Server) te wijzigen voor meer informatie.

• Het WSFC-cluster (Windows Server Failover Clustering) heeft quorum. Zie WSFC Quorum Modes and Voting Configuration (SQL Server)voor meer informatie.

• De primaire replica is niet meer beschikbaar en de voorwaarden voor failover die zijn gedefinieerd door uw flexibele failoverbeleid zijn bereikt. Zie Flexibel failoverbeleid voor automatische failover van een beschikbaarheidsgroep (SQL Server) voor informatie over failoverniveaus.

Hoe automatische failover werkt

Een automatische failover initieert de volgende reeks acties:

1. Als het serverexemplaren dat als host fungeert voor de huidige primaire replica nog steeds actief is, wordt de status van de primaire databases gewijzigd in DISCONNECTED en worden alle clients verbroken.

2. Als er logboekrecords in herstelwachtrijen op de secundaire doelreplica wachten, past de secundaire replica de resterende logboekrecords toe om het doorsturen van de secundaire databases te voltooien.

   Opmerking

   De hoeveelheid tijd die nodig is om het logboek toe te passen op een bepaalde database, is afhankelijk van de snelheid van het systeem, de recente werkbelasting en de hoeveelheid logboekregistratie in de herstelwachtrij.

3. De voormalige secundaire replica wordt overgezet naar de primaire rol. De databases worden de primaire databases. De nieuwe primaire replica draait alle niet-doorgevoerde transacties (de ongedaanmaakfase van herstel) zo snel mogelijk terug. Vergrendelingen isoleren deze niet-doorgevoerde transacties, waardoor ze op de achtergrond kunnen worden teruggedraaid terwijl klanten deze database gebruiken. Met dit proces worden geen vastgelegde transacties teruggedraaid.

   Totdat een bepaalde secundaire database is verbonden, wordt deze kort gemarkeerd als NOT_SYNCHRONIZED. Voordat het terugdraaien van het herstelproces wordt gestart, kunnen secundaire databases verbinding maken met de nieuwe primaire databases en snel overstappen naar de GESYNCHRONISEERDE status. Het beste geval is meestal voor een derde synchrone doorvoerreplica die na de failover in de secundaire rol blijft.

4. Later, wanneer het serverexemplaren waarop de voormalige primaire replica wordt gehost, opnieuw wordt opgestart, wordt herkend dat een andere beschikbaarheidsreplica nu eigenaar is van de primaire rol. De voormalige primaire replica gaat over naar de secundaire rol en de bijbehorende databases worden secundaire databases. De nieuwe secundaire replica maakt verbinding met de huidige primaire replica en haalt de database zo snel mogelijk op tot de huidige primaire databases. Zodra de nieuwe secundaire replica de databases opnieuw heeft gesynchroniseerd, is failover opnieuw mogelijk, in omgekeerde richting.

Automatische failover configureren

Een beschikbaarheidsreplica kan op elk gewenst moment worden geconfigureerd ter ondersteuning van automatische failover.

Het configureren van automatische failover

1. Zorg ervoor dat de secundaire replica is geconfigureerd voor het gebruik van de synchrone doorvoerbeschikbaarheidsmodus. Zie De beschikbaarheidsmodus van een beschikbaarheidsreplica (SQL Server) wijzigen voor meer informatie.

2. Stel de failovermodus in op automatisch. Zie De failovermodus van een beschikbaarheidsreplica (SQL Server) wijzigen voor meer informatie.

3. Wijzig desgewenst het flexibele failoverbeleid van de beschikbaarheidsgroep om de soorten fouten op te geven die een automatische failover kunnen veroorzaken. Zie Het flexibele failoverbeleid configureren voor het beheren van voorwaarden voor automatische failover (AlwaysOn-beschikbaarheidsgroepen) en failoverbeleid voor failoverclusterexemplaren voor meer informatie.

Geplande handmatige failover (zonder gegevensverlies)

Een handmatige failover zorgt ervoor dat een gesynchroniseerde secundaire replica wordt overgezet naar de primaire rol nadat een databasebeheerder een opdracht voor handmatige failover heeft uitgevoerd op het serverexemplaren waarop de secundaire doelreplica wordt gehost. Ter ondersteuning van handmatige failover moeten de secundaire replica en de huidige primaire replica beide worden geconfigureerd voor de synchrone doorvoermodus, indien van toepassing. Elke secundaire database op de beschikbaarheidsreplica moet worden gekoppeld aan de beschikbaarheidsgroep en gesynchroniseerd met de bijbehorende primaire database (dat wil wel dat de secundaire replica moet worden gesynchroniseerd). Dit garandeert dat elke transactie die is doorgevoerd op een voormalige primaire database ook is doorgevoerd in de nieuwe primaire database. Daarom zijn de nieuwe primaire databases identiek aan de oude primaire databases.

In de volgende afbeelding ziet u de fasen van een geplande failover:

1. Vóór failover wordt de primaire replica gehost door het serverexemplaar op Node01.

2. Een databasebeheerder initieert een geplande failover. Het failoverdoel is de beschikbaarheidsreplica die wordt gehost door het serverexemplaar op Node02.

3. Het failoverdoel (op Node02) wordt de nieuwe primaire replica. Omdat dit een geplande failover is, schakelt de voormalige primaire replica tijdens de failover over naar de secundaire rol en worden de databases onmiddellijk als secundaire databases online gebracht.

In deze sectie:

• Voorwaarden vereist voor een handmatige failover

• Hoe handmatige failover werkt

• Beschikbaarheid behouden tijdens upgrades

Voorwaarden vereist voor een handmatige failover

Ter ondersteuning van een handmatige failover moet de huidige primaire replica worden ingesteld op de synchrone doorvoermodus en moet een secundaire replica zijn:

• Geconfigureerd voor de synchrone doorvoermodus.

• Momenteel gesynchroniseerd met de primaire replica.

Als u handmatig een failover wilt uitvoeren voor een beschikbaarheidsgroep, moet u zijn verbonden met de secundaire replica die de nieuwe primaire replica moet worden.

Hoe een geplande handmatige failover werkt

Een geplande handmatige failover, die moet worden gestart op de secundaire doelreplica, initieert de volgende reeks acties:

1. Om ervoor te zorgen dat er geen nieuwe gebruikerstransacties plaatsvinden op de oorspronkelijke primaire databases, verzendt het WSFC-cluster een aanvraag naar de primaire replica om offline te gaan.

2. Als er een logboek in de herstelwachtrij van een secundaire database wacht, voltooit de secundaire replica het vooruitrollen van die secundaire database. De benodigde tijd is afhankelijk van de snelheid van het systeem, de recente werkbelasting en de hoeveelheid logboekregistratie in de herstelwachtrij. Als u de huidige grootte van de herstelwachtrij wilt leren, gebruikt u het prestatiemeteritem voor de herstelwachtrij . Zie SQL Server, Database Replica voor meer informatie.

   Opmerking

   De failovertijd kan worden geregeld door de grootte van de herstelwachtrij te beperken. Dit kan er echter toe leiden dat de primaire replica vertraagt, zodat de secundaire replica kan bijblijven.

3. De secundaire replica wordt de nieuwe primaire replica en de voormalige primaire replica wordt de nieuwe secundaire replica.

4. De nieuwe primaire replica draait alle niet-doorgevoerde transacties terug en brengt zijn databases online als de primaire databases. Alle secundaire databases worden kort gemarkeerd als NIET GESYNCHRONISEERD totdat ze verbinding maken en opnieuw synchroniseren met de nieuwe primaire databases. Met dit proces worden geen vastgelegde transacties teruggedraaid.

5. Wanneer de voormalige primaire replica weer online komt, krijgt deze de secundaire rol en wordt de voormalige primaire database de secundaire database. Met de nieuwe secundaire replica worden de nieuwe secundaire databases snel opnieuw gesynchroniseerd met de bijbehorende primaire databases.

   Opmerking

   Zodra de nieuwe secundaire replica de databases opnieuw heeft gesynchroniseerd, is failover opnieuw mogelijk, maar in omgekeerde richting.

Na een failover moeten clients opnieuw verbinding maken met de huidige primaire database. Zie Listeners voor beschikbaarheidsgroepen, clientconnectiviteit en toepassingsfailover (SQL Server) voor meer informatie.

Beschikbaarheid behouden tijdens upgrades

De databasebeheerder voor uw beschikbaarheidsgroepen kan handmatige failovers gebruiken om de beschikbaarheid van de database te behouden wanneer u hardware of software bijwerken. Als u een beschikbaarheidsgroep wilt gebruiken voor software-upgrades, moeten het serverexemplaar en/of computerknooppunt dat fungeert als host voor de beoogde secundaire replica al zijn geüpgraded. Zie AlwaysOn-replica-exemplaren voor beschikbaarheidsgroepen bijwerken voor meer informatie.

Geforceerde failover (met mogelijk gegevensverlies)

Het afdwingen van failover van een beschikbaarheidsgroep (met mogelijk gegevensverlies) is een methode voor herstel na noodgevallen waarmee u een secundaire replica kunt gebruiken als een warme stand-byserver. Omdat het afdwingen van failover mogelijk gegevensverlies veroorzaakt, moet deze voorzichtig en spaarzaam worden gebruikt. We raden u aan failover alleen af te dwingen als u de service onmiddellijk naar uw beschikbaarheidsdatabases moet herstellen en bereid bent om gegevens te verliezen. Zie Een geforceerde failover van een beschikbaarheidsgroep (SQL Server) uitvoeren voor meer informatie over de vereisten en aanbevelingen voor het afdwingen van failover en voor een voorbeeldscenario waarin een geforceerde failover wordt gebruikt om een onherstelbare fout te herstellen.

In deze sectie:

• Hoe geforceerde failover werkt

• Risico's van het afdwingen van failover

• Waarom geforceerde failover is vereist na het afdwingen van quorum

• Mogelijk gegevensverlies bijhouden

• Het potentiële gegevensverlies beheren

Hoe geforceerde failover werkt

Als u failover afdwingt, wordt een overgang van de primaire rol gestart naar een doelreplica waarvan de rol de secundaire of oplossingsstatus heeft. Het failoverdoel wordt de nieuwe primaire replica en dient onmiddellijk de kopieën van de databases naar clients. Wanneer de voormalige primaire replica beschikbaar komt, wordt deze overgezet naar de secundaire rol en worden de bijbehorende databases secundaire databases.

Alle secundaire databases (met inbegrip van de voormalige primaire databases, wanneer ze beschikbaar komen) worden ONDERBROKEN. Afhankelijk van de vorige status van gegevenssynchronisatie van een onderbroken secundaire database, is deze mogelijk geschikt voor het opslaan van ontbrekende vastgelegde gegevens voor die primaire database. Op een secundaire replica die is geconfigureerd voor alleen-lezentoegang, kunt u een query uitvoeren op de secundaire databases om ontbrekende gegevens handmatig te detecteren. Vervolgens kunt u Transact-SQL verklaringen opstellen voor de nieuwe primaire databases om de benodigde wijzigingen door te voeren.

Risico's van het afdwingen van failover

Het is essentieel om te begrijpen dat het afdwingen van failover gegevensverlies kan veroorzaken. Gegevensverlies is mogelijk omdat de doelreplica niet kan communiceren met de primaire replica en daarom niet kan garanderen dat de databases worden gesynchroniseerd. Als u failover afdwingt, wordt een nieuwe herstelfork gestart. Omdat de oorspronkelijke primaire databases en secundaire databases zich op verschillende herstel forks bevinden, bevat elk van deze databases nu gegevens die de andere database niet bevat: elke oorspronkelijke primaire database bevat alle wijzigingen die nog niet zijn verzonden vanuit de verzendwachtrij naar de voormalige secundaire database (het niet-verzonden logboek); de voormalige secundaire databases bevatten alle wijzigingen die zich voordoen nadat de failover is geforceerd.

Als failover wordt afgedwongen omdat de primaire replica is mislukt, is mogelijk gegevensverlies afhankelijk van of er vóór de fout transactielogboeken naar de secundaire replica zijn verzonden. Onder de asynchrone doorvoermodus is het verzamelen van niet-verzonden logboeken altijd een mogelijkheid. Onder de synchrone doorvoermodus is dit alleen mogelijk totdat de secundaire databases worden gesynchroniseerd.

De volgende tabel bevat een overzicht van de mogelijkheid van gegevensverlies voor een bepaalde database op de replica waarop u failover forceert.

Secundaire databases volgen slechts twee herstel forks, dus als u meerdere geforceerde failovers uitvoert, kan een secundaire database die gegevenssynchronisatie met de vorige geforceerde failover heeft gestart, mogelijk niet hervatten. Als dit het geval is, moeten secundaire databases die niet kunnen worden hervat, worden verwijderd uit de beschikbaarheidsgroep, hersteld naar het juiste tijdstip en opnieuw deelnemen aan de beschikbaarheidsgroep. Fout 1408 met status 103 kan in dit scenario worden waargenomen (fout: 1408, ernst: 16, status: 103). Een herstelbewerking werkt niet voor meerdere herstel forks. Zorg er daarom voor dat u een logboekback-up uitvoert nadat u meerdere geforceerde failovers hebt uitgevoerd.

Waarom geforceerde failover is vereist na het afdwingen van quorum

Nadat quorum is afgedwongen op het WSFC-cluster (geforceerd quorum), moet u een geforceerde failover uitvoeren (met mogelijk gegevensverlies) voor elke beschikbaarheidsgroep. De geforceerde failover is vereist omdat de werkelijke status van de WSFC-clusterwaarden mogelijk verloren is gegaan. Voorkomen van normale failovers na een geforceerd quorum is vereist vanwege de mogelijkheid dat een niet-gesynchroniseerde secundaire replica lijkt te worden gesynchroniseerd op het opnieuw geconfigureerde WSFC-cluster.

Denk bijvoorbeeld aan een WSFC-cluster dat als host fungeert voor een beschikbaarheidsgroep op drie knooppunten: Knooppunt A fungeert als host voor de primaire replica en Knooppunt B en Knooppunt C elke host als host voor een secundaire replica. Knooppunt C wordt losgekoppeld van het WSFC-cluster terwijl de lokale secundaire replica is GESYNCHRONISEERD. Maar knooppunt A en knooppunt B behouden een goed functionerend quorum en de beschikbaarheidsgroep blijft online. Op knooppunt A blijft de primaire replica updates accepteren en op knooppunt B blijft de secundaire replica synchroniseren met de primaire replica. De secundaire replica op Node C wordt niet-gesynchroniseerd en valt steeds meer achter de primaire replica. Omdat knooppunt C echter niet is verbonden, blijft de replica onjuist in de status GESYNCHRONISEERD.

Als het quorum verloren gaat en vervolgens wordt afgedwongen op knooppunt A, moet de synchronisatiestatus van de beschikbaarheidsgroep op het WSFC-cluster correct zijn, waarbij de secundaire replica op knooppunt C wordt weergegeven als UNSYNCHRONIZED. Als quorum echter wordt afgedwongen op Node C, is de synchronisatie van de beschikbaarheidsgroep onjuist. De synchronisatiestatus van het cluster is teruggezet naar het moment waarop knooppunt C is losgekoppeld en de secundaire replica op knooppunt C onjuist wordt weergegeven als GESYNCHRONISEERD. Omdat geplande handmatige failovers de veiligheid van de gegevens garanderen, is het niet toegestaan een beschikbaarheidsgroep weer online te brengen nadat het quorum is afgedwongen.

Mogelijk gegevensverlies bijhouden

Wanneer het WSFC-cluster een goed quorum heeft, kunt u een schatting maken van het huidige potentieel voor gegevensverlies op databases. Voor een bepaalde secundaire replica is het huidige potentieel voor gegevensverlies afhankelijk van hoe ver de lokale secundaire databases achterblijven bij de bijbehorende primaire databases. Omdat de vertraging in de loop van de tijd varieert, raden we u aan om periodiek mogelijk gegevensverlies bij te houden voor uw niet-gesynchroniseerde secundaire databases. Het bijhouden van vertraging omvat het vergelijken van de LSN van laatste doorvoer en de laatste doorvoertijd voor elke primaire database en de secundaire databases, als volgt:

1. Maak verbinding met de primaire replica.

2. Voer een query uit op de last_commit_lsn (LSN van de laatste doorgevoerde transactie) en last_commit_time kolommen (tijd van de laatste doorvoering) van de sys.dm_hadr_database_replica_states dynamische beheerweergave.

3. Vergelijk de waarden die worden geretourneerd voor elke primaire database en elk van de secundaire databases. Het verschil tussen hun laatste commit LSN's geeft de hoeveelheid vertraging aan.

4. U kunt een waarschuwing activeren wanneer de hoeveelheid vertraging in een database of set databases de gewenste maximale vertraging voor een bepaalde periode overschrijdt. De query kan bijvoorbeeld worden uitgevoerd door een taak die elke minuut op elke primaire database wordt uitgevoerd. Als het verschil tussen de last_commit_time van een primaire database en een van de secundaire databases het beoogde herstelpunt (RPO) (bijvoorbeeld vijf minuten) heeft overschreden sinds de laatste keer dat de taak is uitgevoerd, kan de taak een waarschuwing genereren.

Het potentiële gegevensverlies beheren

Nadat de failover is afgedwongen, worden alle secundaire databases geschorst. Dit omvat de voormalige primaire databases, nadat de voormalige primaire replica weer online is en vaststelt dat deze nu een secundaire replica is. U moet elke onderbroken database handmatig afzonderlijk hervatten op elke secundaire replica.

Zodra de voormalige primaire replica beschikbaar is, ervan uitgaande dat de databases onbeschadigd zijn, kunt u proberen het potentiële gegevensverlies te beheren. De beschikbare benadering voor het beheren van potentieel gegevensverlies is afhankelijk van of de oorspronkelijke primaire replica is verbonden met de nieuwe primaire replica. Ervan uitgaande dat de oorspronkelijke primaire replica toegang heeft tot het nieuwe primaire exemplaar, wordt automatisch en transparant opnieuw verbinding gemaakt.

De oorspronkelijke primaire replica is opnieuw verbonden

Normaal gesproken, wanneer de oorspronkelijke primaire replica na een fout opnieuw wordt opgestart, wordt deze snel opnieuw verbonden met de partner. Bij het opnieuw verbinden wordt de oorspronkelijke primaire replica de secundaire replica. De databases worden de secundaire databases en voeren de status SUSPENDED in. De nieuwe secundaire databases worden niet teruggedraaid, tenzij u ze hervat.

De onderbroken databases zijn echter niet toegankelijk, dus u kunt ze niet inspecteren om te evalueren welke gegevens verloren zouden gaan als u een bepaalde database zou hervatten. Daarom is de beslissing over het hervatten of verwijderen van een secundaire database afhankelijk van of u bereid bent gegevensverlies te accepteren, als volgt:

• Als het verlies van gegevens onaanvaardbaar is, moet u de databases uit de beschikbaarheidsgroep verwijderen om ze te redden.

  De databasebeheerder kan nu de voormalige primaire databases herstellen en proberen de gegevens te herstellen die verloren zouden zijn gegaan. Wanneer een voormalige primaire database echter online komt, wijkt deze af van de huidige primaire database, dus moet de databasebeheerder de verwijderde database of de huidige primaire database niet toegankelijk maken voor clients om verdere verschillen van de databases te voorkomen en problemen met clientfailover te voorkomen.

• Als het verlies van gegevens acceptabel is voor uw bedrijfsdoelen, kunt u de secundaire databases hervatten.

  Als u een nieuwe secundaire database hervat, wordt deze teruggedraaid als eerste stap bij het synchroniseren van de database. Als er logboekrecords in de verzendwachtrij stonden op het moment van de fout, gaan de bijbehorende transacties verloren, zelfs als ze zijn bevestigd.

De oorspronkelijke primaire replica is niet opnieuw verbonden

Als u tijdelijk kunt voorkomen dat de oorspronkelijke primaire replica opnieuw verbinding maakt via het netwerk met de nieuwe primaire replica, kunt u de oorspronkelijke primaire databases controleren om te evalueren welke gegevens verloren gaan als ze worden hervat.

• Als het potentiële gegevensverlies acceptabel is

  Toestaan dat de oorspronkelijke primaire replica opnieuw verbinding maakt met de nieuwe primaire replica. Wanneer opnieuw verbinding wordt gemaakt, worden de nieuwe secundaire databases gepauzeerd. Als u gegevenssynchronisatie in een database wilt starten, kunt u deze gewoon hervatten. De nieuwe secundaire replica verwijdert de oorspronkelijke herstelfork voor die database, waardoor transacties verloren gaan die nooit zijn verzonden naar of ontvangen door de voormalige secundaire replica.

• Als het gegevensverlies onaanvaardbaar is

  Als de oorspronkelijke primaire database kritieke gegevens bevat die verloren gaan als u de onderbroken database hervat, kunt u de gegevens op de oorspronkelijke primaire database behouden door deze uit de beschikbaarheidsgroep te verwijderen. Dit zorgt ervoor dat de database de status HERSTELLEN invoert. Op dit moment raden wij u aan een back-up te maken van het laatste deel van de logbestand van de verwijderde database. Vervolgens kunt u de huidige primaire (de voormalige secundaire database) bijwerken door de gegevens te exporteren die u wilt opslaan uit de oorspronkelijke primaire database en deze te importeren in de huidige primaire database. U wordt aangeraden zo snel mogelijk een volledige databaseback-up van de bijgewerkte primaire database te maken.

  Vervolgens kunt u op de serverinstantie waarop de nieuwe secundaire replica wordt gehost, de onderbroken secundaire database verwijderen en een nieuwe secundaire database maken door deze back-up te herstellen (met ten minste één daaropvolgende logboekback-up) met RESTORE WITH NORECOVERY. Het is raadzaam om extra logboekback-ups van de huidige primaire databases uit te stellen totdat de bijbehorende secundaire databases worden hervat.

Verwante inhoud

• overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
• Beschikbaarheidsmodi (Always On-beschikbaarheidsgroepen)
• Windows Server Failover Clustering (WSFC) met SQL Server
• Transacties tussen databases en gedistribueerde transacties voor AlwaysOn-beschikbaarheidsgroepen en databasespiegeling (SQL Server)
• Failoverbeleid voor exemplaren van failoverclusters
• Flexibel failoverbeleid voor automatische failover van een beschikbaarheidsgroep (SQL Server)

Gerelateerde taken

Failovergedrag configureren

• De beschikbaarheidsmodus van een Availability Replica (SQL Server) wijzigen
• De failovermodus van een Availability Replica in SQL Server wijzigen
• het beleid voor flexibele failover configureren voor het beheren van voorwaarden voor automatische failover (AlwaysOn-beschikbaarheidsgroepen)

Handmatige failover uitvoeren

• een geplande handmatige failover van een beschikbaarheidsgroep (SQL Server) uitvoeren
• een geforceerde handmatige failover van een beschikbaarheidsgroep (SQL Server) uitvoeren
• Gebruik de Wizard Failover-Beschikbaarheidsgroepen (SQL Server Management Studio)
• Beheer van aanmeldingen en taken voor de databases van een beschikbaarheidsgroep (SQL Server)

Configuratie van WSFC-quorum configureren

• Cluster Quorum knooppuntgewicht instellingen configureren
• clusterquorumknooppuntgewichtinstellingen weergeven
• Dwing een WSFC-cluster te starten zonder quorum