Delen via

Verschillen tussen beschikbaarheidsmodi voor een AlwaysOn-beschikbaarheidsgroep

van toepassing op:SQL Server-

In AlwaysOn-beschikbaarheidsgroepen is de beschikbaarheidsmodus een replica-eigenschap die bepaalt of een bepaalde beschikbaarheidsreplica kan worden uitgevoerd in de synchrone doorvoermodus. Voor elke beschikbaarheidsreplica moet de beschikbaarheidsmodus worden geconfigureerd voor de synchrone doorvoermodus, asynchrone doorvoer of alleen configuratiemodus.

Als de primaire replica is geconfigureerd voor de asynchrone doorvoermodus, wacht deze niet totdat een secundaire replica binnenkomende transactielogboekrecords naar schijf schrijft (om het logboek te beveiligen).

Als een bepaalde secundaire replica is ingesteld op de asynchrone commit-modus, wacht de primaire replica niet tot die secundaire replica het logboek heeft beveiligd. Als zowel de primaire replica als een bepaalde secundaire replica zijn geconfigureerd voor de synchrone doorvoermodus, wacht de primaire replica totdat de secundaire replica bevestigt dat het logboek is versterkt (tenzij de secundaire replica de primaire replica niet kan bereiken binnen de sessietime-outperiode van de primaire replica).

Opmerking

Als een secundaire replica met synchrone doorvoer de sessietime-outperiode van de primaire replica overschrijdt (de standaardwaarde is 10 seconden), markeert de primaire replica tijdelijk de synchronisatiestatus van elke database op deze secundaire replica als NOT SYNCHRONIZING en de replicastatus als NOT_HEALTHY. Wanneer de secundaire replica opnieuw verbinding maakt met de primaire replica, wordt de modus voor synchrone bevestiging hervat.

Ondersteunde beschikbaarheidsmodi

AlwaysOn-beschikbaarheidsgroepen ondersteunen drie beschikbaarheidsmodi:

  • Asynchrone doorvoermodus
  • Synchrone transactie modus
  • Alleen configuratiemodus

De Asynchrone doorvoermodus is een oplossing voor herstel na noodgevallen die goed werkt wanneer de beschikbaarheidsreplica's over aanzienlijke afstanden worden verdeeld. Als elke secundaire replica in de asynchrone toezeggingsmodus draait, wacht de primaire replica niet tot een van de secundaire replica's het logboek heeft verhard. In plaats daarvan verzendt de primaire replica direct na het schrijven van de logboekrecord naar het lokale logboekbestand de transactiebevestiging naar de client. De primaire replica wordt uitgevoerd met minimale transactielatentie ten opzichte van een secundaire replica die is geconfigureerd voor de asynchrone doorvoermodus.

Als de huidige primaire is geconfigureerd voor de asynchrone doorvoerbeschikbaarheidsmodus, worden transacties asynchroon doorgevoerd voor alle secundaire replica's, ongeacht hun instellingen voor de afzonderlijke beschikbaarheidsmodus.

Zie Asynchronous-Commit beschikbaarheidsmodus verderop in dit artikel voor meer informatie.

De synchrone doorvoermodus benadrukt hoge beschikbaarheid ten opzichte van prestaties, ten koste van een verhoogde transactielatentie. In de synchrone bevestigingsmodus wachten transacties met het verzenden van de transactiebevestiging naar de client totdat de secundaire replica het logboek naar de schijf heeft weggeschreven. Wanneer gegevenssynchronisatie op een secundaire database begint, begint de secundaire replica met het toepassen van binnenkomende logboekrecords uit de bijbehorende primaire database. Zodra elke logboekrecord is gehard, voert de secundaire database de SYNCHRONIZED status in. Daarna wordt elke nieuwe transactie beveiligd door de secundaire replica voordat de logboekrecord naar het lokale logboekbestand wordt geschreven. Wanneer alle secundaire databases van een bepaalde secundaire replica worden gesynchroniseerd, ondersteunt de synchrone doorvoermodus handmatige failover en, optioneel, automatische failover.

