Failover der Always On-Verfügbarkeitsgruppe unter Linux

  • Artikel

Gilt für:SQL Server – Linux

Im Kontext einer Verfügbarkeitsgruppe können die primäre und die sekundäre Rolle von Verfügbarkeitsreplikaten normalerweise im Rahmen des sogenannten Failovers ausgetauscht werden. Failover können in drei Formen auftreten: automatisches Failover (ohne Datenverlust), geplantes manuelles Failover (ohne Datenverlust) und erzwungenes manuelles Failover (mit möglichem Datenverlust), welches in der Regel erzwungenes Failovergenannt wird. Bei automatischen und geplanten manuellen Failover bleiben alle Daten erhalten. Eine Verfügbarkeitsgruppe führt ein Failover auf der Ebene des Verfügbarkeitsreplikats aus. Das heißt, eine Verfügbarkeitsgruppe führt ein Failover auf eines ihrer sekundären Replikate (das aktuelle Failoverziel) aus.

Hintergrundinformationen zum Failover finden Sie unter Failover und Failovermodi (Always On-Verfügbarkeitsgruppen).

Manuelles Failover

Verwenden Sie die Clusterverwaltungstools für ein Failover einer Verfügbarkeitsgruppe, die von einem externen Cluster-Manager verwaltet wird. Wenn z. B. eine Lösung einen Linux-Cluster mithilfe von Pacemaker verwaltet, verwenden Sie pcs, um manuelle Failover auf RHEL oder Ubuntu durchzuführen. Auf dem SLES verwenden Sie crm.

Wichtig

Verwenden Sie bei normalen Vorgängen für Failover keine Transact-SQL- oder SQL Server-Verwaltungstools wie SSMS oder PowerShell. Falls CLUSTER_TYPE = EXTERNAL, ist EXTERNAL der einzige akzeptable Wert für FAILOVER_MODE. Mit diesen Einstellungen werden alle manuellen oder automatischen Failoveraktionen vom externen Cluster-Manager ausgeführt. Anweisungen zum Erzwingen eines Failovers mit möglichem Datenverlust finden Sie unter Force failover (Erzwungenes Failover).

Schritte für ein manuelles Failover

Das sekundäre Replikat, das zum primären Replikat wird, muss für das Failover synchron sein. Wenn ein sekundäres Replikat asynchron ist, ändern Sie den Verfügbarkeitsmodus.

Das manuelle Failover erfolgt in zwei Schritten.

Führen Sie zunächst ein manuelles Failover durch, indem Sie die Verfügbarkeitsgruppenressource vom Clusterknoten, der die Ressource besitzt, zu einem neuen Knoten verschieben.

Der Cluster führt ein Failover der Verfügbarkeitsgruppenressource aus und fügt eine Speicherorteinschränkung hinzu. Durch diese Einschränkung wird die Ressource so konfiguriert, dass sie auf dem neuen Knoten ausgeführt wird. Entfernen Sie diese Einschränkung, um ein Failover in Zukunft erfolgreich durchführen zu können.

Entfernen Sie im nächsten Schritt die Speicherorteinschränkung.

Schritt 1: Manuelles Failover durch Verschieben der Verfügbarkeitsgruppenressource

Führen Sie den entsprechenden Befehl für Ihre Verteilung aus, um ein Failover von einer Verfügbarkeitsgruppenressource namens ag_cluster auf den Clusterknoten namens nodeName2 durchzuführen:

  • RHEL-/Ubuntu-Beispiel

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

  • SLES-Beispiel

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Wichtig

Wenn Sie die Option „--lifetime“ verwenden, ist die zum Verschieben der Ressource erstellte Speicherorteinschränkung nur temporär und gilt im vorherigen Beispiel 30 Sekunden. Beachten Sie, dass die temporäre Einschränkung nicht automatisch aufgehoben wird und möglicherweise in der Einschränkungsliste auftaucht, allerdings als abgelaufene Einschränkung. Abgelaufene Einschränkungen haben keinen Einfluss auf das Failoververhalten des Pacemaker-Clusters. Wenn Sie beim Verschieben der Ressource nicht die Option „--lifetime“ verwenden, sollten Sie eine Speicherorteinschränkung entfernen, die wie unten beschrieben automatisch hinzugefügt wird.

