Failoververknüpfung – Azure SQL Managed Instance

Sie können den Link mit Transact-SQL ab SQL Server 2022 CU13 (KB5036432) fehlschlagen.

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 den Failover zwischen SQL Server und verwaltete Instanz-Assistenten in SSMS, um die Datenbank von Ihrem primären Replikat auf das sekundäre Replikat zu verschieben.

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 in Objekt-Explorer mit der rechten Maustaste auf Ihre replizierte Datenbank, zeigen Sie mit der Maus auf Azure SQL Managed Instance Link, und wählen Sie Failover... , um den Assistenten Failover zwischen SQL Server und verwaltete Instanz zu öffnen. Wenn Sie über mehrere Verknüpfungen aus derselben Datenbank verfügen, erweitern Sie Verfügbarkeitsgruppen unter Always On-Verfügbarkeitsgruppen in Objekt-Explorer, und klicken Sie mit der rechten Maustaste auf die verteilte Verfügbarkeitsgruppe, über die Sie ein Failover durchführen möchten. Wählen Sie Failover... , um den 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 Planed Failover aus.

5. Auf der Seite Sign to Azure and Remote Instance:

   1. Wählen Sie Sign-in 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 planiertes 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 operations unterscheiden sich die Optionen zwischen SQL Server 2022 und früheren Versionen und ob Sie eine Verbindung mit der primären Instanz herstellen konnten.

   • Für SQL Server 2022 können Sie die Replikation zwischen Replikationen beenden, wodurch die Verknüpfung und die verteilte Verfügbarkeitsgruppe nach Abschluss des Failovers unterbrochen wird. Wenn Sie die Verknüpfung aufrechterhalten und die Datenreplikation zwischen Replikaten fortsetzen möchten, lassen Sie das Kontrollkästchen nicht aktiviert. Wenn Sie den Link ablegen möchten, können Sie auch das Kontrollkästchen aktivieren, um die Verfügbarkeitsgruppe abzulegen, wenn Sie sie ausschließlich zum Zweck der Replikation Ihrer Datenbank auf Azure erstellt haben und 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 Verbindung entfernen standardmäßig aktiviert, und Sie können sie nicht deaktivieren, da ein SQL Managed Instance die Replikation beendet, die Verbindung unterbricht und die Verteilte Verfügbarkeitsgruppe entfernt. 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 auf der SQL Server Instanz nach einem erzwungenen Failover zu löschen, indem Sie das Kontrollkästchen im Abschnitt Clean-up 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. Wählen Sie Fertig stellen, wenn Sie bereit sind, die Datenbank auf Failover umzustellen.

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 sich entschieden haben, den Link für SQL Server 2022 beizubehalten, wird die Sekundäre zur neuen Primären, die Verknüpfung ist weiterhin aktiv, und Sie können auf die Sekundäre zurückschalten.

Wenn Sie SQL Server 2019 und früheren 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 durchzuführen, müssen Sie zunächst die Replikationsmodi der SQL Server Instanz mithilfe von Transact-SQL (T-SQL) wechseln.

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

Replikationsmodus wechseln (Failover zu SQL MI)

Die Replikation zwischen SQL Server und SQL Managed Instance ist standardmäßig asynchron. Bevor Sie die Umschaltung Ihrer Datenbank von SQL Server zu Azure SQL Managed Instance durchführen, schalten Sie den Link auf SQL Server mit Transact-SQL (T-SQL) in den synchronen Modus.

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

• <DAGName> mit dem Namen der verteilten Verfügbarkeitsgruppe (der zur Erstellung des Links verwendet wird)
• <AGName> mit dem Namen der Verfügbarkeitsgruppe, die auf SQL Server erstellt wurde (wird zum Erstellen des Links verwendet).
• <ManagedInstanceName> mit dem 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 Sie nun SQL Server in den synchronen Commitmodus gewechselt haben, ist 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 von LSN-Werten für SQL Server und SQL Managed Instance

Um das Failover oder die Migration abzuschließen, bestätigen Sie, dass die Replikation auf das sekundäre System abgeschlossen wurde. Stellen Sie dafür sicher, dass die Protokollsequenznummern (LSNs) in den Protokolldatensätzen für SQL Server und 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, werden die LSNs übereinstimmen und sich nach einer Weile nicht mehr ändern.

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

• <DatabaseName> durch Ihren Datenbanknamen und suchen Sie nach der zuletzt gefestigten LSN-Nummer.

-- 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 den letzten gehärteten LSN für Ihre Datenbank zu lesen. Ersetzen Sie <DatabaseName> durch den Namen der Datenbank.

Diese Abfrage funktioniert auf einer Allzweck-SQL Managed Instance. Für eine Business Critical SQL Managed Instance kommentieren Sie and drs.is_primary_replica = 1 am Ende des Skripts aus. 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 Befehl Get-AzSqlInstanceLink PowerShell oder az sql mi link show Azure CLI verwenden, um die eigenschaft LastHardenedLsn für Ihren Link auf SQL Managed Instance abzurufen, um dieselben Informationen wie die vorherige T-SQL-Abfrage bereitzustellen.

Durchführung eines Failovers einer Datenbank

Wenn Sie PowerShell verwenden möchten, um eine Datenbank zwischen SQL Server 2022 und SQL Managed Instance unter Beibehaltung der Verknüpfung fehlzuschlagen oder ein Failover mit Datenverlust für eine beliebige Version von SQL Server durchzuführen, verwenden Sie den Failover zwischen SQL Server und verwaltete Instanz-Assistent in SSMS, um das Skript für Ihre Umgebung zu generieren. 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.

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

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> mit dem Namen Ihrer verwalteten Instanz.
• <DAGName> durch den Namen des Links, den Sie zum Ausweichen verwenden (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 SQL Managed Instance Datenbank können Lese-/Schreibarbeitslasten ausführen, da sie jetzt 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 distributed 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> mit dem Namen der verteilten Verfügbarkeitsgruppe auf SQL Server (wird zum Erstellen des Links verwendet).

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