Delen via

Een geforceerde handmatige failover uitvoeren van een AlwaysOn-beschikbaarheidsgroep (SQL Server)

  • Artikel

van toepassing op:SQL Server-

In dit onderwerp wordt beschreven hoe u een geforceerde failover (met mogelijk gegevensverlies) uitvoert op een AlwaysOn-beschikbaarheidsgroep met behulp van SQL Server Management Studio, Transact-SQL of PowerShell in SQL Server. Een geforceerde failover is een vorm van handmatige failover die strikt bedoeld is voor herstel na noodgevallen, wanneer een geplande handmatige failover niet mogelijk is. Als u een failover afdwingt naar een niet-gesynchroniseerde secundaire replica, kan enig gegevensverlies optreden. Daarom raden we u ten zeerste aan om failover alleen af te dwingen als u de service onmiddellijk naar de beschikbaarheidsgroep moet herstellen en u bereid bent om gegevens te verliezen.

Na een geforceerde failover wordt het failoverdoel waarnaar de beschikbaarheidsgroep is overgeschakeld, de nieuwe primaire replica. De secundaire databases in de resterende secundaire replica's zijn gepauzeerd en moeten handmatig hervat worden. Wanneer de voormalige primaire replica beschikbaar is, gaat deze over naar de secundaire rol, waardoor de voormalige primaire databases secundaire databases worden en in de status ONDERBROKEN terechtkomen. Voordat u een bepaalde secundaire database hervat, kunt u mogelijk verloren gegevens herstellen. U ziet echter dat het trunceren van transactielogboeken wordt vertraagd op een bepaalde primaire database terwijl een van de secundaire databases is geschorst.

Belangrijk

Gegevenssynchronisatie met de primaire database vindt pas plaats als de secundaire database wordt hervat. Zie Opvolgen: Essentiële taken na een geforceerde failover verderop in dit artikel voor meer informatie over het hervatten van een secundaire database.

Het uitvoeren van een geforceerde failover is nodig in de volgende noodsituaties:

  • Nadat u quorum hebt afgedwongen op het WSFC-cluster (geforceerde quorum), moet u failover per beschikbaarheidsgroep afdwingen (met mogelijk gegevensverlies). Het afdwingen van failover is vereist omdat de werkelijke status van de WSFC-clusterwaarden mogelijk verloren is gegaan. U kunt echter gegevensverlies voorkomen als u failover kunt afdwingen op het serverexemplaar dat de primaire replica hostte voordat u quorum afdwingen, of naar een secundaire replica die vóór het quorum afdwingen werd gesynchroniseerd. Zie Mogelijke manieren om gegevensverlies te voorkomen nadat quorum is geforceerdverderop in dit onderwerp voor meer informatie.

    Belangrijk

    Als het quorum door natuurlijke middelen wordt hersteld in plaats van geforceerd te worden, zullen de beschikbaarheidsreplica's via het normale herstelproces worden hersteld. Als de primaire replica nog steeds niet beschikbaar is nadat het quorum is hersteld, kunt u een geplande handmatige failover uitvoeren naar een gesynchroniseerde secundaire replica.

    Voor meer informatie over het afdwingen van quorum, zie WSFC Disaster Recovery met een geforceerd quorum (SQL Server). Voor informatie over waarom het forceren van failover is vereist na het forceren van quorum, zie failover en failovermodi (Always On-beschikbaarheidsgroepen).

  • Als de primaire replica niet meer beschikbaar is wanneer het WSFC-cluster een gezond quorum heeft, kunt u een geforceerde failover uitvoeren (met mogelijk gegevensverlies) naar elke replica waarvan de rol de status SECUNDAIR of IN OPLOSSING heeft. Indien mogelijk, dwing failover af naar een synchrone commit secundaire replica die gesynchroniseerd was op het moment dat de primaire replica verloren ging.

    Tip

    Wanneer het WSFC-cluster een goed functionerend quorum heeft, voert de replica een geplande handmatige failover uit als u een opdracht voor een geforceerde failover uitvoert op een gesynchroniseerde secundaire replica.

Notitie

