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

van toepassing op:SQL Server-

In dit onderwerp wordt beschreven hoe u een handmatige failover uitvoert zonder gegevensverlies (een geplande handmatige failover) op een AlwaysOn-beschikbaarheidsgroep met behulp van SQL Server Management Studio, Transact-SQL of PowerShell in SQL Server. Een beschikbaarheidsgroep voert een failover uit op het niveau van een beschikbaarheidsreplica. Een geplande handmatige failover, zoals elke Always On-failover van een beschikbaarheidsgroep, zorgt ervoor dat een secundaire replica de primaire rol overneemt. Tegelijkertijd verandert de failover de voormalige primaire replica naar de secundaire rol.

Een geplande handmatige failover wordt alleen ondersteund wanneer de primaire replica en de secundaire doelreplica opereren in de modus voor synchrone commit en momenteel gesynchroniseerd zijn. Bij een geplande handmatige failover blijven alle gegevens in de secundaire databases behouden die zijn gekoppeld aan de beschikbaarheidsgroep op de secundaire doelreplica. Nadat de voormalige primaire replica naar de rol van secundaire replica is overgezet, worden de databases secundaire databases. Vervolgens beginnen ze te synchroniseren met de nieuwe primaire databases. Nadat ze allemaal de status GESYNCHRONISEERD hebben bereikt, wordt de nieuwe secundaire replica geschikt om als doel te dienen voor een toekomstige geplande handmatige failover.

Notitie

Als de secundaire en primaire replica's beide zijn geconfigureerd voor de automatische failovermodus, kan deze, nadat de secundaire replica is gesynchroniseerd, ook fungeren als het doel voor een automatische failover. Zie Beschikbaarheidsmodi (AlwaysOn-beschikbaarheidsgroepen)voor meer informatie.

Voordat u begint

Belangrijk

Er zijn specifieke procedures voor het uitvoeren van een failover van een beschikbaarheidsgroep op leesschaal zonder clusterbeheer. Wanneer een beschikbaarheidsgroep CLUSTER_TYPE = NONE heeft, volgt u de procedures onder Schakel de primaire replica over op een beschikbaarheidsgroep met leesschaal.

Beperkingen en beperkingen

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

• Consistentie tussen databases binnen de beschikbaarheidsgroep wordt mogelijk niet gehandhaafd bij een failover.

  Notitie

  Ondersteuning voor meerdere databases en gedistribueerde transacties variëren per SQL Server- en besturingssysteemversie. Zie Transacties tussen databases en gedistribueerde transacties voor AlwaysOn-beschikbaarheidsgroepen en databasespiegeling (SQL Server)voor meer informatie.

Vereisten en beperkingen

• Zowel de secundaire doelreplica als de primaire replica moeten draaien in de synchrone commit-beschikbaarheidsmodus.

• Op dit moment moet de secundaire doelreplica worden gesynchroniseerd met de primaire replica. Alle secundaire databases op deze secundaire replica moeten worden gekoppeld aan de beschikbaarheidsgroep. Ze moeten ook worden gesynchroniseerd met hun bijbehorende primaire databases (de lokale secundaire databases moeten worden GESYNCHRONISEERD).

  Fooi

  Als u de failovergereedheid van een secundaire replica wilt bepalen, voert u een query uit op de kolom is_failover_ready in de sys.dm_hadr_database_replica_cluster_states dynamische beheerweergave. U kunt ook de kolom Failover-gereedheid bekijken van het Always On-groepsdashboard.

• Deze taak wordt alleen ondersteund op de secundaire doelreplica. u moet zijn verbonden met het serverexemplaar die als host fungeert voor de secundaire doelreplica.

Veiligheid

Machtigingen

Toestemming ALTER AVAILABILITY GROUP is vereist voor de beschikbaarheidsgroep. De machtiging CONTROL AVAILABILITY GROUP, de machtiging ALTER ANY AVAILABILITY GROUP of de MACHTIGING CONTROL SERVER is ook vereist.

SQL Server Management Studio gebruiken

Een failover van een beschikbaarheidsgroep handmatig uitvoeren:

1. Maak in Objectverkenner verbinding met een serverexemplaar dat host is van een secundaire replica van de beschikbaarheidsgroep waarvoor een overzetting moet worden uitgevoerd. Vouw de serverstructuur uit.

