Verlinkung Failover ausführen – Azure SQL Managed Instance

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:

• 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.

Transact-SQL

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

SQL Server Management Studio (SSMS)

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.

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 ein erzwungenes Failover ausführen, können Daten verloren gehen.
• 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.

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.

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.

PowerShell

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

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 

declare @link_name varchar(max) = '<DAGName>' 
USE MASTER 
GO

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:

• Vorbereiten der Umgebung für einen Managed Instance-Link
• Konfigurieren der Verknüpfung zwischen SQL Server und SQL Managed Instance mit SSMS
• Konfigurieren der Verknüpfung zwischen SQL Server und SQL Managed Instance mit Skripten
• Migrieren mit dem Link
• Bewährte Methoden zum Verwalten des Links

Weitere Informationen zum Link finden Sie unter:

• Übersicht der verwalteten Instanz-Links
• Notfallwiederherstellung mit Managed Instance Link

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter:

• Transaktionsreplikation mit SQL Managed Instance
• Protokollwiedergabedienst (Log Replay Service, LRS)