Schritt 2: Entfernen der Speicherorteinschränkung

Während eines manuellen Failovers fügt der pcs-Befehl move oder der crm-Befehl migrate eine Speicherorteinschränkung hinzu, damit die Ressource auf dem neuen Zielknoten platziert wird. Um die neue Einschränkung anzuzeigen, führen Sie den folgenden Befehl nach dem Verschieben der Ressource aus:

  • RHEL-/Ubuntu-Beispiel

    sudo pcs constraint list --full

  • SLES-Beispiel

    crm config show

Ein Beispiel für die Einschränkung, die aufgrund eines manuellen Failovers erstellt wird. Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

Hinweis

Der Ressourcenname der Verfügbarkeitsgruppe in Pacemaker-Clustern in Red Hat Enterprise Linux 8.x und Ubuntu 18.04 ähnelt ag_cluster-clone, da sich die Benennung in Bezug auf Ressourcen weiterentwickelt hat, um einen heraufstufbaren Klon zu verwenden.

  • RHEL-/Ubuntu-Beispiel

    Im folgenden Befehl ist cli-prefer-ag_cluster-master die ID der Einschränkung, die entfernt werden muss. sudo pcs constraint list --full gibt diese ID zurück.

    sudo pcs resource clear ag_cluster-master

    oder

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    Alternativ können Sie die automatische Generierung von Einschränkungen in einer einzelnen Zeile wie folgt verschieben und löschen. Im folgenden Beispiel wird die Terminologie Klon gemäß Red Hat Enterprise Linux 8.x verwendet.

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

  • SLES-Beispiel

    Im folgenden Befehl ist cli-prefer-ms-ag_cluster die ID der Einschränkung. crm config show gibt diese ID zurück.

    crm configure
delete cli-prefer-ms-ag_cluster 
commit

Hinweis

Das automatische Failover fügt keine Speicherorteinschränkung hinzu, also ist keine Bereinigung notwendig.

Weitere Informationen finden Sie unter:

Erzwungenes Failover

Ein erzwungenes Failover ist ausschließlich für die Notfallwiederherstellung gedacht. In diesem Fall können Sie kein Failover mit Clusterverwaltungstools durchführen, da das primäre Rechenzentrum ausgefallen ist. Wenn Sie ein Failover auf ein nicht synchronisiertes sekundäres Replikat erzwingen, ist Datenverlust möglich. Erzwingen Sie ein Failover nur, wenn Sie den Dienst für die Verfügbarkeitsgruppe sofort wiederherstellen müssen und bereit sind, das Risiko des Datenverlustes in Kauf zu nehmen.

Wenn Sie die Clusterverwaltungstools für die Interaktion mit dem Cluster nicht verwenden können, z. B. wenn der Cluster aufgrund eines Notfallereignisses im primären Rechenzentrum nicht erreichbar ist, müssen Sie das Failover möglicherweise erzwingen, um den externen Cluster-Manager zu umgehen. Dieses Verfahren wird für reguläre Vorgänge nicht empfohlen, da das Risiko des Datenverlusts besteht. Greifen Sie auf dieses Verfahren zurück, wenn die Clusterverwaltungstools das Failover nicht durchführen können. Funktionell ähnelt dieses Verfahren der Durchführung eines erzwungenen manuellen Failovers einer Verfügbarkeitsgruppe unter Windows.