2. Vouw het knooppunt Always On hoge beschikbaarheid en het knooppunt Beschikbaarheidsgroepen uit.

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

4. De wizard voor de failoverbeschikbaarheidsgroep wordt gestart. Zie De wizard Failover-beschikbaarheidsgroep (SQL Server Management Studio) gebruikenvoor meer informatie.

Gebruik Transact-SQL

Om handmatig een overschakeling van een beschikbaarheidsgroep uit te voeren:

1. Maak verbinding met het serverexemplaar waarop de doelsecundaire replica wordt gehost.

2. Gebruik de statement ALTER AVAILABILITY GROUP als volgt:

   WIJZIG DE BESCHIKBAARHEIDSGROEP GROUP_NAME FAILOVER

   In de verklaring is group_name de naam van de beschikbaarheidsgroep.

   In het volgende voorbeeld wordt handmatig een failover uitgevoerd van de MyAg beschikbaarheidsgroep naar de verbonden secundaire replica:

   ALTER AVAILABILITY GROUP MyAg FAILOVER;  
   

PowerShell gebruiken

Een failover van een beschikbaarheidsgroep handmatig uitvoeren:

1. Wijzig de map (cd) naar het serverexemplaar waarop de secundaire doelreplica wordt gehost.

2. Gebruik de cmdlet Switch-SqlAvailabilityGroup.

   Notitie

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

   In het volgende voorbeeld wordt handmatig een failover uitgevoerd van de MyAg beschikbaarheidsgroep naar de secundaire replica met het opgegeven pad:

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

   De SQL Server PowerShell-provider instellen en gebruiken:

   • SQL Server PowerShell-provider
   • Hulp krijgen voor SQL Server PowerShell

Opvolgen: Nadat u handmatig een failover hebt uitgevoerd voor een beschikbaarheidsgroep

Als u een failover hebt uitgevoerd buiten de automatische failoverset van de beschikbaarheidsgroep, past u de quorumstemmen van de Windows Server-failoverclusterknooppunten aan zodat deze overeenkomen met de configuratie van uw nieuwe beschikbaarheidsgroep. Zie Windows Server-failoverclustering (WSFC) met SQL Servervoor meer informatie.

Overschakelen naar de primaire replica in een leesschaal-beschikbaarheidsgroep

Elke beschikbaarheidsgroep heeft slechts één primaire replica. De primaire replica staat lees- en schrijfbewerkingen toe. Als u wilt wijzigen welke replica primair is, kunt u een failover uitvoeren. In een typische beschikbaarheidsgroep automatiseert de clusterbeheerder het failoverproces. In een beschikbaarheidsgroep met clustertype NONE is het failoverproces handmatig.

Er zijn twee manieren om een failover uit te voeren voor de primaire replica in een beschikbaarheidsgroep met clustertype NONE:

• Handmatige failover zonder gegevensverlies
• Geforceerde handmatige failover met gegevensverlies

Handmatige failover zonder gegevensverlies

Gebruik deze methode wanneer de primaire replica beschikbaar is, maar u moet tijdelijk of permanent wijzigen welk exemplaar als host fungeert voor de primaire replica. Als u mogelijk gegevensverlies wilt voorkomen, moet u ervoor zorgen dat de secundaire doelreplica up-to-date is voordat u de handmatige failover uitvoert.

Handmatig een failover uitvoeren zonder gegevensverlies:

1. Maak de huidige primaire replica en maak de doelsecundaire replica SYNCHRONOUS_COMMIT.

   ALTER AVAILABILITY GROUP [AGRScale] 
        MODIFY REPLICA ON N'<node2>' 
        WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

2. Voer de volgende query uit om te bepalen dat actieve transacties worden doorgevoerd in de primaire replica en ten minste één synchrone secundaire replica:

   SELECT ag.name, 
      drs.database_id, 
      drs.group_id, 
      drs.replica_id, 
      drs.synchronization_state_desc, 
      ag.sequence_number
   FROM sys.dm_hadr_database_replica_states drs, sys.availability_groups ag
   WHERE drs.group_id = ag.group_id; 
   

   De secundaire replica wordt gesynchroniseerd wanneer synchronization_state_desc is SYNCHRONIZED.

