Verlinkung Failover ausführen – Azure SQL Managed Instance

2025-01-23

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:

Eine aktive Azure-Subscription. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
Unterstützte Version von SQL Server mit erforderlichem Dienstupdate ist installiert.
Verknüpfung zwischen Ihrem primären und sekundären Replikat konfiguriert.
Sie können für die Verknüpfung mithilfe von Transact-SQL ab SQL Server 2022 CU13 (KB5036432) ein Failover durchführen.

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

Um ein Failover ausführen zu können, müssen Sie zuerst die SQL Server-Instanz der Replikationsmodi mithilfe von Transact-SQL (T-SQL) wechseln.

Anschließend können Sie mithilfe von PowerShell ein Failover ausführen und Rollen wechseln.

Wechseln des Replikationsmodus (Failover zu SQL MI)

Die Replikation zwischen SQL Server und SQL Managed Instance erfolgt standardmäßig asynchron. Wenn Sie ein Failover ausführen von SQL Server zu Azure SQL Managed Instance, bevor Sie ein Failover der Datenbank ausführen, wechseln Sie mit Transact-SQL (T-SQL) zum synchronen Modus auf SQL Server.

Hinweis

Überspringen Sie diesen Schritt, wenn Sie ein Failover ausführen von SQL Managed Instance zu SQL Server 2022.
Die synchrone Replikation in großen Netzwerken kann Transaktionen auf dem primären Replikat verlangsamen.

Führen Sie das folgende T-SQL-Skript auf SQL Server aus, um den Replikationsmodus der verteilten Verfügbarkeitsgruppe von asynchron in synchron zu ändern. Ersetzen Sie:

<DAGName> durch den Namen der verteilten Verfügbarkeitsgruppe (zur Erstellung des Links verwendet)
<AGName> durch den Namen der Verfügbarkeitsgruppe, die in SQL Server erstellt wurde (zur Erstellung des Links verwendet)
<ManagedInstanceName> durch den Namen Ihrer verwalteten Instanz.

-- Run on SQL Server
-- Sets the distributed availability group to a synchronous commit.
-- ManagedInstanceName example: 'sqlmi1'
USE master
GO
ALTER AVAILABILITY GROUP [<DAGName>] 
MODIFY 
AVAILABILITY GROUP ON
    '<AGName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT),
    '<ManagedInstanceName>' WITH
    (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);

Um zu bestätigen, dass Sie den Replikationsmodus des Links erfolgreich geändert haben, verwenden Sie die folgende dynamische Verwaltungssicht. Die Ergebnisse zeigen den Zustand SYNCHRONOUS_COMMIT an.

-- Run on SQL Server
-- Verifies the state of the distributed availability group
SELECT
    ag.name, ag.is_distributed, ar.replica_server_name,
    ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc,
    ars.operational_state_desc, ars.synchronization_health_desc
FROM
    sys.availability_groups ag
    join sys.availability_replicas ar
    on ag.group_id=ar.group_id
    left join sys.dm_hadr_availability_replica_states ars
    on ars.replica_id=ar.replica_id
WHERE
    ag.is_distributed=1

Nachdem SQL Server jetzt in den synchronen Commitmodus umgeschaltet wurden, erfolgt die Replikation zwischen den beiden Instanzen synchron. Wenn Sie diesen Zustand umkehren müssen, führen Sie die gleichen Schritte aus, und stellen Sie AVAILABILITY_MODE auf ASYNCHRONOUS_COMMIT ein.

Überprüfen der LSN-Werte für SQL Server und SQL Managed Instance

Um das Failover oder die Migration abzuschließen, bestätigen Sie, dass die Replikation auf dem sekundären Server abgeschlossen ist. Dazu stellen Sie sicher, dass die Protokollfolgenummern (LSN) in den Protokolldatensätzen für SQL Server und für SQL Managed Instance identisch sind.

