Freigeben über

Verlinkung Failover ausführen – Azure SQL Managed Instance

  • Artikel

Gilt für: Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie ein Failover einer Datenbank ausführen, die zwischen SQL Server und Azure SQL Managed Instance verknüpft ist. Dazu verwenden sie SQL Server Management Studio (SSMS) oder PowerShell für die Notfallwiederherstellung oder Migration.

Voraussetzungen

Um ein Failover Ihrer Datenbanken über den Link auf Ihr sekundäres Replikat auszuführen, ist Folgendes erforderlich:

Beenden einer Workload

Wenn Sie zum Failover Ihrer Datenbank bereit sind und um Ihre Datenbank auf das sekundäre Replikat auszulagern, stoppen Sie zunächst alle Anwendungs-Workloads auf dem primären Replikat während Ihrer Wartungszeiten. Dadurch kann die Datenbank-Replikation auf dem sekundären System ausfallen und Sie können ohne Datenverlust auf ein sekundäres System ausfallen. Sie müssen sicherstellen, dass die Anwendungen vor dem Failover keine Transaktionen an das primäre Replikat übertragen.

Ausführen eines Failovers für eine Datenbank

Sie können ein Failover einer verknüpften Datenbank mithilfe von Transact-SQL (T-SQL), SQL Server Management Studio oder PowerShell ausführen.

Sie können für die Verknüpfung mithilfe von Transact-SQL ab SQL Server 2022 CU13 (KB5036432) ein Failover durchführen.

Verwenden Sie zum Ausführen eines geplanten Failovers für einen Link den folgenden T-SQL-Befehl im primären Replikat:

ALTER AVAILABILITY GROUP [<DAGname>] FAILOVER

Verwenden Sie zum Ausführen eines erzwungenen Failovers den folgenden T-SQL-Befehl im sekundären Replikat:

ALTER AVAILABILITY GROUP [<DAGname>] FORCE_FAILOVER_ALLOW_DATA_LOSS

Datenbank nach dem Failover anzeigen

Wenn Sie sich für SQL Server 2022 entschieden haben, die Verbindung beizubehalten, können Sie überprüfen, ob die verteilte Verfügbarkeitsgruppe unter Verfügbarkeitsgruppen in Objekt-Explorer in SQL Server Management Studio vorhanden ist.

Wenn Sie die Verbindung während des Failovers weggelassen haben, können Sie Objekt-Explorer verwenden, um zu bestätigen, dass die verteilte Verfügbarkeitsgruppe nicht mehr vorhanden ist. Wenn Sie sich entschieden haben, die Verfügbarkeitsgruppe beizubehalten, wird die Datenbank weiterhin synchronisiert.

Aufräumen nach Failover

Wenn nicht Link nach dem erfolgreichen Failover entfernen ausgewählt wurde, wird beim Failover mit SQL Server 2022 die Verlinkung nicht unterbrochen. Sie können die Verbindung nach dem Failover beibehalten, wodurch die Verfügbarkeitsgruppe verlassen und die verteilte Verfügbarkeitsgruppe aktiv ist. Weitere Schritte sind nicht erforderlich.

Beim Weglassen der Verbindung wird nur die verteilte Verfügbarkeitsgruppe weggelassen, und die Verfügbarkeitsgruppe bleibt aktiv. Sie können die Verfügbarkeitsgruppe beibehalten oder weglassen.

Wenn Sie sich dazu entscheiden, Ihre Verfügbarkeitsgruppe wegzulassen, ersetzen Sie den folgenden Wert, und führen Sie dann den T-SQL-Beispielcode aus:

  • <AGName> durch den Namen der Verfügbarkeitsgruppe in SQL Server (zur Erstellung des Links verwendet)
-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <AGName> 
GO

Inkonsistenter Zustand nach erzwungenem Failover

Nach einem erzwungenen Failover tritt möglicherweise ein Split-Brain-Szenario auf, bei dem beide Replikate in der primären Rolle sind und die Verlinkung in einem inkonsistenten Zustand bleibt. Dies kann passieren, wenn Sie während eines Notfalls ein Failover auf das sekundäre Replikat umschalten und das primäre Replikat wieder online geht.

Bestätigen Sie sich zunächst, dass Sie sich in einem Split-Brain-Szenario befinden. Sie können dazu SQL Server Management Studio (SSMS) oder Transact-SQL (T-SQL) verwenden.

Stellen Sie eine Verbindung mit SQL-Server und SQL Managed Instance in SSMS her und erweitern Sie dann in Objekt-Explorer Verfügbarkeitsreplikate unter dem Node Verfügbarkeitsgruppe in Always On High Availability. Wenn zwei unterschiedliche Replikate als (Primärinstanz) aufgeführt sind, befinden Sie sich in einem Split-Brain-Szenario.

Alternativ können Sie das folgende T-SQL-Skript sowohl für SQL Server als auch für SQL Managed Instance ausführen, um die Rolle der Replikate zu überprüfen:

-- Execute on SQL Server and SQL Managed Instance 
USE master
DECLARE @link_name varchar(max) = '<DAGName>'
SELECT
   ag.name [Link name], 
   rs.role_desc [Link role] 
FROM
   sys.availability_groups ag 
   join sys.dm_hadr_availability_replica_states rs 
   on ag.group_id = rs.group_id 
WHERE 
   rs.is_local = 1 and ag.name = @link_name 
GO

Wenn beide Instanzen eine andere Primärinstanz in der Spalte Verknüpfungsrolle auflisten, befinden Sie sich in einem Split-Brain-Szenario.

Um den Split-Brain-Zustand aufzulösen, nehmen Sie zuerst eine Sicherung für das replizierbare Replikat als Primärinstanz an. Wenn es sich bei der ursprünglichen primären Instanz um SQL Server handelt, nehmen Sie eine Sicherung des Protokollfragments vor. Wenn die ursprüngliche primäre Instanz eine SQL Managed Instance war, nehmen Sie eine kopiegeschützte vollständige Sicherung vor. Legen Sie nach Abschluss der Sicherung die verteilte Verfügbarkeitsgruppe auf die sekundäre Rolle für das Replikat fest, das als Original-Primärinstanz verwendet wurde, jetzt aber die neue sekundäre Instanz ist.

Wenn Sie beispielsweise im Falle einer echten Katastrophe ein Failover Ihres SQL Server-Workload auf Azure SQL Managed Instance durchgesetzt haben und beabsichtigen, Ihren Workload weiterhin auf SQL Managed Instance auszuführen, nehmen Sie eine Sicherung des Protokollfragments auf SQL Server vor und setzen Sie dann die verteilte Verfügbarkeitsgruppe auf die sekundäre Rolle auf SQL Server, wie im folgenden Beispiel:

--Execute on SQL Server 
USE MASTER

ALTER availability group [<DAGName>] 
SET (role = secondary) 
GO

Führen Sie als Nächstes ein geplantes manuelles Failover von SQL Managed Instance zu SQL Server mithilfe der Verlinkung aus, z. B. das folgende Beispiel:

--Execute on SQL Managed Instance 
USE MASTER

ALTER availability group [<DAGName>] FAILOVER 
GO

Zugehöriger Inhalt

So verwenden Sie den Link:

Weitere Informationen zum Link finden Sie unter:

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter: