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
Azure SQL Managed Instance