Zie Synchronous-Commit beschikbaarheidsmodus verderop in dit artikel voor meer informatie.

De configuratiemodus is alleen van toepassing op beschikbaarheidsgroepen die zich niet in een Windows Server-failovercluster bevinden. Een replica in de configuratiemodus bevat geen gebruikersgegevens. Alleen in de configuratiemodus slaat de database-replica master metadata van de beschikbaarheidsgroep op. Zie Hoge beschikbaarheid en gegevensbeveiliging voor configuraties van beschikbaarheidsgroepenvoor meer informatie.

In de volgende afbeelding ziet u een beschikbaarheidsgroep met vijf beschikbaarheidsreplica's. De primaire replica en één secundaire replica zijn geconfigureerd voor de synchrone doorvoermodus met automatische failover. Een andere secundaire replica is geconfigureerd voor de synchrone doorvoermodus met alleen geplande handmatige failover en twee secundaire replica's zijn geconfigureerd voor de asynchrone doorvoermodus, die alleen geforceerde handmatige failover ondersteunt (meestal geforceerde failover genoemd).

Diagram van beschikbaarheids- en failovermodi van replica's.

Het synchronisatie- en failovergedrag tussen twee beschikbaarheidsreplica's is afhankelijk van de beschikbaarheidsmodus van beide replica's. Voor synchrone doorvoer moet bijvoorbeeld zowel de primaire replica als de secundaire replica worden geconfigureerd voor synchrone doorvoer. Voor automatische failover moeten beide replica's ook worden geconfigureerd voor automatische failover. Daarom kan het gedrag voor het eerder geïllustreerde implementatiescenario worden samengevat in de volgende tabel, waarmee het gedrag wordt verkend met elke potentiële primaire replica:

Huidige primaire replica De automatische failoverdoelen Gedrag van synchrone commit-modus met Het gedrag van de Asynchroon-bevestigingsmodus met Automatische failover mogelijk
01 02 02 en 03 04 Ja
02 01 01 en 03 04 Ja
03 01 en 02 04 Nee.
04 01, 02 en 03 Nee.

Node 04, als asynchrone-commit replica, wordt doorgaans ingezet op een locatie voor herstel na noodsituaties. Het feit dat knooppunten 01, 02 en 03 in de asynchrone doorvoermodus blijven na een failover naar Node 04, helpt potentiële prestatievermindering in uw beschikbaarheidsgroep te voorkomen vanwege een hoge netwerklatentie tussen de twee sites.

Beschikbaarheidsmodus voor asynchrone doorvoer

Onder de asynchrone doorvoermodus wordt de secundaire replica nooit gesynchroniseerd met de primaire replica. Hoewel een bepaalde secundaire database de bijbehorende primaire database kan inhalen, kan elke secundaire database op elk moment achterblijven. De asynchrone doorvoermodus kan handig zijn in een scenario voor herstel na noodgevallen waarin de primaire replica en de secundaire replica worden gescheiden door een aanzienlijke afstand en waar u geen kleine fouten wilt die van invloed zijn op de primaire replica of in situaties waarin prestaties belangrijker zijn dan gesynchroniseerde gegevensbeveiliging. Omdat de primaire replica niet wacht op bevestigingen van de secundaire replica, hebben problemen op de secundaire replica nooit invloed op de primaire replica.

Een secundaire replica met een asynchrone commit probeert bij te blijven met de logboekrecords die zijn ontvangen van de primaire replica. Maar secundaire databases met asynchrone doorvoer blijven altijd niet-gesynchroniseerd en lopen waarschijnlijk enigszins achter bij de bijbehorende primaire databases. Meestal is de kloof tussen een secundaire database met asynchrone doorvoer en de bijbehorende primaire database klein. Maar de kloof kan aanzienlijk worden als de server die als host fungeert voor de secundaire replica overbelasting of het netwerk traag is.