Anfangs wird erwartet, dass die LSN auf dem primären Computer höher ist als die LSN auf dem sekundären Computer. Die Netzwerklatenz kann dazu führen, dass die Replikation etwas hinter der Primärversion zurückbleibt. Da die Workload auf der Primärinstanz angehalten wurde, wird die LSN übereinstimmen und sich nach einiger Zeit nicht mehr ändern.

Verwenden Sie die folgende T-SQL-Abfrage für SQL Server, um die LSN des zuletzt aufgezeichneten Transaktionsprotokolleintrags zu lesen. Ersetzen Sie:

<DatabaseName> durch Ihren Datenbanknamen, und suchen Sie nach der zuletzt gefestigten LSN

-- Run on SQL Server
-- Obtain the last hardened LSN for the database on SQL Server.
SELECT
    ag.name AS [Replication group],
    db.name AS [Database name], 
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state], 
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN] 
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
    inner join sys.availability_groups ag on drs.group_id = ag.group_id
WHERE
    ag.is_distributed = 1 and db.name = '<DatabaseName>'

Verwenden Sie die folgende T-SQL-Abfrage für SQL Managed Instance, um die letzte gefestigte LSN für Ihre Datenbank zu lesen. Ersetzen Sie <DatabaseName> durch den Namen der Datenbank.

Diese Abfrage funktioniert auf einer universellen SQL Managed Instance. Für eine unternehmenskritische SQL Managed Instance entfernen Sie die Kommentare von and drs.is_primary_replica = 1 am Ende des Skripts. Bei einer unternehmenskritischen Dienstebene stellt dieser Filter sicher, dass Details nur von dem primären Replikat gelesen werden.

-- Run on SQL managed instance
-- Obtain the LSN for the database on SQL Managed Instance.
SELECT
    db.name AS [Database name],
    drs.database_id AS [Database ID], 
    drs.group_id, 
    drs.replica_id, 
    drs.synchronization_state_desc AS [Sync state],
    drs.end_of_log_lsn AS [End of log LSN],
    drs.last_hardened_lsn AS [Last hardened LSN]
FROM
    sys.dm_hadr_database_replica_states drs
    inner join sys.databases db on db.database_id = drs.database_id
WHERE
    db.name = '<DatabaseName>'
    -- for Business Critical, add the following as well
    -- AND drs.is_primary_replica = 1

Alternativ können Sie auch den PowerShell-Befehl Get-AzSqlInstanceLink oder den Azure CLI-Befehl az sql mi link show verwenden, um die LastHardenedLsn Eigenschaft für Ihren Link auf der SQL Managed Instance abzurufen, um die gleichen Informationen wie bei der vorherigen T-SQL-Abfrage zu erhalten.

Wichtig

Vergewissern Sie sich noch einmal, dass Ihre Workload auf der primären Instanz gestoppt wurde. Überprüfen Sie, ob die LSNs von SQL Server und SQL Managed Instance übereinstimmen, gleich bleiben und sich längere Zeit nicht ändern. Stabile LSN in beiden Instanzen deuten darauf hin, dass das Protokollfragment auf die sekundäre Instanz repliziert wurde und die Workload effektiv gestoppt wurde.

Ausführen eines Failovers für eine Datenbank

Wenn Sie PowerShell verwenden möchten, um einen Failover einer Datenbank zwischen SQL Server 2022 und SQL Managed Instance durchzuführen und dabei die Verbindung aufrechtzuerhalten, oder um einen Failover mit Datenverlust für eine beliebige Version von SQL Server durchzuführen, verwenden Sie den Assistenten für Failover zwischen SQL Server und verwaltete Instanz in SSMS, um das Skript für Ihre Umgebung zu erstellen. Sie können ein geplantes Failover entweder von dem primären oder dem sekundären Replikat aus durchführen. Zum Ausführen eines erzwungenen Failovers stellen Sie eine Verbindung mit dem sekundären Replikat her.

Um die Verknüpfung zu unterbrechen und die Replikation zu beenden, wenn Sie einen Failover durchführen oder Ihre Datenbank unabhängig von der SQL Server-Version migrieren, verwenden Sie den PowerShell-Befehl Remove-AzSqlInstanceLink oder den Azure CLI-Befehl az sql mi link delete.