Zie voor meer informatie over de vereisten en aanbevelingen voor het afdwingen van failover en voor een voorbeeldscenario dat gebruikmaakt van een geforceerde failover om te herstellen van een catastrofale fout, voorbeeldscenario: een geforceerde failover gebruiken om te herstellen van een onherstelbare foutverderop in dit onderwerp.

Beperkingen en beperkingen

  • De enige keer dat u geen geforceerde failover kunt uitvoeren, is wanneer het WSFC-cluster (Windows Server Failover Clustering) geen quorum heeft.

  • Gegevensverlies is mogelijk tijdens de geforceerde failover van een beschikbaarheidsgroep. Als de primaire replica wordt uitgevoerd wanneer u een geforceerde failover start, zijn clients mogelijk nog steeds verbonden met voormalige primaire databases. Daarom raden we u ten zeerste aan om failover alleen af te dwingen als de primaire replica niet meer wordt uitgevoerd en als u bereid bent gegevens te verliezen om de toegang tot databases in de beschikbaarheidsgroep te herstellen.

  • Wanneer een secundaire database de status HERSTELLEN of INITIALISEREN heeft, kan het afdwingen van een failover ertoe leiden dat de database niet kan worden gestart als een primaire database. Als de database de status INITIALISEREN heeft, moet u de ontbrekende logboekrecords uit een databaseback-up toepassen of de database helemaal opnieuw herstellen. Als de database in de status Reverteren stond, moet u de database volledig herstellen van back-ups.

  • Een failoveropdracht wordt geretourneerd zodra het failoverdoel de opdracht heeft geaccepteerd. Databaseherstel vindt echter asynchroon plaats nadat de beschikbaarheidsgroep de failover heeft voltooid.

  • Consistentie tussen databases binnen de beschikbaarheidsgroep kan mogelijk niet worden gehandhaafd bij failover.

    Notitie

    Ondersteuning voor meerdere databases en gedistribueerde transacties variëren per SQL Server- en besturingssysteemversie. Zie Cross-Database Transactions and Distributed Transactions for AlwaysOn Availability Groups and Database Mirroring (SQL Server)voor meer informatie.

Voorwaarden

Aanbevelingen

  • Forceer failover niet terwijl de primaire replica nog actief is.

  • Dwing indien mogelijk failover alleen af naar een failoverdoel waarvan de secundaire databases de status NIET GESYNCHRONISEERD, GESYNCHRONISEERD of SYNCHROON HEBBEN. Zie Beperkingen en beperkingeneerder in dit onderwerp voor informatie over de gevolgen van het afdwingen van failover wanneer een secundaire database de status INITIALISEREN of TERUGDRAAIEN heeft.

  • Normaal gesproken moet de latentie van een bepaalde secundaire database ten opzichte van de primaire database vergelijkbaar zijn op verschillende asynchrone secundaire replica's. Bij het afdwingen van failover kan gegevensverlies echter een grote zorg zijn. Overweeg daarom de tijd te nemen om de relatieve latentie van de databasekopieën op verschillende secundaire replica's vast te stellen. Als u wilt bepalen welke kopie van een bepaalde secundaire database de minste latentie heeft, vergelijkt u de LSN's voor het einde van het logboek. Een hogere end-of-log LSN geeft minder latentie aan.

    Advies

    Als u de LSN's van het einde van het logboek wilt vergelijken, verbindt u met elke secundaire replica die online is. Voer vervolgens een query uit op sys.dm_hadr_database_replica_states voor de end_of_log_lsn-waarde van elke lokale secundaire database. Vergelijk vervolgens de LSN's voor het einde van het logboek van de verschillende kopieën van elke database. Houd er rekening mee dat verschillende databases mogelijk hun hoogste LSN's hebben op verschillende secundaire replica's. In dit geval is het meest geschikte failoverdoel afhankelijk van het relatieve belang dat u op de gegevens in de verschillende databases plaatst. Dat wil zeggen, voor welke van deze databases wilt u mogelijk gegevensverlies minimaliseren?

  • Als clients verbinding kunnen maken met de oorspronkelijke primaire, leidt een geforceerde failover tot een risico van gesplitst hersengedrag. Voordat u failover forceert, raden we u ten zeerste aan om te voorkomen dat clients toegang hebben tot de oorspronkelijke primaire replica. Anders kunnen na een failover de oorspronkelijke primaire databases en de huidige primaire databases onafhankelijk van de andere worden bijgewerkt.