De enige vorm van failover die wordt ondersteund door de asynchrone doorvoermodus, is geforceerde failover (met mogelijk gegevensverlies). Failover afdwingen is een laatste redmiddel dat alleen bedoeld is voor situaties waarin de huidige primaire replica gedurende een langere periode niet beschikbaar blijft en de onmiddellijke beschikbaarheid van primaire databases belangrijker is dan het risico op mogelijk gegevensverlies. Het failoverdoel moet een replica zijn waarvan de rol zich in de status SECONDARY of RESOLVING bevindt. Het failoverdoel gaat over naar de primaire rol en de kopieën van de databases worden de primaire database. Alle resterende secundaire databases, samen met de voormalige primaire databases, worden onderbroken totdat u ze handmatig afzonderlijk hervat. Onder de asynchrone doorvoermodus gaan transactielogboeken die de oorspronkelijke primaire replica nog niet naar de voormalige secundaire replica had verzonden, verloren. Dit betekent dat sommige of alle nieuwe primaire databases mogelijk niet recent vastgelegde transacties bevatten. Zie Failover en Failovermodi (Always On-beschikbaarheidsgroepen) voor meer informatie over hoe een geforceerde failover werkt en over de beste praktijken voor het gebruik ervan.

Beschikbaarheidsmodus voor synchrone doorvoer

Onder de synchrone-commitbeschikbaarheidsmodus (synchrone-commitmodus), nadat deze is toegevoegd aan een beschikbaarheidsgroep, wordt een secundaire database bijgewerkt aan de bijbehorende primaire database en gaat naar de SYNCHRONIZED status. De secundaire database blijft SYNCHRONIZED zolang de gegevenssynchronisatie wordt voortgezet. Dit garandeert dat elke transactie die is doorgevoerd op een bepaalde primaire database, wordt doorgevoerd in de bijbehorende secundaire database. Wanneer elke secundaire database op een bepaalde secundaire replica wordt gesynchroniseerd, is de synchronisatiestatus van de gezondheid van de secundaire replica als geheel HEALTHY.

In deze sectie:

Factoren die gegevenssynchronisatie verstoren

Zodra alle databases zijn gesynchroniseerd, voert een secundaire replica de HEALTHY status in. De gesynchroniseerde secundaire replica blijft in orde, tenzij een van de volgende gebeurtenissen plaatsvindt:

  • Een netwerk- of computervertraging of -storing zorgt ervoor dat de sessie tussen de secundaire replica en de primaire replica verloopt met een time-out.

    Opmerking

    Zie Wat is een AlwaysOn-beschikbaarheidsgroep voor informatie over de eigenschap sessietijd van beschikbaarheidsreplica's?

  • U onderbreekt een secundaire database op de secundaire replica. De secundaire replica wordt niet meer gesynchroniseerd en de synchronisatiestatus wordt gemarkeerd als NOT_HEALTHY. De secundaire replica kan pas weer gezond worden nadat de onderbroken secundaire database ofwel is hervat en opnieuw gesynchroniseerd, of verwijderd uit de beschikbaarheidsgroep.

  • U voegt een primaire database toe aan de beschikbaarheidsgroep. Eerder gesynchroniseerde secundaire replica's voeren de status van de NOT_HEALTHY synchronisatiestatus in. Deze status geeft aan dat ten minste één database de NOT SYNCHRONIZING synchronisatiestatus heeft. Een bepaalde secundaire replica kan niet opnieuw HEALTHY worden totdat een corresponderende secundaire database is voorbereid op de replica, is aangesloten bij de beschikbaarheidsgroep en is gesynchroniseerd met de nieuwe primaire database.

  • U wijzigt de primaire of secundaire replica naar de beschikbaarheidsmodus asynchroon bevestigen. Nadat de secundaire replica is overgezet naar de asynchrone doorvoermodus, blijft de synchronisatiegezondheidsstatus van de HEALTHY behouden zolang de gegevenssynchronisatie doorgaat. Als echter alleen de primaire replica wordt gewijzigd in de asynchrone-commit-modus, komt de synchrone-commit secundaire replica in de PARTIALLY_HEALTHY synchronisatiegezondheidsstatus terecht. Deze status geeft aan dat ten minste één database de SYNCHRONIZING synchronisatiestatus heeft, maar dat geen van de databases de NOT SYNCHRONIZING status heeft.

  • Je wijzigt een secundaire replica naar synchroon-commit beschikbaarheidsmodus. Dit zorgt ervoor dat de secundaire replica wordt gemarkeerd als in de PARTIALLY_HEALTHY synchronisatie-/gezondheidsstatus totdat al zijn databases zich in de SYNCHRONIZED synchronisatiestatus bevinden.