3. Werk REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT bij naar 1.

   Met het volgende script wordt REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ingesteld op 1 op een beschikbaarheidsgroep met de naam ag1. Voordat u het volgende script uitvoert, vervangt u ag1 door de naam van uw beschikbaarheidsgroep:

   ALTER AVAILABILITY GROUP [AGRScale] 
        SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

   Deze instelling zorgt ervoor dat elke actieve transactie wordt doorgevoerd in de primaire replica en ten minste één synchrone secundaire replica.

   Notitie

   Deze instelling is niet specifiek voor failover en moet worden ingesteld op basis van de vereisten van de omgeving.

4. Stel de primaire replica en de secundaire replica's die niet deelnemen aan de failover offline in om de rolwijziging voor te bereiden.

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Promoveer de secundaire replica naar primair.

   ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS; 
   

6. Werk de rol van de oude primaire en andere secundaire databases bij naar SECONDARYen voer de volgende opdracht uit op het SQL Server-exemplaar dat als host fungeert voor de oude primaire replica:

   ALTER AVAILABILITY GROUP [AGRScale] 
        SET (ROLE = SECONDARY); 
   

   Notitie

   Als u een beschikbaarheidsgroep wilt verwijderen, gebruikt u DROP AVAILABILITY GROUP. Voor een beschikbaarheidsgroep die is gemaakt met clustertype NONE of EXTERNAL, voert u de opdracht uit op alle replica's die deel uitmaken van de beschikbaarheidsgroep.

7. Hervat gegevensverplaatsing, voer de volgende opdracht uit voor elke database in de beschikbaarheidsgroep op het SQL Server-exemplaar dat als host fungeert voor de primaire replica:

   ALTER DATABASE [db1]
        SET HADR RESUME
   

8. Hermaak elke listener die u eerder hebt gemaakt voor leesschaaldoeleinden en die niet beheerd wordt door een clusterbeheerder. Als de oorspronkelijke listener verwijst naar de oude primaire, verwijder deze en maak deze opnieuw aan om naar de nieuwe primaire te verwijzen.

Geforceerde handmatige failover met gegevensverlies

Als de primaire replica niet beschikbaar is en niet onmiddellijk kan worden hersteld, moet u een failover naar de secundaire replica afdwingen met gegevensverlies. Als de oorspronkelijke primaire replica echter na een failover wordt hersteld, zal deze de primaire rol opnieuw op zich nemen. Als u wilt voorkomen dat elke replica een andere status heeft, verwijdert u de oorspronkelijke primaire replica uit de beschikbaarheidsgroep na een geforceerde failover met gegevensverlies. Zodra de oorspronkelijke primaire versie weer online is, verwijdert u de beschikbaarheidsgroep volledig.

Als u een handmatige failover wilt afdwingen met gegevensverlies van primaire replica N1 naar secundaire replica N2, voert u de volgende stappen uit:

1. Voer op de secundaire replica (N2) de geforceerde failover uit:

   ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

2. Verwijder op de nieuwe primaire replica (N2) de oorspronkelijke primaire replica (N1):

   ALTER AVAILABILITY GROUP [AGRScale]
   REMOVE REPLICA ON N'N1';
   

3. Controleer of al het toepassingsverkeer naar de listener en/of de nieuwe primaire replica wijst.

4. Als de oorspronkelijke primaire (N1) online komt, haalt u de beschikbaarheidsgroep AGRScale onmiddellijk offline op de oorspronkelijke primaire (N1):

   ALTER AVAILABILITY GROUP [AGRScale] OFFLINE
   

5. Als er gegevens of niet-gesynchroniseerde wijzigingen zijn, behoudt u deze gegevens via back-ups of andere opties voor het repliceren van gegevens die aansluiten bij uw zakelijke behoeften.

6. Verwijder vervolgens de beschikbaarheidsgroep uit de oorspronkelijke primaire groep (N1):

   DROP AVAILABILITY GROUP [AGRScale];
   

7. Verwijder de database van de beschikbaarheidsgroep op de oorspronkelijke primaire replica (N1):

   USE [master]
   GO
   DROP DATABASE [AGDBRScale]
   GO
   

8. (Optioneel) Desgewenst kunt u N1 weer toevoegen als een nieuwe secundaire replica aan de beschikbaarheidsgroep AGRScale.

Zie ook

• Overzicht van AlwaysOn-beschikbaarheidsgroepen (SQL Server)
• failover- en failovermodi (AlwaysOn-beschikbaarheidsgroepen)
• een geforceerde handmatige failover uitvoeren van een beschikbaarheidsgroep (SQL Server)