Mogelijke manieren om gegevensverlies te voorkomen nadat quorum is geforceerd

Onder bepaalde foutvoorwaarden nadat het quorum is verbroken, kunt u voorkomen dat gegevens verloren gaan, als volgt:

  • Als de oorspronkelijke primaire replica online komt

    Als quorum verloren gaat en het afdwingen van het WSFC-quorum het clusterknooppunt herstelt dat fungeert als host voor de primaire replica van een beschikbaarheidsgroep, kunt u gegevensverlies voor deze groep beschikbaarheid voorkomen. Maak verbinding met de primaire replica en voer een geforceerde failover uit (FAILOVER_ALLOW_DATA_LOSS). Hierdoor is de primaire replica weer online. Omdat u de geforceerde failover naar de oorspronkelijke primaire replica uitvoert, is er geen gegevensverlies.

  • Als een gesynchroniseerde secundaire replica voor synchrone doorvoer online komt

    Als quorum verloren gaat en WSFC-quorum wordt afgedwongen om een clusterknooppunt te herstellen dat een gesynchroniseerde secundaire replica voor een beschikbaarheidsgroep host, moet u in staat zijn gegevensverlies voor deze beschikbaarheidsgroep te voorkomen. Als het herstelde knooppunt actief was op het moment dat het quorum werd verbroken, kunt u bepalen of gegevensverlies kan optreden op een bepaalde database door de is_failover_ready kolom van de sys.dm_hadr_database_replica_cluster_states dynamische beheerweergave te bevragen. Voer bijvoorbeeld de volgende query uit voor een serverexemplaar met de naam sql108w2k8r22.

    SELECT * FROM sys.dm_hadr_database_replica_cluster_states  
   WHERE replica_id=(SELECT replica_id FROM sys.availability_replicas   
      WHERE replica_server_name ='sql108w2k8r22')

    Voorzichtigheid

    Als het herstelde knooppunt niet operationeel was op het moment dat het quorum verloren ging, geeft is_failover_ready mogelijk niet de werkelijke status van het cluster weer op het moment dat de primaire replica offline ging. Daarom is de is_failover_ready waarde alleen geldig als het hostknooppunt op het moment van de storing is. Zie 'Waarom geforceerde failover is vereist na het afdwingen van quorum' in failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

    Als is_failover_ready = 1, wordt de database gemarkeerd als gesynchroniseerd in het cluster en is deze gereed voor een failover. Als is_failover_ready = 1 op elke database op een bepaalde secundaire replica, kunt u een geforceerde failover (FORCE_FAILOVER_ALLOW_DATA_LOSS) uitvoeren zonder gegevensverlies op deze secundaire replica. De gesynchroniseerde secundaire replica is online in de primaire rol, namelijk als de nieuwe primaire replica, met alle gegevens intact.

    Als is_failover_ready = 0, wordt de database niet gemarkeerd als gesynchroniseerd in het cluster en is niet gereed voor een geplande handmatige failover. Als u een failover naar de secundaire replica van de host dwingt, gaan gegevens in deze database verloren.

    Notitie

    Wanneer u failover naar een secundaire replica overzet, is de hoeveelheid datalek afhankelijk van hoeveel het failoverdoel achter de primaire replica ligt. Helaas kunt u, wanneer het WSFC-cluster geen quorum heeft of wanneer quorum is afgedwongen, de hoeveelheid mogelijk gegevensverlies niet beoordelen. Houd er echter rekening mee dat wanneer het WSFC-cluster weer een goed quorum krijgt, u potentiële gegevensverlies kunt bijhouden. Zie 'Mogelijk gegevensverlies bijhouden' in failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

Machtigingen

