Ausführen eines geplanten manuellen Failovers einer Always On-Verfügbarkeitsgruppe (SQL Server)

  • Artikel

Gilt für:SQL Server

In diesem Thema wird beschrieben, wie ein manuelles Failover ohne Datenverlust (ein geplantes manuelles Failover) in einer Always On-Verfügbarkeitsgruppe mithilfe von SQL Server Management Studio, Transact-SQL oder PowerShell in SQL Server ausgeführt wird. Eine Verfügbarkeitsgruppe führt auf der Ebene eines Verfügbarkeitsreplikats ein Failover aus. Bei einem geplanten manuellen Failover wird – wie bei jedem Failover in einer Always On-Verfügbarkeitsgruppe – ein sekundäres Replikat in die primäre Rolle überführt. Parallel dazu wird das bisherige primäre Replikat in die sekundäre Rolle überführt.

Ein geplantes manuelles Failover wird nur unterstützt, wenn das primäre Replikat und das sekundäre Zielreplikat im Modus für synchrone Commits ausgeführt werden und aktuell synchronisiert sind. Bei einem geplanten manuellen Failover bleiben sämtliche Daten in den sekundären Datenbanken, die im sekundären Zielreplikat mit der Verfügbarkeitsgruppe verknüpft sind, erhalten. Nachdem das frühere primäre Replikat in die sekundäre Rolle übergegangen ist, werden seine Datenbanken zu sekundären Datenbanken. Anschließend beginnt Ihre Synchronisierung mit den neuen primären Datenbanken. Nach dem Übergang in den Status SYNCHRONIZED kann das neue sekundäre Replikat als Ziel eines künftigen geplanten manuellen Failovers dienen.

Hinweis

Wenn das sekundäre und primäre Replikat für den automatischen Failovermodus konfiguriert sind, kann das sekundäre Replikat nach der Synchronisierung auch als Ziel für ein automatisches Failover dienen. Weitere Informationen finden Sie unter Verfügbarkeitsmodi (Always On-Verfügbarkeitsgruppen).

Vorbereitung

Wichtig

Für das Failover einer schreibgeschützten Verfügbarkeitsgruppe ohne Cluster-Manager gibt es bestimmte Vorgehensweisen. Wenn für eine Verfügbarkeitsgruppe CLUSTER_TYPE = NONE gilt, führen Sie die Schritte unter Ausführen eines Failovers des primären Replikats auf schreibgeschützten Verfügbarkeitsgruppen aus.

Einschränkungen

  • Ein Failoverbefehl gibt einen Wert zurück, sobald das sekundäre Zielreplikat den Befehl akzeptiert hat. Die Datenbankwiederherstellung tritt jedoch asynchron auf, nachdem die Verfügbarkeitsgruppe aufgehört hat, ein Failover auszuführen.

  • Datenbankübergreifende Konsistenz zwischen Datenbanken innerhalb der Verfügbarkeitsgruppe wird beim Failover möglicherweise nicht beibehalten.

    Hinweis

    Die Unterstützung für datenbankübergreifende und verteilte Transaktionen unterscheidet sich je nach verwendeter SQL Server- und Betriebssystemversion. Weitere Informationen finden Sie unter Datenbankübergreifende Transaktionen und verteilte Transaktionen für Always On-Verfügbarkeitsgruppen und Datenbankspiegelung (SQL Server).

Voraussetzungen und Einschränkungen

  • Sowohl das sekundäre Zielreplikat als auch das primäre Replikat müssen im Verfügbarkeitsmodus für synchrone Commits ausgeführt werden.

  • Das sekundäre Zielreplikat muss aktuell mit dem primären Replikat synchronisiert sein. Alle sekundären Datenbanken in diesem sekundären Replikat müssen mit der Verfügbarkeitsgruppe verknüpft sein. Ebenso müssen sie mit ihren entsprechenden primären Datenbanken synchronisiert sein (d.h., die lokalen sekundären Datenbanken müssen SYNCHRONIZED sein).

    Tipp

    Sie können die Failoverbereitschaft eines sekundären Replikats ermitteln, indem Sie die Spalte is_failover_ready in der dynamischen Verwaltungssicht sys.dm_hadr_database_replica_cluster_states abfragen. Alternativ dazu können Sie sich die Spalte Failoverbereitschaft des Always On-Gruppendashboards ansehen.

  • Dieser Task wird nur für das sekundäre Zielreplikat unterstützt. Sie müssen mit der Serverinstanz verbunden sein, auf der das sekundäre Zielreplikat gehostet wird.

Sicherheit

Berechtigungen

Für die Verfügbarkeitsgruppe ist die Berechtigung ALTER AVAILABILITY GROUP erforderlich. Die CONTROL AVAILABILITY GROUP-Berechtigung, die ALTER ANY AVAILABILITY GROUP-Berechtigung oder die CONTROL SERVER-Berechtigung sind ebenfalls erforderlich.

Verwenden Sie SQL Server Management Studio

