Failover der Always On-Verfügbarkeitsgruppe unter Linux

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 über das 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.

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.

1. 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.

2. 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
  

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)

  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
  

Weitere Informationen finden Sie unter:

• Red Hat - Managing Cluster Resources (Red Hat – Verwalten von Clusterressourcen)
• Pacemaker - Move Resources Manaually (Pacemaker – Manuelles Verschieben von Ressourcen)
• SLES-Verwaltungshandbuch – Verwalten von Clusterressourcen

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

     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.

Ü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 und vom Datenbankstatus ab, der unter „sys.databases.“ aktualisiert wird

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

Zugehöriger Inhalt

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