Hint

Als u de synchronisatiestatus van een beschikbaarheidsgroep, beschikbaarheidsreplica of beschikbaarheidsdatabase wilt weergeven, voert u respectievelijk een query uit op de synchronization_health of synchronization_health_desc kolom van sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states of sys.dm_hadr_database_replica_states.

Hoe synchronisatie werkt op een secundaire replica

Nadat een secundaire replica is toegevoegd aan de beschikbaarheidsgroep in de synchrone commitmodus en een sessie met de primaire replica tot stand heeft gebracht:

  1. De secundaire replica schrijft binnenkomende logboekrecords naar schijf (behard het logboek).
  2. De secundaire replica verzendt een bevestigingsbericht naar de primaire replica.

Nadat het verharde logboek op de secundaire database heeft bijgehouden tot het einde van het logboek van de primaire database, wordt de status van de secundaire database ingesteld op SYNCHRONIZED.

De tijd die nodig is voor synchronisatie, is afhankelijk van hoe ver de secundaire database zich aan het begin van de sessie achter de primaire database bevond. Deze delta wordt gemeten door het aantal logboekrecords dat oorspronkelijk is ontvangen van de primaire replica, de werkbelasting van de primaire database en de snelheid van de instantiehost van de secundaire replica.

Het transactieproces

In de synchrone doorvoermodus worden transacties in deze volgorde doorgevoerd naar beide replica's:

  1. De primaire replica ontvangt een transactie van een client.

  2. De primaire replica schrijft de record naar het transactielogboek en verzendt de logboekrecord gelijktijdig naar de secundaire replica's.

    Zodra een logboekrecord naar het transactielogboek van de primaire database is geschreven, kan de transactie alleen ongedaan worden gemaakt als er een failover naar een secundaire database is die het logboek niet heeft ontvangen.

  3. De primaire replica wacht op bevestiging van de secundaire replica met synchrone commit.

  4. De secundaire replica verhardt het logboek en retourneert een bevestiging aan de primaire replica.

  5. De primaire replica voltooit de doorvoerverwerking en stuurt een bevestigingsbericht naar de client.

Time-out voor synchrone bevestiging

Als een secundaire replica met synchrone-commit een time-out heeft zonder te bevestigen dat het logboek is gehard, worden de volgende acties uitgevoerd in de beschikbaarheidsgroep:

  1. De primaire kopie beschouwt de secundaire kopie als mislukt.
  2. De secundaire replicastatus wordt gewijzigd in DISCONNECTED.
  3. De primaire bron stopt met wachten op bevestiging.
  4. De beschikbaarheidsgroep markeert de synchronisatiestatus als NOT SYNCHRONIZING en de replicastatus als NOT_HEALTHY.

Dit gedrag zorgt ervoor dat een gefaalde synchrone-commit secundaire replica de logversterking op de primaire replica niet verhindert.

Wanneer de secundaire replica weer online is:

  1. De secundaire replicastatus wordt gewijzigd in CONNECTED.
  2. De secundaire replica verwerkt de log-verzendwachtrij van de primaire replica.
  3. De synchronisatiestatus gaat over naar SYNCHRONIZINGen de status van de replica naar PARTIALLY_HEALTHY.

Nadat de wachtrij voor het verzenden van logboeken is verwerkt, verandert de synchronisatiestatus naar SYNCHRONIZED en de replica naar HEALTHY.

De synchrone doorvoermodus beveiligt uw gegevens door te vereisen dat de gegevens tussen twee locaties worden gesynchroniseerd, ten koste van een enigszins toenemende latentie van de transactie.

Synchrone doorvoermodus met alleen handmatige failover