Hiervoor is de machtiging ALTER AVAILABILITY GROUP vereist voor de beschikbaarheidsgroep, de machtiging CONTROL AVAILABILITY GROUP, de machtiging ALTER ANY AVAILABILITY GROUP of de machtiging CONTROL SERVER.

SQL Server Management Studio gebruiken

Failover afdwingen (met mogelijk gegevensverlies)

  1. Maak in Objectverkenner verbinding met een serverexemplaren die als host fungeert voor een replica waarvan de rol de status SECUNDAIR of OPLOSSEN heeft in de beschikbaarheidsgroep waarvoor een failover moet worden uitgevoerd en vouw de serverstructuur uit.

  2. Vouw het knooppunt Always On Hoge Beschikbaarheid en het Beschikbaarheidsgroepen knooppunt uit.

  3. Klik met de rechtermuisknop op de beschikbaarheidsgroep waarvoor een failover moet worden uitgevoerd en selecteer de opdracht Failover.

  4. Hiermee wordt de wizard Failover-Beschikbaarheidsgroep gestart. Voor meer informatie, zie De wizard Failover-beschikbaarheidsgroep gebruiken (SQL Server Management Studio).

  5. Nadat u een failover van een beschikbaarheidsgroep hebt afgedwongen, moet u de benodigde vervolgstappen uitvoeren. Zie verderop in dit onderwerp Opvolgen: Essentiële taken na een geforceerde failovervoor meer informatie.

Transact-SQL gebruiken

Failover afdwingen (met mogelijk gegevensverlies)

  1. Maak verbinding met een serverexemplaar dat fungeert als host voor een replica waarvan de rol de status SECUNDAIR of AAN HET OPLOSSEN heeft in de beschikbaarheidsgroep waarvoor een failoverprocedure moet worden uitgevoerd.

  2. Gebruik de opdracht ALTER AVAILABILITY GROUP als volgt:

    ALTER AVAILABILITY GROUP groep_naam FORCE_FAILOVER_ALLOW_DATA_LOSS (dwingt een failover die dataverlies kan veroorzaken)

    waarbij group_name de naam van de beschikbaarheidsgroep is.

    In het volgende voorbeeld wordt de AccountsAG-beschikbaarheidsroep gedwongen om over te schakelen naar de lokale secundaire replica.

    ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

  3. Nadat u een failover van een beschikbaarheidsgroep hebt afgedwongen, moet u de benodigde vervolgstappen uitvoeren. Voor meer informatie, zie Opvolgen: Essentiële taken na een geforceerde failover, verderop in dit onderwerp.

PowerShell gebruiken

Failover afdwingen (met mogelijk gegevensverlies)

  1. Wijzig de directory (cd) naar een serverexemplaar dat fungeert als host voor een replica waarvan de rol de status SECUNDAIR of OPLOSSEN heeft in de beschikbaarheidsgroep die overgezet moet worden.

  2. Gebruik de cmdlet Switch-SqlAvailabilityGroup met de parameter AllowDataLoss in een van de volgende formulieren:

    • -AllowDataLoss

      Standaard zorgt de -AllowDataLoss parameter ervoor dat Switch-SqlAvailabilityGroup u eraan herinnert dat het forceren van een failover kan leiden tot het verlies van niet-doorgevoerde transacties, en bevestiging vraagt. Als u wilt doorgaan, voert u Y-in; als u de bewerking wilt annuleren, voert u N-in.

      In het volgende voorbeeld wordt een geforceerde failover uitgevoerd (met mogelijk gegevensverlies) van de beschikbaarheidsgroep MyAg naar de secundaire replica op het serverexemplaren met de naam SecondaryServer\InstanceName. U wordt gevraagd deze bewerking te bevestigen.

      Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss

    • -AllowDataLoss-Force

      Als u een geforceerde failover wilt initiëren zonder bevestiging, geeft u zowel de parameters -AllowDataLoss als -Force op. Dit is handig als u de opdracht in een script wilt opnemen en wilt uitvoeren zonder tussenkomst van de gebruiker. Gebruik echter de optie -Forceren met voorzichtigheid, omdat een geforceerde failover kan leiden tot verlies van gegevens van databases die deelnemen aan de beschikbaarheidsgroep.

      In het volgende voorbeeld wordt een geforceerde failover uitgevoerd (met mogelijk gegevensverlies) van de beschikbaarheidsgroep MyAg naar het serverexemplaren met de naam SecondaryServer\InstanceName. De optie -Forceer onderdrukt de bevestiging van deze operatie.

      Switch-SqlAvailabilityGroup `  
   -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `  
   -AllowDataLoss -Force

    Notitie

    Als u de syntaxis van een cmdlet wilt weergeven, gebruikt u de Get-Help--cmdlet in de SQL Server PowerShell-omgeving. Voor meer informatie, zie Hulp krijgen SQL Server PowerShell.

  3. Nadat u een failover van een beschikbaarheidsgroep hebt afgedwongen, moet u de benodigde vervolgstappen uitvoeren. Zie voor meer informatie later in dit onderwerp Opvolgen: Essentiële taken na een geforceerde failover.

