Delen via

Failover van AlwaysOn-beschikbaarheidsgroep in Linux

  • Artikel

van toepassing op:SQL Server- - Linux

Binnen de context van een beschikbaarheidsgroep (AG) zijn de primaire rol en secundaire rol van beschikbaarheidsreplica's doorgaans uitwisselbaar, in een proces dat bekend staat als failover. 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. Automatische en geplande handmatige failovers behouden al uw gegevens. Er wordt een failover uitgevoerd voor een beschikbaarheidsgroep op het niveau van de beschikbaarheidsreplica. Dat wil gezegd: een AG voert een failover uit naar een van de secundaire replica's (het huidige failoverdoel).

Voor achtergrondinformatie over failover, zie Failover en failovermodi (Always On-beschikbaarheidsgroepen).

Handmatige failover

Gebruik de clusterbeheerhulpmiddelen om een failover uit te voeren van een AG die door een extern clusterbeheerder wordt beheerd. Als een oplossing bijvoorbeeld Pacemaker gebruikt om een Linux-cluster te beheren, gebruikt u pcs om handmatige failovers uit te voeren op Red Hat Enterprise Linux (RHEL) of Ubuntu. Gebruik op SUSE Linux Enterprise Server (SLES) crm.

Belangrijk

Voer onder normale bewerkingen geen failover uit met Transact-SQL- of SQL Server-beheerprogramma's zoals SSMS of PowerShell. Wanneer CLUSTER_TYPE = EXTERNAL, is de enige acceptabele waarde voor FAILOVER_MODEEXTERNAL. Met deze instellingen worden alle handmatige of automatische failoveracties uitgevoerd door de externe clusterbeheerder. Zie Failover afdwingenvoor instructies voor het afdwingen van failover met mogelijk gegevensverlies.

Handmatige failoverstappen

Als u een failover wilt uitvoeren, moet de secundaire replica die de primaire replica wordt, synchroon zijn. Als een secundaire replica asynchroon is, de beschikbaarheidsmodus wijzigen.

Voer handmatig een failover uit in twee stappen.

  1. Eerst handmatig een failover uitvoeren door ag-resource te verplaatsen van het clusterknooppunt dat eigenaar is van de resources naar een nieuw knooppunt.

    Het cluster mislukt de AG-resource en voegt een locatiebeperking toe. Met deze beperking configureert u de resource die moet worden uitgevoerd op het nieuwe knooppunt. Verwijder deze beperking om in de toekomst een failover uit te voeren.

  2. Ten tweede de locatiebeperkingverwijderen.

Stap 1. Handmatig een failover uitvoeren door de resource van de beschikbaarheidsgroep te verplaatsen

Als u handmatig een failover wilt uitvoeren van een AG-resource met de naam ag_cluster naar het clusterknooppunt met de naam nodeName2, voert u de juiste opdracht uit voor uw distributie:

  • RHEL-/Ubuntu-voorbeeld

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

  • SLES-voorbeeld

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Wanneer u de optie --lifetime gebruikt, is de locatiebeperking die is gemaakt om de resource te verplaatsen tijdelijk en is deze gedurende 30 seconden geldig in het vorige voorbeeld.

De tijdelijke beperking wordt niet automatisch gewist en wordt mogelijk weergegeven in de lijst met beperkingen, maar als een verlopen beperking. Verlopen beperkingen hebben geen invloed op het failovergedrag van pacemakerclusters. Als u de optie --lifetime niet gebruikt bij het verplaatsen van de resource, moet u een locatiebeperking verwijderen die automatisch wordt toegevoegd. Dit wordt vermeld in de volgende sectie.

Stap 2. De locatiebeperking verwijderen

Tijdens een handmatige failover wordt met de opdracht pcsmove of crm opdracht migrate een locatiebeperking toegevoegd voor de resource die op het nieuwe doelknooppunt moet worden geplaatst. Als u de nieuwe beperking wilt zien, voert u de volgende opdracht uit nadat u de resource handmatig hebt verplaatst:

  • RHEL-/Ubuntu-voorbeeld

    sudo pcs constraint list --full

  • SLES-voorbeeld

    crm config show

    Dit is een voorbeeld van de beperking, die wordt gemaakt vanwege een handmatige failover.

    Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

    Notitie

    De naam van de AG-resource in pacemakerclusters op Red Hat Enterprise Linux 8.x en Ubuntu 18.04 kan lijken op ag_cluster clone aangezien de nomenclatuur met betrekking tot resources zich heeft ontwikkeld naar het gebruik van promotable clone.

  • RHEL-/Ubuntu-voorbeeld

    In de volgende opdracht is cli-prefer-ag_cluster-master de id van de beperking die moet worden verwijderd. sudo pcs constraint list --full retourneert deze id.

    sudo pcs resource clear ag_cluster-master

    Of

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    U kunt ook zowel de verplaatsing als het wissen van automatisch gegenereerde beperkingen in één regel als volgt uitvoeren. In het volgende voorbeeld wordt de kloon terminologie gebruikt volgens Red Hat Enterprise Linux 8.x.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone

  • SLES-voorbeeld

    In de volgende opdracht is cli-prefer-ms-ag_cluster de id van de beperking. crm config show retourneert deze id.

    crm configure
