Failover der Always On-Verfügbarkeitsgruppe unter Linux

Gilt für:SQL Server unter 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. Ein AG führt ein Failover auf der Ebene der Verfügbarkeitsreplik durch. Das heißt, eine Verfügbarkeitsgruppe wechselt per Failover zu einem ihrer sekundären Replikate (dem aktuellen Failoverziel).

Hintergrundinformationen zum Thema 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 Red Hat Enterprise Linux (RHEL) oder Ubuntu durchzuführen. Auf SUSE Linux Enterprise Server (SLES) verwenden Sie crm. (Ab SQL Server 2025 (17.x) wird SUSE Linux Enterprise Server (SLES) nicht unterstützt.)

Schritte für ein manuelles Failover

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

Das manuelle Failover erfolgt in zwei Schritten.

1. Führen Sie zunächst ein manuelles Failover durch, indem Sie die Verfügbarkeitsgruppenressource vom Clusterknoten, der die Ressourcen hostet, auf einen neuen Knoten verschieben.

   Der Cluster führt ein Failover der AG-Ressource durch und fügt eine Standorteinschrä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.

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

Schritt 1. Failover manuell durch Verschieben der Verfügbarkeitsgruppenressource durchführen

Um einen manuellen Failover einer AG-Ressource namens ag_cluster auf den Clusterknoten namens nodeName2 durchzuführen, führen Sie den entsprechenden Befehl für Ihre Distribution aus:

• RHEL-/Ubuntu-Beispiel

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

• SLES-Beispiel

  crm resource migrate ag_cluster nodeName2 --lifetime=30S
  

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.

Die temporäre Einschränkung wird nicht automatisch aufgehoben 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 im folgenden Abschnitt beschrieben 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
  

  Dies ist 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)

  Note

  Der Name der AG-Ressource in Pacemaker-Clustern unter Red Hat Enterprise Linux 8.x und Ubuntu 18.04 kann ag_cluster-clone lauten, da sich die Nomenklatur für Ressourcen hin zu hochstufbarer Klon entwickelt hat.

• 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 das Verschieben und Entfernen automatisch generierter Einschränkungen wie folgt in einer einzigen Zeile ausführen. 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
  

Weitere Informationen finden Sie unter:

• Red Hat - Managing Cluster Resources (Red Hat – Verwalten von Clusterressourcen)
• Pacemaker - Ressourcen manuell verschieben
• SLES-Verwaltungshandbuch – Verwalten von Clusterressourcen

Failover erzwingen

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 der Verfügbarkeitsgruppe sofort wiederherstellen müssen und bereit sind, einen Datenverlust zu riskieren.

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. Stellen Sie sicher, dass der Cluster die AG-Ressource nicht mehr verwaltet.

   • 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>
     

     Note

     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.

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

3. Führen Sie mit Transact-SQL ein Failover der AG aus. Ersetzen Sie im folgenden Beispiel <MyAg> durch den Namen Ihrer AG. 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 AG nach einem erzwungenen Failover in einen fehlerfreien Zustand, bevor Sie entweder die Überwachung und Verwaltung der Clusterressourcen neu starten oder die AG-Ressource neu erstellen. Lesen Sie sich den Abschnitt Wichtige Aufgaben nach einem erzwungenen Failover durch.

5. Entweder 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.

Überwachung auf Datenbankebene und Failover-Auslöser

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, meldet der Integritätsstatus der Verfügbarkeitsgruppe einen Fehler, wenn die Datenbank den Status ONLINE verlässt. Als Reaktion löst der Cluster-Manager eine Failoveraktion aus. Unter Linux kann die SQL Server-Instanz nicht mit dem Cluster kommunizieren. Die Überwachung des Datenbankzustands erfolgt von außen nach innen. Wenn der Benutzer sich für die Failoverüberwachung und das Failover auf Datenbankebene entschieden hat (durch Festlegen der Option DB_FAILOVER=ON beim Erstellen der AG), überprüft der Cluster bei jeder Ausführung einer Überwachungsaktion, ob der Datenbankstatus ONLINE ist. 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 und vom Datenbankstatus ab, der unter „sys.databases.“ aktualisiert wird

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

Verwandte Inhalte

• Konfigurieren des Red Hat Enterprise Linux-Clusters für Clusterressourcen von SQL Server-Verfügbarkeitsgruppen
• Konfigurieren des SUSE Linux Enterprise Server-Clusters für Clusterressourcen von SQL Server-Verfügbarkeitsgruppen
• Konfigurieren des Ubuntu-Clusters für Clusterressourcen von SQL Server-Verfügbarkeitsgruppen

Zur SQL-Dokumentation beitragen

Wussten Sie schon, dass Sie SQL-Inhalte selbst bearbeiten könnten? Wenn Sie dies tun, helfen Sie nicht nur, unsere Dokumentation zu verbessern, sondern werden Sie auch als Mitwirkender der Seite erwähnt.

Weitere Informationen finden Sie unter Edit Microsoft Learn documentation.