Wanneer deze replica's zijn verbonden en de database wordt gesynchroniseerd, wordt handmatige failover ondersteund. Als de secundaire replica uitvalt, wordt de primaire replica niet beïnvloed. De primaire replica wordt weergegeven als er geen SYNCHRONIZED replica's bestaan (dat wil gezegd, zonder gegevens naar een secundaire replica te verzenden). Als de primaire replica verloren gaat, voeren de secundaire replica's de RESOLVING status in, maar kan de eigenaar van de database een failover naar de secundaire replica afdwingen (met mogelijk gegevensverlies). Zie failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

Synchroon commit-modus met automatische failover

Automatische failover biedt hoge beschikbaarheid door ervoor te zorgen dat de database snel weer beschikbaar wordt gemaakt na het verlies van de primaire replica. Als u een beschikbaarheidsgroep wilt configureren voor automatische failover, moet u zowel de huidige primaire replica als ten minste één secundaire replica instellen op de modus synchrone doorvoer met automatische failover. SQL Server 2019 (15.x) heeft het maximum aantal synchrone replica's verhoogd naar 5, tot 3 in SQL Server 2017 (14.x). U kunt deze groep van vijf replica's configureren voor automatische failover binnen de groep. Er is één primaire replica, plus vier synchrone secundaire replica's.

Bovendien moet deze secundaire replica op een bepaald moment worden gesynchroniseerd met de primaire replica (dat wil zeggen dat de secundaire databases allemaal worden gesynchroniseerd), en moet het WSFC-cluster (Windows Server Failover Clustering) quorum hebben. Als de primaire replica onder deze voorwaarden niet meer beschikbaar is, vindt automatische failover plaats. De secundaire replica schakelt over naar de rol van primair en biedt de database aan als primaire database. Zie de sectie Automatische failover van het artikel Failover- en Failovermodi (AlwaysOn-beschikbaarheidsgroepen) voor meer informatie.

Opmerking

Zie WSFC-quorummodi en stemconfiguratie (SQL Server) voor meer informatie over WSFC-quorummodi en AlwaysOn-beschikbaarheidsgroepen.

Gegevenslatentie op secundaire replica

Het implementeren van alleen-lezentoegang tot secundaire replica's is nuttig als uw alleen-lezen workloads enige gegevenslatentie kunnen verdragen. In situaties waarin gegevenslatentie onaanvaardbaar is, kunt u overwegen om alleen-lezenworkloads uit te voeren op de primaire replica.

De primaire replica verzendt logboekrecords met wijzigingen op de primaire database naar de secundaire replica's. Op elke secundaire database past een speciale redo-thread de logboekrecords toe. In een secundaire database met leestoegang wordt een bepaalde gegevenswijziging pas weergegeven in queryresultaten als de logboekrecord met de wijziging is toegepast op de secundaire database en de transactie is doorgevoerd in de primaire database.

Dit betekent dat er enige latentie is, meestal slechts een kwestie van seconden, tussen de primaire en secundaire replica's. In ongebruikelijke gevallen kan de latentie echter aanzienlijk worden als netwerkproblemen de doorvoer verminderen. Latentie neemt toe wanneer I/O-knelpunten optreden en wanneer gegevensverplaatsing wordt onderbroken. Als u de onderbroken gegevensverplaatsing wilt bewaken, kunt u het dashboard AlwaysOn-beschikbaarheidsgroep (SQL Server Management Studio) of de sys.dm_hadr_database_replica_states dynamische beheerweergave gebruiken.

Als u de latentie in SQL Server 2025 (17.x) Preview en latere versies wilt verminderen, kunt u de tijd (in milliseconden) beperken die de primaire replica nodig heeft om transacties door te voeren naar de secundaire replica. Zie Serverconfiguratie: doorvoertijd voor beschikbaarheidsgroepen (ms) voor meer informatie.

De beschikbaarheidsmodus en failovermodus wijzigen

Quorumstemmen aanpassen

Een handmatige failover uitvoeren

Beschikbaarheidsgroep, beschikbaarheidsreplica en databasestatussen weergeven

Verwante inhoud