Dieser Prozess zum Erzwingen eines Failovers ist für SQL Server für Linux spezifisch.

  1. Vergewissern Sie sich, dass die Verfügbarkeitsgruppenressource nicht mehr vom Cluster verwaltet wird.

    • Legen Sie für die Ressource auf dem Zielclusterknoten den nicht verwalteten Modus fest. Dieser Befehl signalisiert dem Ressourcen-Agent, dass er die Ressourcenüberwachung und -verwaltung abbrechen soll. Beispiel:
    sudo pcs resource unmanage <resourceName>
    • Wenn Sie den Modus der Ressource nicht auf „nicht verwaltet“ festlegen können, löschen Sie die Ressource. Beispiel:
    sudo pcs resource delete <resourceName>

    Hinweis

    Wenn Sie eine Ressource löschen, werden auch alle zugeordneten Einschränkungen gelöscht.

  2. Legen Sie auf der SQL Server-Instanz, von der das sekundäre Replikat gehostet wird, als Sitzungskontextvariable external_cluster fest.

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

  3. Führen Sie mithilfe von Transact-SQL ein Failover der Verfügbarkeitsgruppe durch. Ersetzen Sie im folgenden Beispiel <MyAg> durch den Namen Ihrer Verfügbarkeitsgruppe. Stellen Sie eine Verbindung mit der SQL Server-Instanz her, die das sekundäre Zielreplikat hostet, und führen Sie den folgenden Befehl aus:

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Versetzen Sie die Verfügbarkeitsgruppe nach einem erzwungenen Failover in einen ordnungsgemäßen Zustand, bevor Sie entweder die Clusterressourcenüberwachung und -verwaltung neu starten oder die Verfügbarkeitsgruppenressource neu erstellen. Lesen Sie sich den Abschnitt Wichtige Aufgaben nach einem erzwungenen Failover durch.

  5. Starten Sie die Clusterressourcenüberwachung und -verwaltung neu:

Führen Sie den folgenden Befehl aus, um die Clusterressourcenüberwachung und -verwaltung neu zu starten:

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

Falls Sie die Clusterressource gelöscht haben, erstellen Sie sie neu. Befolgen Sie die Anweisungen unter Create availability group resource (Verfügbarkeitsgruppenressource erstellen), um die Clusterressource neu zu erstellen.

Wichtig

Verwenden Sie die vorhergehenden Schritte nicht für Übungen zur Notfallwiederherstellung, da dabei das Risiko des Datenverlusts besteht. Ändern Sie stattdessen das asynchrone Replikat in ein synchrones Replikat, und befolgen Sie die Anweisungen für ein normales manuelles Failover.

Überwachung auf Datenbankebene und Failovertrigger

Für CLUSTER_TYPE=EXTERNAL unterscheidet sich die Semantik des Failovertriggers im Vergleich zu WSCF. Wenn sich die Verfügbarkeitsgruppe auf einer SQL Server-Instanz in einem WSFC befindet, führt der Übergang aus dem ONLINE-Status für die Datenbank zu einem Fehler bei der Integrität der Verfügbarkeitsgruppe. Als Reaktion löst der Cluster-Manager eine Failoveraktion aus. Unter Linux kann die SQL Server-Instanz nicht mit dem Cluster kommunizieren. Die Überwachung der Datenbankintegrität erfolgt indirekt. Wenn der Benutzer die Failoverüberwachung und Failover auf Datenbankebene aktiviert hat (durch Festlegen der Option DB_FAILOVER=ON beim Erstellen der Verfügbarkeitsgruppe), überprüft der Cluster bei jeder Ausführung einer Überwachungsaktion, ob der Status der Datenbank ONLINE lautet. Der Cluster fragt den Status unter sys.databases ab. Wenn der Status nicht ONLINE lautet, löst er automatisch ein Failover aus (falls die Bedingungen für das automatische Failover erfüllt sind). Die tatsächliche Dauer des Failovers hängt sowohl von der Frequenz der Überwachungsaktion als auch vom Datenbankstatus ab, der unter „sys.databases“ aktualisiert wird.

Für ein automatisches Failover wird mindestens ein synchrones Replikat benötigt.

Zugehöriger Inhalt

Zur SQL-Dokumentation beitragen

Wussten Sie schon, dass Sie SQL-Inhalte selbst bearbeiten könnten? Hierdurch helfen Sie nicht nur mit, unsere Dokumentation zu verbessern, sondern Sie werden auch als Mitwirkender an der Seite aufgeführt.

Weitere Informationen finden Sie unter Mitwirken an der SQL Server-Dokumentation.