Verlinkung Failover ausführen – Azure SQL Managed Instance

Sie können für den Link mithilfe von Transact-SQL (derzeit in der Vorschau) ab SQL Server 2022 CU13 (KB5036432) Failover ausfü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

Verwenden Sie das Failover zwischen SQL Server und verwaltete Instanz-Assistenten in SSMS, um die Datenbank von Ihrem primären zu Ihrem sekundären Replikat zu überschreiben.

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.

Führen Sie die folgenden Schritte aus, um ein Failover Ihrer Datenbank auszuführen:

1. Öffnen Sie SSMS, und stellen Sie eine Verbindung zu einem Replikaten her.

2. Klicken Sie im Objekt-Explorer mit der rechten Maustaste auf Ihre Datenbank, zeigen Sie mit der Maus auf Azure SQL Managed Instance-Link und wählen Sie Failover… für Datenbank ausführen aus, um den Assistenten für die Ausführung eines Failovers für eine Datenbank zu Managed Instance zu öffnen. Wenn Sie über mehrere Verknüpfungen aus derselben Datenbank verfügen, erweitern Sie Verfügbarkeitsgruppen unter AlwaysOn-Verfügbarkeitsgruppen in Objekt-Explorer, und klicken Sie mit der rechten Maustaste auf die Verteilte Verfügbarkeitsgruppe für den Link, über den Sie fehlschlagen möchten. Wählen Sie Failover… um das Failover zwischen SQL Server und verwaltete Instanz Assistenten für diesen bestimmten Link zu öffnen.

   

3. Wählen Sie auf der Seite Einführung die Option Weiter.

4. Auf der Seite Failover-Typ auswählen werden Details zu den einzelnen Replikaten, der Rolle der ausgewählten Datenbank und den unterstützten Failovertypen angezeigt. Sie können Failover von jedem Replikat aus initiieren. Wenn Sie ein erzwungenes Failover auswählen, müssen Sie das Kontrollkästchen aktivieren, um anzugeben, dass ein potenzieller Datenverlust auftreten könnte. Wählen Sie Weiter aus.

   Hinweis

   Wenn Sie zu Azure SQL Managed Instance migrieren, wählen Sie Geplantes Failover aus.

5. Auf der Seite Bei Azure und Remoteinstanz anmelden:

   1. Wählen Sie Anmelden aus, um Ihre Anmeldeinformationen anzugeben und sich bei Ihrem Azure-Konto anzumelden.
   2. Basierend auf dem auf der vorherigen Seite ausgewählten Failovertyp funktioniert die Option Anmelden anders. Für ein geplantes Failover ist die Anmeldung bei der Remoteinstanz (entweder SQL Server oder SQL Managed Instance) obligatorisch. Für ein erzwungenes Failover ist die Signatur optional, da die folgenden beiden Szenarien unterstützt werden:
      • Wahre Notfallwiederherstellung: Da die primäre Instanz in der Regel während eines echten Notfalls nicht verfügbar ist, ist die Anmeldung nicht möglich, und der Benutzer muss sofort ein Failover zur sekundären Instanz ausführen, wodurch sie zur neuen primären Instanz wird. Nachdem der Ausfall behoben wurde, befindet sich der Link in einem inkonsistenten Zustand, da sich beide Replikate jetzt in der primären Rolle (Split-Brain-Szenario) befinden.
      • Übung zur Notfallwiederherstellung: Von der Ausführung von Übungen zur Notfallwiederherstellung mit erzwungenem Failover wird abgeraten, da potenzielle Datenverluste auftreten könnten. Während einer Übung wird jedoch die Anmeldung unterstützt, da die primäre Instanz verfügbar ist, und Sie haben die Möglichkeit, Rollen für beide Replikate umzukehren, um das Split-Brain-Szenario zu vermeiden.

6. Auf der Seite Post-Failover-Vorgänge unterscheiden sich die Optionen zwischen SQL Server 2022 und früheren Versionen und unabhängig davon, ob Sie eine Verbindung mit der primären Instanz herstellen konnten.

   • Für SQL Server 2022 können Sie die Replikation zwischen Replikaten beenden und die Verknüpfung und verteilte Verfügbarkeitsgruppe nach Abschluss des Failovers ablegen. Wenn Sie die Verknüpfung Standard und die Replikation von Daten zwischen Replikaten fortsetzen möchten, lassen Sie das Kontrollkästchen deaktiviert. Wenn Sie den Link löschen möchten, können Sie auch das Kontrollkästchen aktivieren, um die Verfügbarkeitsgruppe zu löschen, wenn Sie sie ausschließlich zum Zweck der Replikation Ihrer Datenbank in Azure erstellt haben und Sie sie nicht mehr benötigen. Aktivieren Sie die Kontrollkästchen, die Ihrem Szenario entsprechen, und wählen Sie dann Weiter.
   • Bei SQL Server 2019 und früheren Versionen ist die Option zum Entfernen des Links standardmäßig aktiviert, und Sie können die Option nicht deaktivieren, da der Fehler bei SQL verwaltete Instanz die Replikation beendet, die Verknüpfung unterbrochen und die verteilte Verfügbarkeitsgruppe aufgehoben wird. Aktivieren Sie das Kontrollkästchen, um anzugeben, dass der Link gelöscht wird, und wählen Sie dann Weiter.
   • (Optional) Wenn Sie sich auf der vorherigen Seite bei der SQL Server-Instanz anmelden konnten, haben Sie auch die Möglichkeit, die Verfügbarkeitsgruppe in der SQL Server-Instanz nach einem erzwungenen Failover zu löschen, indem Sie das Kontrollkästchen im Abschnitt Bereinigen aktivieren.

7. Überprüfen Sie die Aktionen auf der Seite Zusammenfassung. Wählen Sie optional Skript aus, um ein Skript zu generieren, damit Sie die Datenbank problemlos mit demselben Link in der Zukunft überschreiben können. Wenn Sie bereit sind, mit dem Failover fortzufahren, wählen Sie Fertig stellen aus.

8. Nach Abschluss aller Schritte werden auf der Seite Ergebnisse neben den erfolgreich abgeschlossenen Aktionen Häkchen angezeigt. Sie können das Fenster jetzt schließen.

Wenn Sie den Link für SQL Server 2022 Standard beibehalten haben, wird die sekundäre Verbindung zur neuen primären Instanz, die Verknüpfung ist weiterhin aktiv, und Sie können die sekundäre Verknüpfung nicht mehr aufrufen.

Wenn Sie sql Server 2019 und frühere Versionen verwenden oder den Link für SQL Server 2022 ablegen möchten, wird der Link gelöscht und ist nach Abschluss des Failovers nicht mehr vorhanden. Die Quelldatenbank und die Zieldatenbank auf jedem Replikat können eine Lese-/Schreibworkload ausführen. Sie sind vollständig unabhängig.

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.

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.

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.

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.

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