De SQL Server PowerShell-provider instellen en gebruiken

Opvolgen: Essentiële taken na een geforceerde failover

  1. Na een geforceerde failover wordt de secundaire replica waarnaar u een failover hebt uitgevoerd, de nieuwe primaire replica. Als u deze beschikbaarheidsreplica echter toegankelijk wilt maken voor clients, moet u mogelijk het WSFC-quorum opnieuw configureren of de configuratie van de beschikbaarheidsmodus van de beschikbaarheidsgroep als volgt aanpassen:

  2. Na een geforceerde failover worden alle secundaire databases onderbroken. Dit omvat de voormalige primaire databases, nadat de voormalige primaire replica weer online is en ontdekt dat het nu een secundaire replica is. U moet elke onderbroken database handmatig afzonderlijk hervatten op elke secundaire replica.

    Wanneer een secundaire database wordt hervat, wordt gegevenssynchronisatie gestart met de bijbehorende primaire database. De secundaire database rolt alle logboekrecords terug die nooit zijn doorgevoerd in de nieuwe primaire database. Als u zich dus zorgen maakt over mogelijk gegevensverlies op de primaire databases na failover, moet u proberen een momentopname van de database te maken voor de onderbroken databases op een van de synchrone doorvoer secundaire databases.

    Belangrijk

    Het bijwerken van het transactielogboek op een primaire database wordt vertraagd zolang een van de secundaire databases is opgeschort. De synchronisatiestatus van een secundaire replica met synchrone doorvoer kan ook niet worden overgezet naar HEALTHY zolang een lokale database onderbroken blijft.

    Een momentopname van een database maken

    Een beschikbaarheidsdatabase hervatten

    Voorzichtigheid

    Nadat u alle secundaire databases hebt hervat, wacht u, voordat u opnieuw probeert een failover van de groep uit te voeren, tot elke secundaire database op het volgende failoverdoelwit de toestand SYNCHRONISEREN bereikt. Als een database nog niet synchroon is, kan die database niet online komen als een primaire database en kan het opnieuw tot stand brengen van gegevenssynchronisatie voor de database vereist zijn om transactielogboeken te herstellen, een volledige databaseback-up te herstellen of een failover-overschakeling naar de vorige primaire replica uit te voeren.

  3. Als een beschikbaarheidsreplica die is mislukt niet terugkeert naar de beschikbaarheidsreplica of te laat retourneert om het afkappen van transactielogboeken op de nieuwe primaire database uit te stellen, kunt u overwegen om de mislukte replica uit de beschikbaarheidsgroep te verwijderen om te voorkomen dat er onvoldoende schijfruimte voor uw logboekbestanden beschikbaar is.

    Een secundaire replica verwijderen

  4. Als u een gedwongen failover volgt met een of meer extra gedwongen failovers, voert u na elke extra gedwongen failover in de serie een logboekback-up uit. Zie 'Risico's bij het afdwingen van failover' in de sectie 'Geforceerde handmatige failover (met mogelijk gegevensverlies)' van failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen).

    Een back-up van logboeken uitvoeren