So führen Sie manuell ein Failover für eine Verfügbarkeitsgruppe aus:

  1. Stellen Sie im Objekt-Explorer eine Verbindung mit einer Serverinstanz her, die ein sekundäres Replikat der Verfügbarkeitsgruppe hostet, für die ein Failover ausgeführt werden muss. Erweitern Sie die Serverstruktur.

  2. Erweitern Sie den Knoten Hohe Verfügbarkeit (immer aktiviert) und den Knoten Verfügbarkeitsgruppen .

  3. Klicken Sie mit der rechten Maustaste auf die Verfügbarkeitsgruppe, für die ein Failover ausgeführt werden soll, und wählen Sie Failover aus.

  4. Der Assistent für das Failover von Verfügbarkeitsgruppen wird gestartet. Weitere Informationen finden Sie unter Verwenden des Assistenten für Failover-Verfügbarkeitsgruppen (SQL Server Management Studio).

Verwenden von Transact-SQL

So führen Sie manuell ein Failover für eine Verfügbarkeitsgruppe aus:

  1. Stellen Sie eine Verbindung mit der Serverinstanz her, die das sekundäre Zielreplikat hostet.

  2. Verwenden Sie die ALTER AVAILABILITY GROUP -Anweisung wie folgt:

    ALTER AVAILABILITY GROUP Gruppenname FAILOVER

    In der Anweisung ist Gruppenname der Name der Verfügbarkeitsgruppe.

    Im folgenden Beispiel wird manuell ein Failover der MyAg-Verfügbarkeitsgruppe zum verbundenen sekundären Replikat ausgeführt:

    ALTER AVAILABILITY GROUP MyAg FAILOVER;

Verwenden von PowerShell

So führen Sie manuell ein Failover für eine Verfügbarkeitsgruppe aus:

  1. Wechseln Sie (mit cd) in das Verzeichnis der Serverinstanz, die das sekundäre Zielreplikat hostet.

  2. Verwenden Sie das Cmdlet Switch-SqlAvailabilityGroup .

    Hinweis

    Um die Syntax eines Cmdlets anzuzeigen, verwenden Sie das Get-Help -Cmdlet in der SQL Server PowerShell-Umgebung. Weitere Informationen finden Sie unter Get Help for SQL Server PowerShell (Hilfe zu SQL Server-PowerShell anfordern).

    Im folgenden Beispiel wird manuell ein Failover der MyAg-Verfügbarkeitsgruppe zum sekundären Replikat mit dem angegebenen Pfad ausgeführt:

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

    So richten Sie den SQL Server PowerShell-Anbieter ein und verwenden ihn:

Nachverfolgung: Nach dem manuellen Ausführen eines Failovers für eine Verfügbarkeitsgruppe

Wenn Sie ein Failover außerhalb des Satz automatischer Failover der Verfügbarkeitsgruppe ausgeführt haben, passen Sie die Quorumabstimmungen der WSFC-Knoten (Windows Server-Failoverclustering) an die Konfiguration der neuen Verfügbarkeitsgruppe an. Weitere Informationen finden Sie unter Windows Server-Failoverclustering (WSFC) mit SQL Server.

Ausführen eines Failovers des primären Replikats auf eine schreibgeschützte Verfügbarkeitsgruppe

Jede Verfügbarkeitsgruppe hat nur ein primäres Replikat. Das primäre Replikat lässt Lese- und Schreibvorgänge zu. Sie können ein Failover ausführen, um das primäre Replikat zu ändern. In einer typischen Verfügbarkeitsgruppe automatisiert der Cluster-Manager den Failoverprozess. In einer Verfügbarkeitsgruppe mit dem Clustertyp „NONE“ erfolgt der Failovervorgang manuell.

Es gibt zwei Möglichkeiten, ein Failover für ein primäres Replikat in einer Verfügbarkeitsgruppe mit dem Clustertyp „NONE“ auszuführen:

  • Manuelles Failover ohne Datenverlust
  • Erzwungenes manuelles Failover mit Datenverlust

Manuelles Failover ohne Datenverlust

Verwenden Sie diese Methode, wenn das primäre Replikat verfügbar ist. Dabei müssen Sie allerdings vorübergehend oder dauerhaft ändern, welche Instanz das primäre Replikat hostet. Um potenzielle Datenverluste zu vermeiden, stellen Sie vor der Ausführung eines manuellen Failovers sicher, dass das sekundäre Zielreplikat aktuell ist.