delete cli-prefer-ms-ag_cluster
commit

Notitie

Automatische failover voegt geen locatiebeperking toe, dus er is geen opschoonactie nodig.

Voor meer informatie:

Failover afdwingen

Een geforceerde failover is uitsluitend bedoeld voor herstel na noodgevallen. In dit geval kunt u geen failover uitvoeren met hulpprogramma's voor clusterbeheer omdat het primaire datacenter uitvalt. Als u een failover afdwingt naar een niet-gesynchroniseerde secundaire replica, is enig gegevensverlies mogelijk. Voer alleen een failover uit als u de service onmiddellijk naar de AG moet herstellen en bereid bent het risico te nemen dataverlies te lijden.

Als u de hulpprogramma's voor clusterbeheer niet kunt gebruiken voor interactie met het cluster (bijvoorbeeld als het cluster niet reageert vanwege een noodgeval in het primaire datacenter), moet u mogelijk een failover afdwingen om de externe clusterbeheerder te omzeilen. Deze procedure wordt niet aanbevolen voor reguliere bewerkingen, omdat er risico is op gegevensverlies. Gebruik deze functie wanneer de hulpprogramma's voor clusterbeheer de failover-actie niet uitvoeren. Functioneel gezien is deze procedure vergelijkbaar met het uitvoeren van een geforceerde handmatige failover op een AG in Windows.

Dit proces voor het afdwingen van failover is specifiek voor SQL Server in Linux.

  1. Controleer of het cluster de AG-resource niet meer beheert.

    • Stel de resource in op de niet-beheerde modus op het doelclusterknooppunt. Met deze opdracht wordt de resourceagent signalen gegeven om de bewaking en het beheer van resources te stoppen. Bijvoorbeeld:

      sudo pcs resource unmanage <resourceName>

    • Als de poging om de resourcemodus in te stellen op de niet-beheerde modus mislukt, verwijdert u de resource. Bijvoorbeeld:

      sudo pcs resource delete <resourceName>

      Notitie

      Wanneer u een resource verwijdert, worden ook alle bijbehorende beperkingen verwijderd.

  2. Stel op het exemplaar van SQL Server dat als host fungeert voor de secundaire replica de sessiecontextvariabele in external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';

  3. Voer een failover van de AG uit met Transact-SQL. Vervang in het volgende voorbeeld <MyAg> door de naam van uw AG. Maak verbinding met het exemplaar van SQL Server dat als host fungeert voor de secundaire doelreplica en voer de volgende opdracht uit:

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Na een geforceerde failover brengt u de beschikbaarheidsgroep in orde voordat u de bewaking en het beheer van de clusterresource opnieuw start of de beschikbaarheidsgroep-resource opnieuw creëert. Controleer de Essentiële taken na een geforceerde failover.

  5. Start de bewaking en het beheer van clusterresources opnieuw op:

    Voer de volgende opdracht uit om de bewaking en het beheer van de clusterresource opnieuw op te starten:

    sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>

    Als u de clusterresource hebt verwijderd, maakt u deze opnieuw. Volg de instructies in om de clusterresource opnieuw te makenResource voor beschikbaarheidsgroep maken.

Belangrijk

Gebruik de voorgaande stappen niet voor noodherstelanalyses omdat ze gegevensverlies riskeren. Verander de asynchrone replica in een synchrone en volg de instructies voor normale handmatige failover.

Monitoring en failover-trigger op databaseniveau

Voor CLUSTER_TYPE=EXTERNALzijn de semantieken van de failovertrigger anders in vergelijking met WSFC. Wanneer de beschikbaarheidsgroep zich op een exemplaar van SQL Server in een WSFC bevindt, leidt het verlaten van de ONLINE-status van de database ertoe dat de gezondheidstoestand van de beschikbaarheidsgroep een fout meldt. Als reactie activeert de clusterbeheerder een failover-actie. In Linux kan het SQL Server-exemplaar niet communiceren met het cluster. Bewaking van de databasestatus wordt uitgevoerd van buiten naar binnen. Als de gebruiker heeft ingeschakeld voor failoverbewaking en failover op databaseniveau (door de optie DB_FAILOVER=ON in te stellen bij het maken van de beschikbaarheidsgroep), controleert het cluster of de databasestatus ONLINE is telkens als een bewakingsactie wordt uitgevoerd. Het cluster voert een query uit op de status in sys.databases. Voor elke status die verschilt van ONLINE, wordt er automatisch een failover geactiveerd (als aan de voorwaarden voor automatische failover wordt voldaan). De werkelijke tijd van de failover is afhankelijk van de frequentie van de bewakingsactie en de databasestatus die wordt bijgewerkt in sys.databases.

Automatische failover vereist ten minste één synchrone replica.

Verwante inhoud

Bijdragen aan SQL-documentatie

Wist u dat u zelf SQL-inhoud kunt bewerken? Als u dit doet, helpt u niet alleen onze documentatie te verbeteren, maar krijgt u ook erkenning als bijdrager aan de pagina.

Zie Bijdragen aan sql Server-documentatie voor meer informatie