Voorbeeldscenario: een geforceerde failover gebruiken om te herstellen van een onherstelbare fout

Als de primaire replica mislukt en er geen gesynchroniseerde secundaire replica beschikbaar is, kan het zijn dat de beschikbaarheidsgroep een failover moet uitvoeren. De geschiktheid van het afdwingen van een failover is afhankelijk van: (1) of u verwacht dat de primaire replica langer offline is dan uw SLA (Service Level Agreement) tolereert, en (2) of u bereid bent potentiële gegevensverlies te riskeren om primaire databases snel beschikbaar te maken. Als u besluit dat een beschikbaarheidsgroep een geforceerde failover vereist, is de daadwerkelijke geforceerde failover slechts één stap van een proces met meerdere stappen.

Ter illustratie van de stappen die nodig zijn voor het gebruik van een geforceerde failover om te herstellen van een onherstelbare fout, wordt in dit onderwerp een mogelijk scenario voor herstel na noodgevallen weergegeven. In het voorbeeldscenario wordt een beschikbaarheidsgroep beschouwd waarvan de oorspronkelijke topologie bestaat uit een hoofddatacentrum dat als host fungeert voor drie synchrone doorvoerbeschikbaarheidsreplica's, waaronder de primaire replica, en een extern datacenter dat als host fungeert voor twee asynchrone secundaire replica's. In de volgende afbeelding ziet u de oorspronkelijke topologie van deze voorbeeld beschikbaarheidsgroep. De beschikbaarheidsgroep wordt gehost door een WSFC-cluster met meerdere subnetten met drie knooppunten in het hoofddatacentrum (Node 01, Node 02en Node 03) en twee knooppunten in een extern datacenter (Node 04 en Node 05).

Oorspronkelijke topologie van beschikbaarheidsgroep

Het belangrijkste datacenter wordt onverwacht afgesloten. Wanneer de drie beschikbaarheidsreplica's offline gaan, worden hun databases onbeschikbaar. In de volgende afbeelding ziet u de impact van deze fout op de topologie van de beschikbaarheidsgroep.

Topologie na het mislukken van het hoofddatacentrum

De databasebeheerder (DBA) bepaalt dat de beste reactie is om een failover van de beschikbaarheidsgroep te forceren naar een van de externe, asynchrone secundaire replica's. In dit voorbeeld ziet u de gebruikelijke stappen bij het afdwingen van failover van de beschikbaarheidsgroep naar een externe replica en uiteindelijk wordt de beschikbaarheidsgroep naar de oorspronkelijke topologie geretourneerd.

De hier gepresenteerde storingsreactie bestaat uit de volgende twee stadia:

Reageren op de onherstelbare fout van het hoofddatacentrum

In de volgende afbeelding ziet u de reeks acties die in het externe datacenter worden uitgevoerd als reactie op een onherstelbare fout in het hoofddatacentrum.

stappen voor het reageren op fouten in het hoofddatacentrum

De stappen in deze afbeelding geven de volgende stappen aan:

Stap Actie Koppelingen
1. De DBA- of netwerkbeheerder zorgt ervoor dat het WSFC-cluster een goed quorum heeft. In dit voorbeeld moet quorum worden afgedwongen. WSFC-quorum-modi en stem-configuratie (SQL Server)

WSFC Disaster Recovery door middel van een geforceerd quorum (SQL Server)
2. De DBA maakt verbinding met de serverexemplaar met de minste latentie (op Node 04) en voert een geforceerde handmatige failover uit. De geforceerde failover verplaatst deze secundaire replica naar de primaire rol en onderbreekt de secundaire databases op de resterende secundaire replica (op Node 05). sys.dm_hadr_database_replica_states (Transact-SQL) (Query uitvoeren op de kolom end_of_log_lsn. Voor meer informatie, zie Aanbevelingeneerder in dit onderwerp.)
3. De DBA hervat handmatig iedere secundaire database op de resterende secundaire replica. Een beschikbaarheidsdatabase in SQL Server hervatten

De beschikbaarheidsgroep terugsturen naar de oorspronkelijke topologie