So führen ein manuelles Failover ohne Datenverlust aus:

  1. Verwenden Sie SYNCHRONOUS_COMMIT für das aktuelle primäre Replikat und das sekundäre Zielreplikat.

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

  2. Um zu ermitteln, ob für aktive Transaktionen ein Commit auf das primäre Replikat und gleichzeitig auf mindestens ein synchrones sekundäres Replikat ausgeführt wurde, führen Sie die folgende Abfrage aus:

    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;

    Das sekundäre Replikat wird synchronisiert, wenn synchronization_state_descSYNCHRONIZED ist.

  3. Aktualisieren Sie REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf 1.

    Das folgende Skript legt REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT auf „1“ für eine Verfügbarkeitsgruppe mit dem Namen ag1 fest. Ersetzen Sie ag1 vor der Ausführung des Skripts durch den Namen Ihrer Verfügbarkeitsgruppe:

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

    Diese Einstellung stellt sicher, dass für jede aktive Transaktion ein Commit auf das primäre Replikat und auf mindestens ein synchrones sekundäres Replikat ausgeführt wurde.

    Hinweis

    Diese Einstellung ist nicht failoverspezifisch und sollte anhand der Umgebungsanforderungen festgelegt werden.

  4. Legen Sie zur Vorbereitung auf die Rollenänderung das primäre Replikat und die sekundären Replikate, die nicht am Failover beteiligt sind, offline fest:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Stufen Sie das sekundäre Zielreplikat auf ein primäres hoch.

    ALTER AVAILABILITY GROUP AGRScale FORCE_FAILOVER_ALLOW_DATA_LOSS;

  6. Aktualisieren Sie die Rolle des alten primären Replikats und weiterer sekundärer Replikate auf SECONDARY, und führen Sie den folgenden Befehl auf der SQL Server-Instanz aus, die das alte primäre Replikat hostet:

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

    Hinweis

    Verwenden Sie DROP AVAILABILITY GROUP (Verfügbarkeitsgruppe löschen), um eine Verfügbarkeitsgruppe zu löschen. Führen Sie bei Verfügbarkeitsgruppen, die mit dem Clustertyp „NONE“ oder „EXTERNAL“ erstellt wurden, den Befehl für alle Replikate aus, die der Verfügbarkeitsgruppe angehören.

  7. Setzen Sie die Datenverschiebung fort, und führen Sie folgenden Befehl für jede Datenbank in der Verfügbarkeitsgruppe auf der SQL Server-Instanz aus, die das primäre Replikat hostet:

    ALTER DATABASE [db1]
     SET HADR RESUME

  8. Erstellen Sie jeden Listener neu, den Sie für Leseskalierungszwecke erstellt haben und der nicht von einem Cluster-Manager verwaltet wird. Wenn der ursprüngliche Listener auf das alte primäre Replikat zeigt, löschen Sie ihn, und erstellen Sie ihn neu, um auf das neue primäre Replikat zu verweisen.

Erzwungenes manuelles Failover mit Datenverlust

Wenn das primäre Replikat nicht verfügbar ist und nicht sofort wieder hergestellt werden kann, müssen Sie ein Failover auf das sekundäre Replikat mit Datenverlust erzwingen. Wenn das ursprüngliche primäre Replikat jedoch nach einem Failover wieder hergestellt wird, nimmt es die primäre Rolle an. Um zu vermeiden, dass jedes Replikat einen anderen Zustand aufweist, entfernen Sie das ursprüngliche primäre Replikat nach einem erzwungenen Failover mit Datenverlust aus der Verfügbarkeitsgruppe. Wenn das ursprüngliche primäre Replikat wieder online ist, entfernen Sie die Verfügbarkeitsgruppe vollständig.

Gehen Sie folgendermaßen vor, um ein manuelles Failover mit Datenverlust vom primären Replikat N1 zum sekundären Replikat N2 zu erzwingen:

  1. Initiieren Sie auf dem sekundären Replikat (N2) das erzwungene Failover:

    ALTER AVAILABILITY GROUP [AGRScale] FORCE_FAILOVER_ALLOW_DATA_LOSS;

  2. Entfernen Sie auf dem neuen primären Replikat (N2) das ursprüngliche primäre Replikat (N1):

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

  3. Überprüfen Sie, ob der gesamte Anwendungsdatenverkehr auf den Listener und/oder das neue primäre Replikat verweist.

  4. Wenn das ursprüngliche primäre Replikat (N1) online geschaltet wird, schalten Sie die Verfügbarkeitsgruppe „AGRScale“ auf der ursprünglichen primären Datenbank (N1) offline:

    ALTER AVAILABILITY GROUP [AGRScale] OFFLINE

  5. Wenn Daten oder nicht synchronisierte Änderungen vorhanden sind, behalten Sie diese Datei über Sicherungskopien oder andere Datenreplikationsoptionen bei, die Ihren Geschäftsanforderungen entsprechen.

  6. Entfernen Sie als Nächstes die Verfügbarkeitsgruppe aus der ursprünglichen primären Datenbank (N1):

    DROP AVAILABILITY GROUP [AGRScale];

  7. Löschen Sie die Datenbank der Verfügbarkeitsgruppe auf dem ursprünglichen primären Replikat (N1):

    USE [master]
GO
DROP DATABASE [AGDBRScale]
GO

  8. (Optional) Sie können, wenn gewünscht, N1 jetzt wieder als neues sekundäres Replikat der Verfügbarkeitsgruppe „AGRScale“ hinzufügen.

Siehe auch