Achtung

Halten Sie vor dem Failover die Arbeitslast auf der Ursprungsdatenbank an, damit die replizierte Datenbank vollständig nachziehen und ein Failover ohne Datenverlust durchführen kann. Wenn Sie einen erzwungenen Failover durchführen oder die Verbindung unterbrechen, bevor die LSNs übereinstimmen, könnten Sie Daten verlieren.
Der Failover einer Datenbank in SQL Server 2019 und früheren Versionen unterbricht und entfernt die Verbindung zwischen den beiden Replikaten. Sie können nicht zur ursprünglichen Primärinstanz zurückkehren.

Das folgende Beispielskript unterbricht die Verknüpfung und beendet die Replikation zwischen Ihren Replikaten, sodass die Datenbank auf beiden Instanzen gelesen und geschrieben werden kann. Ersetzen Sie:

<ManagedInstanceName> durch den Namen Ihrer verwalteten Instanz.
<DAGName> durch den Namen des Links, über den Sie ausfallen (Ausgabe der Eigenschaft Name aus dem oben ausgeführten Befehl Get-AzSqlInstanceLink).

# Run in Azure Cloud Shell (select PowerShell console) 
# =============================================================================
# POWERSHELL SCRIPT TO FAIL OVER OR MIGRATE DATABASE TO AZURE
# ===== Enter user variables here ====

# Enter your managed instance name – for example, "sqlmi1"
$ManagedInstanceName = "<ManagedInstanceName>"
$LinkName = "<DAGName>"

# ==== Do not customize the following cmdlet ====

# Find out the resource group name
$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName

# Failover the specified link
Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup |
-InstanceName $ManagedInstanceName -Name $LinkName -Force

Bei einem erfolgreichen Failover wird der Link getrennt und ist dann nicht mehr vorhanden. Die SQL Server-Datenbank und die SQL Managed Instance-Datenbank können beide Lese-/Schreibworkloads ausführen, da sie nun vollständig unabhängig sind.

Wichtig

Nach erfolgreichem Failover zur SQL Managed Instance verweisen Sie die Verbindungszeichenfolge Ihrer Anwendung(en) manuell auf den FQDN der SQL Managed Instance, um die Migration oder den Failover-Prozess abzuschließen und den Betrieb in Azure fortzusetzen.

Nachdem der Link gelöscht wurde, können Sie die Verfügbarkeitsgruppe auf SQL Server beibehalten, aber Sie müssen die verteilte Verfügbarkeitsgruppe ablegen, um Verknüpfungsmetadaten aus SQL Server zu entfernen. Dieser zusätzliche Schritt ist nur erforderlich, wenn ein Failover mithilfe von PowerShell ausgeführt wird, da SSMS diese Aktion für Sie ausführt.

Ersetzen Sie zum Weglassen der verteilten Verfügbarkeitsgruppe den folgenden Wert, und führen Sie dann den T-SQL-Beispielcode aus:

<DAGName> durch den Namen der verteilten Verfügbarkeitsgruppe auf der SQL Server-Instanz (zur Erstellung des Links verwendet)

-- Run on SQL Server
USE MASTER
GO
DROP AVAILABILITY GROUP <DAGName> 
GO

Wichtig

Nach dem Ausführen eines geplanten Failovers wird der Replikationsmodus auf asynchron festgelegt.

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.

Informationen zum Beheben dieses Problems finden Sie unter Beheben des Split-Brain-Szenarios.

So verwenden Sie den Link:

Weitere Informationen zum Link finden Sie unter:

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter:

Freigeben über

Verlinkung Failover ausführen – Azure SQL Managed Instance

Voraussetzungen

Beenden einer Workload

Ausführen eines Failovers für eine Datenbank

Datenbank nach dem Failover anzeigen

Aufräumen nach Failover

Inkonsistenter Zustand nach erzwungenem Failover

Zugehöriger Inhalt

Feedback

Zusätzliche Ressourcen