In de volgende afbeelding ziet u de reeks acties die de beschikbaarheidsgroep naar de oorspronkelijke topologie retourneren nadat het belangrijkste datacenter weer online is en de WSFC-knooppunten de communicatie met het WSFC-cluster opnieuw tot stand brengen.

Belangrijk

Als het WSFC-clusterquorum is geforceerd, omdat de offlineknooppunten opnieuw worden opgestart, kunnen ze een nieuw quorum vormen als beide voorwaarden bestaan: (a) er is geen netwerkverbinding tussen een van de knooppunten in de geforceerde quorumset en (b) de herstartknooppunten zijn het merendeel van de clusterknooppunten. Dit zou resulteren in een 'split brain'-voorwaarde waarin de beschikbaarheidsgroep twee onafhankelijke primaire replica's zou bezitten, één in elk datacenter. Voordat u het quorum dwingt om een minderheidsquorumset te maken, raadpleegt u WSFC Disaster Recovery via Geforceerd Quorum (SQL Server).

Stappen om de groep terug te keren naar de oorspronkelijke topologie

De stappen in deze afbeelding geven de volgende stappen aan:

Stap Links
1. De knooppunten in het hoofddatacentrum komen weer online en brengen de communicatie met het WSFC-cluster opnieuw tot stand. De beschikbaarheidsreplica's zijn online als secundaire replica's met onderbroken databases en de DBA moet elk van deze databases binnenkort handmatig hervatten. een SQL Server- (Availability Database) hervatten

Tip: Als u zich zorgen maakt over mogelijk gegevensverlies bij de primaire databases na failover, moet u proberen een momentopname van de database te maken op een van de geschorste databases binnen de synchronous-commit secundaire databases. Houd er rekening mee dat het inkorten van het transactielogboek wordt vertraagd op een primaire database terwijl een van de secundaire databases wordt opgeschort. De synchronisatiestatus van de secundaire replica met synchrone doorvoer kan niet worden overgezet naar HEALTHY zolang een lokale database onderbroken blijft.
2. Zodra de databases zijn hervat, wijzigt de DBA de nieuwe primaire replica tijdelijk in de synchrone doorvoermodus. Dit omvat twee stappen:

1) Wijzig één replica voor offline beschikbaarheid naar de asynchrone doorvoermodus.

2) Wijzig de nieuwe primaire replica naar de synchrone commit modus. Opmerking: met deze stap kunnen hervatte secundaire databases met synchrone commit GESYNCHRONISEERD worden.		 De beschikbaarheidsmodus van een Availability Replica (SQL Server) wijzigen
3. Zodra de secundaire replica met synchrone commit op Node 03 (de oorspronkelijke primaire replica) in de toestand GEZOND synchronisatie komt, voert de DBA een geplande handmatige failover naar die replica uit om deze opnieuw als primaire replica te maken. De replica op Node 04 keert terug naar een secundaire replica. sys.dm_hadr_database_replica_states (Transact-SQL)

Gebruik Always On-beleid om de status van een beschikbaarheidsgroep (SQL Server) weer te geven

een geplande handmatige failover van een beschikbaarheidsgroep (SQL Server) uitvoeren
4. De DBA maakt verbinding met de nieuwe primaire replica en:

1) Wijzigt de voormalige primaire replica (op de externe locatie) weer in de asynchrone commit-modus.

2) Hiermee wijzigt u de secundaire replica van asynchrone doorvoer in het hoofddatacentrum terug in de modus synchrone doorvoer.		 De beschikbaarheidsmodus van een beschikbaarheidsreplica wijzigen (SQL Server)

Gerelateerde taken

Quorumstemmen aanpassen

Geplande handmatige failover:

Om problemen op te lossen:

Verwante inhoud

Zie ook

overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
Beschikbaarheidsmodi (Always On-beschikbaarheidsgroepen)
Failover en Failover-modi (Always On-beschikbaarheidsgroepen)
Over Toegang voor Clientverbindingen tot Beschikbaarheidsreplica's (SQL Server)
bewaking van beschikbaarheidsgroepen (SQL Server)
Windows Server Failover Clustering (WSFC) met SQL Server