Konfigurieren von Verknüpfungen mit Skripten – Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie eine Verbindung zwischen SQL Server und Azure SQL Managed Instance mit Transact-SQL und PowerShell oder Azure CLI-Skripten konfigurieren. Mit dem Link werden die Datenbanken von Ihrer primären Datenbank nahezu in Echtzeit auf Ihr sekundäres Replikat repliziert.

Nachdem die Verknüpfung erstellt wurde, können Sie zum Zwecke der Migration oder der Notfallwiederherstellung einen Failover zu Ihrer sekundären Replikation ausführen.

Hinweis

Überblick

Verwenden Sie das Linkfeature, um Datenbanken von Ihrem primären auf Ihr sekundäres Replikat zu replizieren. Für SQL Server 2022 kann die anfängliche Primärinstanz entweder SQL Server oder Azure SQL Managed Instance sein. Für SQL Server 2019 und frühere Versionen muss der ursprüngliche Primärserver SQL Server sein. Nachdem die Verknüpfung konfiguriert wurde, werden die Datenbanken des ursprünglichen primären Systems auf das sekundäre Replikat repliziert.

Sie können den Link für eine kontinuierliche Datenreplikation in einer hybriden Umgebung zwischen dem primären und dem sekundären Replikat bestehen lassen oder die Datenbank auf das sekundäre Replikat auslagern, um zu Azure zu migrieren oder für eine Notfallwiederherstellung. Bei SQL Server 2019 und früheren Versionen unterbricht der Failover zu Azure SQL Managed Instance die Verbindung und der Failback wird nicht unterstützt. Mit SQL Server 2022 haben Sie die Möglichkeit, die Verbindung aufrechtzuerhalten und zwischen den beiden Replikaten hin und her zu wechseln – diese Funktion befindet sich derzeit in Planung.

Wenn Sie planen, Ihre sekundäre verwaltete Instanz nur für die Notfallwiederherstellung zu verwenden, können Sie Lizenzkosten sparen, indem Sie den hybrider Failover-Vorteil aktivieren.

Richten Sie mithilfe der Anweisungen in diesem Artikel den Link zwischen SQL Server-Instanz und Azure SQL Managed Instance manuell ein. Nachdem die Verknüpfung erstellt wurde, erhält Ihre Quelldatenbank eine schreibgeschützte Kopie auf dem sekundären Zielreplikat.

Tipp

  • Um die Verwendung von T-SQL-Skripts mit den richtigen Parametern für Ihre Umgebung zu vereinfachen, wird dringend empfohlen, den Assistenten für Links für verwaltete Instanzen in SQL Server Management Studio (SSMS) zu verwenden, um ein Skript zum Erstellen des Links zu generieren. Wählen Sie im Fenster Neuer Link für verwaltete Instanz auf der Seite Zusammenfassung die Option Skript anstelle von Fertig stellen aus.

Voraussetzungen

Hinweis

Einige der Funktionen der Verbindung sind allgemein verfügbar, während sich andere derzeit in der Vorschauversion befinden. Sie auch Versionsunterstützung, um mehr zu erfahren.

Um Ihre Datenbanken zu replizieren, benötigen Sie die folgenden Voraussetzungen:

Beachten Sie Folgendes:

  • Das Linkfeature unterstützt jeweils eine Datenbank pro Link. Wenn Sie mehrere Datenbanken für eine Instanz replizieren möchten, muss jeweils ein Link pro Datenbank erstellt werden. Wenn Sie also beispielsweise zehn Datenbanken in SQL Managed Instance replizieren möchten, müssen zehn einzelne Links erstellt werden.
  • Die Sortierung zwischen SQL Server und SQL Managed Instance sollte identisch sein. Ein Konflikt bei der Sortierung kann zu einem Konflikt bei der Groß-/Kleinschreibung des Servernamens führen und eine erfolgreiche Verbindungsherstellung zwischen SQL Server und SQL Managed Instance verhindern.
  • Der Fehler 1475 auf Ihrem ursprünglichen SQL Server-Primärserver zeigt an, dass Sie eine neue Sicherungskette starten müssen, indem Sie eine vollständige Sicherung ohne die Option COPY ONLY erstellen.

Berechtigungen

Für SQL Server sollten Sie über sysadmin-Berechtigungen verfügen.

Für Azure SQL Managed Instance sollten Sie Mitglied der Rolle Mitwirkender für SQL Managed Instance sein oder über die folgenden Berechtigungen für eine benutzerdefinierte Rolle verfügen:

Microsoft.Sql/resource Erforderliche Berechtigungen
Microsoft.Sql/managedInstances /read, /write
Microsoft.Sql/managedInstances/hybridCertificate /action
Microsoft.Sql/managedInstances/databases /read, /delete, /write, /completeRestore/action, /readBackups/action, /restoreDetails/read
Microsoft.Sql/managedInstances/distributedAvailabilityGroups /read, /write, /delete, /setRole/action
Microsoft.Sql/managedInstances/endpointCertificates /read
Microsoft.Sql/managedInstances/hybridLink /read, /write, /delete
Microsoft.Sql/managedInstances/serverTrustCertificates /write, /delete, /read

Terminologie und Benennungskonventionen

Beim Ausführen von Skripts aus dieser Anleitung für Benutzer ist es wichtig, die Namen von SQL Server und SQL Managed Instance nicht mit den zugehörigen vollqualifizierten Domänennamen (Fully Qualified Domain Names, FQDNs) zu verwechseln. Die folgende Tabelle zeigt, was die verschiedenen Namen genau darstellen und wie Sie die jeweiligen Werte erhalten:

Begriff BESCHREIBUNG Ermitteln des Werts
Ursprüngliche Primärinstanz1 Der SQL Server oder die SQL Managed Instance, auf dem/der Sie die Verknüpfung zur Replikation Ihrer Datenbank auf das sekundäre Replikat erstellen.
Primäres Replikat Der SQL Server oder die SQL Managed Instance, der/die derzeit die primäre Datenbank hostet.
Sekundäres Replikat Der SQL Server oder die SQL Managed Instance, der/die nahezu in Echtzeit replizierte Daten von der aktuellen primären Replikation erhält.
SQL Server-Name Kurzer SQL Server-Name aus einzelnem Wort Bespiel: sqlserver1. Führen Sie SELECT @@SERVERNAME über T-SQL aus.
SQL Server-FQDN Vollqualifizierter Domänenname (FQDN) Ihrer SQL Server-Instanz. z. B. sqlserver1.domain.com. Sehen Sie sich Ihre lokale Netzwerkkonfiguration (DNS) oder den Servernamen an, wenn Sie einen virtuellen Azure-Computer (Virtual Machine, VM) verwenden.
Name der verwalteten Instanz Kurzer SQL Managed Instance-Name aus einzelnem Wort z. B. managedinstance1. Sehen Sie sich den Namen Ihrer verwalteten Instanz im Azure-Portal an.
SQL Managed Instance-FQDN Vollqualifizierter Domänenname (FQDN) der SQL Managed Instance z. B. managedinstance1.6d710bcf372b.database.windows.net. Sehen Sie sich den Hostnamen auf der SQL Managed Instance-Übersichtsseite im Azure-Portal an.
Auflösbarer Domänenname DNS-Name, der in eine IP-Adresse aufgelöst werden kann. Beispielsweise sollte die Ausführung von nslookup sqlserver1.domain.com eine IP-Adresse wie 10.0.0.1 zurückgeben. Führen Sie nslookup über die Eingabeaufforderung aus.
SQL Server-IP-Adresse IP-Adresse Ihrer SQL Server-Instanz. Bei mehreren IP-Adressen unter SQL Server wählen Sie die IP-Adresse aus, auf die von Azure aus zugegriffen werden kann. Führen Sie den Befehl ipconfig über die Eingabeaufforderung des Hostbetriebssystems aus, unter dem die SQL Server-Instanz ausgeführt wird.

1 Das Konfigurieren von Azure SQL Managed Instance als erste primäre Instanz befindet sich derzeit in Planung und wird ab dem SQL Server 2022 CU10 nur unterstützt.

Einrichten der Datenbankwiederherstellung und -sicherung

Wenn SQL Server Ihr ursprünglicher Primärserver ist, müssen die Datenbanken, die über den Link repliziert werden sollen, müssen sich im vollständigen Wiederherstellungsmodus befinden und über mindestens eine Sicherung verfügen. Da Azure SQL Managed Instance automatisch Backups erstellt, können Sie diesen Schritt überspringen, wenn SQL Managed Instance Ihre erste Primärinstanz ist. primary

Führen Sie den folgenden Code auf der SQL Server-Instanz für alle Datenbanken aus, die Sie replizieren möchten. Ersetzen Sie <DatabaseName> durch den eigentlichen Namen der Datenbank.

-- Run on SQL Server
-- Set full recovery model for all databases you want to replicate.
ALTER DATABASE [<DatabaseName>] SET RECOVERY FULL
GO

-- Execute backup for all databases you want to replicate.
BACKUP DATABASE [<DatabaseName>] TO DISK = N'<DiskPath>'
GO

Weitere Informationen finden Sie unter Erstellen einer vollständigen Datenbanksicherung.

Hinweis

Die Verbindung unterstützt nur die Replikation von Benutzerdatenbanken. Die Replikation von Systemdatenbanken wird nicht unterstützt. Um (in den Datenbanken master oder msdb gespeicherte) Objekte auf Instanzebene zu replizieren, wird empfohlen, dafür T-SQL-Skripts zu erstellen und in der Zielinstanz auszuführen.

Einrichten der Vertrauensstellung zwischen Instanzen

Zunächst müssen Sie Vertrauen zwischen den beiden Instanzen herstellen und die Endpunkte sichern, die für die Kommunikation und die Verschlüsselung von Daten im Netzwerk verwendet werden. Verteilte Verfügbarkeitsgruppen verwenden anstatt eines eigenen dedizierten Endpunkts den vorhandenen Datenbankspiegelungsendpunkt für Verfügbarkeitsgruppen. Aus diesem Grund müssen Sicherheit und Vertrauensstellung zwischen den beiden Instanzen über den Endpunkt für die Datenbankspiegelung für Verfügbarkeitsgruppen konfiguriert werden.

Hinweis

Der Link basiert auf der Technologie von Always On-Verfügbarkeitsgruppen. Der Endpunkt für die Datenbankspiegelung ist ein spezieller Endpunkt, der ausschließlich von Verfügbarkeitsgruppen verwendet wird, um Verbindungen von anderen Instanzen zu empfangen. Der Begriff Datenbankspiegelungsendpunkt sollte nicht mit der alten SQL Server-Feature zur Datenbankspiegelung verwechselt werden.

Die zertifikatbasierte Vertrauensstellung ist die einzige unterstützte Methode zum Schutz von Endpunkte für die Datenbankspiegelung in SQL Server und SQL Managed Instance. Wenn Verfügbarkeitsgruppen mit Windows-Authentifizierung vorhanden sind, muss die zertifikatbasierte Vertrauensstellung dem vorhandenen Spiegelungsendpunkt als sekundäre Authentifizierungsoption hinzugefügt werden. Sie können dies mithilfe der ALTER ENDPOINT-Anweisung erreichen, wie weiter unten in diesem Artikel beschrieben.

Wichtig

Zertifikate werden mit einem Ablaufdatum und einer Ablaufzeit generiert. Sie müssen erneuert und gedreht werden, bevor sie ablaufen.

Im Anschluss finden Sie eine Übersicht über die Vorgehensweise zum Schützen von Datenbankspiegelungsendpunkten für SQL Server und SQL Managed Instance:

  1. Generieren Sie ein Zertifikat in SQL Server, und rufen Sie den zugehörigen öffentlichen Schlüssel ab.
  2. Rufen Sie einen öffentlichen Schlüssel des SQL Managed Instance-Zertifikats ab.
  3. Tauschen Sie die öffentlichen Schlüssel zwischen SQL Server und SQL Managed Instance aus.
  4. Importieren von in Azure vertrauenswürdigen Stammzertifizierungsstellenschlüsseln in SQL Server

In den folgenden Abschnitten werden diese Schritte ausführlich behandelt.

Erstellen eines Zertifikats in SQL Server und Importieren des zugehörigen öffentlichen Schlüssels in SQL Managed Instance

Erstellen Sie zunächst den Hauptschlüssel der Datenbank in der master-Datenbank, falls noch nicht vorhanden. Geben Sie Ihr Kennwort anstelle von <strong_password> in das nachfolgende Skript ein, und bewahren Sie es an einem vertraulichen und sicheren Ort auf. Führen Sie dieses T-SQL-Skript unter SQL Server aus:

-- Run on SQL Server
-- Create a master key encryption password
-- Keep the password confidential and in a secure place
USE MASTER
IF NOT EXISTS (SELECT * FROM sys.symmetric_keys WHERE symmetric_key_id = 101)
BEGIN
    PRINT 'Creating master key.' + CHAR(13) + 'Keep the password confidential and in a secure place.'
    CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<strong_password>'
END
ELSE
    PRINT 'Master key already exists.'
GO

Generieren Sie dann ein Authentifizierungszertifikat auf der SQL Server-Instanz. Ersetzen Sie im folgenden Code Folgendes:

  • @cert_expiry_date durch das gewünschte Ablaufdatum des Zertifikats (zukünftiges Datum).

Notieren Sie sich dieses Datum, und legen Sie eine Erinnerung fest, um das SQL-Serverzertifikat vor seinem Ablaufdatum zu erneuern (zu aktualisieren), um die kontinuierliche Funktion des Links sicherzustellen.

Wichtig

Es wird dringend empfohlen, den automatisch generierten Zertifikatsnamen aus diesem Skript zu verwenden. Das Anpassen Ihres eigenen Zertifikatsnamens in SQL Server ist zwar zulässig, aber dieser Name sollte keine \-Zeichen enthalten.

-- Create the SQL Server certificate for the instance link
USE MASTER

-- Customize SQL Server certificate expiration date by adjusting the date below
DECLARE @cert_expiry_date AS varchar(max)='03/30/2025'

-- Build the query to generate the certificate
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @sqlserver_certificate_subject NVARCHAR(MAX) = N'Certificate for ' + @sqlserver_certificate_name
DECLARE @create_sqlserver_certificate_command NVARCHAR(MAX) = N'CREATE CERTIFICATE [' + @sqlserver_certificate_name + '] ' + char (13) +
'    WITH SUBJECT = ''' + @sqlserver_certificate_subject + ''',' + char (13) +
'    EXPIRY_DATE = '''+ @cert_expiry_date + ''''+ char (13)
IF NOT EXISTS (SELECT name from sys.certificates WHERE name = @sqlserver_certificate_name)
BEGIN
    PRINT (@create_sqlserver_certificate_command)
    -- Execute the query to create SQL Server certificate for the instance link
    EXEC sp_executesql @stmt = @create_sqlserver_certificate_command
END
ELSE
    PRINT 'Certificate ' + @sqlserver_certificate_name + ' already exists.'
GO

Verwenden Sie dann die folgende T-SQL-Abfrage in SQL Server, um zu überprüfen, ob das Zertifikat erstellt wurde:

-- Run on SQL Server
USE MASTER
GO
SELECT * FROM sys.certificates WHERE pvt_key_encryption_type = 'MK'

In den Abfrageergebnissen sehen Sie, dass das Zertifikat mit dem Hauptschlüssel verschlüsselt wurde.

Nun können Sie den öffentlichen Schlüssel des generierten Zertifikats in SQL Server abrufen:

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
DECLARE @PUBLICKEYENC VARBINARY(MAX) = CERTENCODED(CERT_ID(@sqlserver_certificate_name));
SELECT @sqlserver_certificate_name as 'SQLServerCertName'
SELECT @PUBLICKEYENC AS SQLServerPublicKey;

Speichern Sie die Werte von SQLServerCertName und SQLServerPublicKey aus der Ausgabe. da Sie diese für den nächsten Schritt benötigen, wenn Sie das Zertifikat importieren.

Vergewissern Sie sich zunächst, dass Sie bei Azure angemeldet sind und dass Sie das Abonnement ausgewählt haben, in dem Ihre verwaltete Instanz gehostet wird. Die Auswahl des richtigen Abonnements ist besonders wichtig, wenn Sie über mehr als ein Azure-Abonnement in Ihrem Konto verfügen.

Ersetzen Sie <SubscriptionID> durch Ihre Azure-Abonnement-ID.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Verwenden Sie dann entweder den PowerShell-Befehl New-AzSqlInstanceServerTrustCertificate oder den Azure CLI-Befehl az sql mi partner-cert create, um den öffentlichen Schlüssel des Authentifizierungszertifikats von SQL Server auf Azure hochzuladen, wie in dem folgenden PowerShell-Beispiel.

Füllen Sie die erforderlichen Benutzerinformationen aus, kopieren Sie sie, fügen Sie sie ein, und führen Sie dann das Skript aus. Ersetzen Sie:

  • <SQLServerPublicKey> durch den öffentlichen Teil des SQL Server-Zertifikats im Binärformat, das Sie im vorherigen Schritt aufgezeichnet haben. (ein langer Zeichenfolgenwert, der mit 0x beginnt)
  • <SQLServerCertName> durch den Namen des SQL Server-Zertifikats, das Sie im vorherigen Schritt aufgezeichnet haben.
  • <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO IMPORT SQL SERVER PUBLIC CERTIFICATE TO SQL MANAGED INSTANCE
# ===== Enter user variables here ====

# Enter the name for the server SQLServerCertName certificate – for example, "Cert_sqlserver1_endpoint"
$CertificateName = "<SQLServerCertName>"

# Insert the certificate public key blob that you got from SQL Server – for example, "0x1234567..."
$PublicKeyEncoded = "<SQLServerPublicKey>"

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

# ==== Do not customize the below cmdlets====

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

# Upload the public key of the authentication certificate from SQL Server to Azure.
New-AzSqlInstanceServerTrustCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $CertificateName -PublicKey $PublicKeyEncoded

Das Ergebnis dieses Vorgangs ist eine Zusammenfassung des in Azure hochgeladenen SQL Server-Zertifikats.

Wenn Sie alle auf eine verwaltete Instanz hochgeladenen SQL Server-Zertifikate sehen möchten, verwenden Sie den PowerShell-Befehl Get-AzSqlInstanceServerTrustCertificate oder den Azure CLI-Befehl az sql mi partner-cert list in Azure Cloud Shell. Um das auf einer SQL Managed Instance hochgeladene SQL Server-Zertifikat zu entfernen, verwenden Sie den PowerShell-Befehl Remove-AzSqlInstanceServerTrustCertificate oder den Azure CLI-Befehl az sql mi partner-cert delete in Azure Cloud Shell.

Abrufen des öffentlichen Schlüssels des Zertifikats von SQL Managed Instance und Importieren des Schlüssels in SQL Server

Das Zertifikat zum Schutz des Linkendpunkts wird automatisch in Azure SQL Managed Instance generiert. Holen Sie sich den öffentlichen Schlüssel des Zertifikats von SQL Managed Instance und importieren Sie ihn in SQL Server, indem Sie den PowerShell-Befehl Get-AzSqlInstanceEndpointCertificate oder den Azure CLI-Befehl az sql mi endpoint-cert show verwenden, siehe auch das folgende PowerShell-Beispiel.

Achtung

Wenn Sie die Azure-Befehlszeilenschnittstelle verwenden, müssen Sie vor der PublicKey-Ausgabe 0x hinzufügen, falls Sie diese in den folgenden Schritten verwenden möchten. Der PublicKey ähnelt „0x3082033E30...“.

Führen Sie das folgende Skript aus. Ersetzen Sie:

  • <SubscriptionID> durch Ihre Azure-Abonnement-ID
  • <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz
# Run in Azure Cloud Shell (select PowerShell console)
# ===============================================================================
# POWERSHELL SCRIPT TO EXPORT MANAGED INSTANCE PUBLIC CERTIFICATE
# ===== Enter user variables here ====

# Enter your managed instance short name – for example, "sqlmi"
$ManagedInstanceName = "<ManagedInstanceName>"

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

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

# Fetch the public key of the authentication certificate from Managed Instance. Outputs a binary key in the property PublicKey.
Get-AzSqlInstanceEndpointCertificate -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -EndpointType "DATABASE_MIRRORING" | out-string

Kopieren Sie die gesamte PublicKey-Ausgabe (beginnt mit 0x), da Sie sie im nächsten Schritt benötigen.

Wenn Sie Probleme haben, den PublicKey zu kopieren, können Sie alternativ auch den T-SQL-Befehl EXEC sp_get_endpoint_certificate 4 in der verwalteten Instanz ausführen, um den öffentlichen Schlüssel für den Linkendpunkt zu erhalten.

Als Nächstes importieren Sie den öffentlichen Schlüssel des Sicherheitszertifikats der verwalteten Instanz in SQL Server. Führen Sie die folgende Abfrage in SQL Server aus. Ersetzen Sie:

  • <ManagedInstanceFQDN> durch den vollqualifizierten Domänennamen der verwalteten Instanz
  • <PublicKey> durch den PublicKey-Wert, der im vorherigen Schritt abgerufen wurde (aus Azure Cloud Shell, beginnend mit 0x) Sie müssen keine Anführungszeichen verwenden.

Wichtig

Der Name des Zertifikats muss der SQL Managed Instance-FQDN sein und sollte nicht geändert werden. Der Link ist nicht funktionsfähig, wenn Sie einen benutzerdefinierten Namen verwenden.

-- Run on SQL Server
USE MASTER
CREATE CERTIFICATE [<ManagedInstanceFQDN>]
FROM BINARY = <PublicKey>

Importieren von in Azure vertrauenswürdigen Stammzertifizierungsstellenschlüsseln in SQL Server

Der Import von öffentlichen Stammzertifikatsschlüsseln der Zertifizierungsstellen von Microsoft und DigiCert in SQL Server ist erforderlich, damit Ihre SQL Server-Instanz den von Azure für „datenbank.windows.net“-Domänen ausgestellten Zertifikaten vertraut.

Achtung

Stellen Sie sicher, dass der PublicKey mit 0x beginnt. Möglicherweise müssen Sie die Zeichen manuell am Anfang des PublicKey hinzufügen, wenn sie noch nicht vorhanden sind.

Importieren Sie zunächst das Microsoft PKI-Zertifikat der Stammzertifizierungsstelle in SQL Server:

-- Run on SQL Server
-- Import Microsoft PKI root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'MicrosoftPKI')
BEGIN
    PRINT 'Creating MicrosoftPKI certificate.'
    CREATE CERTIFICATE [MicrosoftPKI] FROM BINARY = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3

    --Trust certificates issued by Microsoft PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('MicrosoftPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate MicrosoftPKI already exsits.'
GO

Importieren Sie dann das DigiCert PKI-Zertifikat der Stammzertifizierungsstelle in SQL Server:

-- Run on SQL Server
-- Import DigiCert PKI root-authority certificate trusted by Azure to SQL Server, if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'DigiCertPKI')
BEGIN
    PRINT 'Creating DigiCertPKI certificate.'
    CREATE CERTIFICATE [DigiCertPKI] FROM BINARY = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D0

    --Trust certificates issued by DigiCert PKI root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('DigiCertPKI')
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate DigiCertPKI already exsits.'
GO

Überprüfen Sie abschließend alle erstellten Zertifikate mithilfe der folgenden dynamischen Verwaltungssicht (Dynamic Management View, DMV):

-- Run on SQL Server
SELECT * FROM sys.certificates

Schützen des Endpunkts für die Datenbankspiegelung

Wenn Sie weder über eine Verfügbarkeitsgruppe noch über einen Endpunkt für die Datenbankspiegelung in SQL Server verfügen, besteht der nächste Schritt darin, einen Endpunkt für die Datenbankspiegelung für SQL Server zu erstellen und mit dem zuvor generierten SQL Server-Zertifikat zu schützen. Wenn Sie bereits eine Verfügbarkeitsgruppe oder einen Spiegelungsendpunkt haben, fahren Sie mit dem Abschnitt Ändern eines bestehenden Endpunkts fort.

Erstellen und Schützen des Endpunkts für die Datenbankspiegelung in SQL Server

Vergewissern Sie sich mithilfe des folgenden Skripts, dass Sie über keinen vorhandenen Datenbankspiegelungsendpunkt verfügen:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT * FROM sys.database_mirroring_endpoints WHERE type_desc = 'DATABASE_MIRRORING'

Wenn die vorangegangene Abfrage keinen vorhandenen Endpunkt für die Datenbankspiegelung ausgibt, führen Sie das folgende Skript in SQL Server aus, um den Namen des zuvor generierten SQL Server-Zertifikats zu erhalten.

-- Run on SQL Server
-- Show the name and the public key of generated SQL Server certificate
USE MASTER
GO
DECLARE @sqlserver_certificate_name NVARCHAR(MAX) = N'Cert_' + @@servername  + N'_endpoint'
SELECT @sqlserver_certificate_name as 'SQLServerCertName'

Speichern Sie SQLServerCertName aus der Ausgabe, da Sie dies im nächsten Schritt benötigen.

Verwenden Sie das folgende Skript, um einen neuen Datenbankspiegelungsendpunkt an Port 5022 zu erstellen und den Endpunkt mit dem SQL Server-Zertifikat zu schützen. Ersetzen Sie:

  • <SQL_SERVER_CERTIFICATE> durch den Namen von SQLServerCertName, den Sie im vorherigen Schritt erhalten haben
-- Run on SQL Server
-- Create a connection endpoint listener on SQL Server
USE MASTER
CREATE ENDPOINT database_mirroring_endpoint
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Vergewissern Sie sich, dass der Spiegelungsendpunkt erstellt wurde, indem Sie das folgende Skript in SQL Server ausführen:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc,
    connection_auth_desc, is_encryption_enabled, encryption_algorithm_desc
FROM 
    sys.database_mirroring_endpoints

Die erfolgreich erstellte Endpunktspalte „state_desc“ sollte den Wert STARTED aufweisen.

Ein neuer Spiegelungsendpunkt mit Zertifikatauthentifizierung und aktivierter AES-Verschlüsselung wurde erstellt.

Ändern eines vorhandenen Endpunkts

Hinweis

Überspringen Sie diesen Schritt, wenn Sie soeben einen neuen Spiegelungsendpunkt erstellt haben. Führen Sie diesen Schritt nur aus, wenn Sie vorhandene Verfügbarkeitsgruppen mit einem vorhandenen Datenbankspiegelungsendpunkt verwenden.

Wenn Sie vorhandene Verfügbarkeitsgruppen für den Link verwenden oder ein Datenbankspiegelungsendpunkt vorhanden ist, vergewissern Sie sich zunächst, dass er die folgenden obligatorischen Bedingungen für den Link erfüllt:

  • Der Typ muss DATABASE_MIRRORING sein.
  • Die Verbindungsauthentifizierung muss CERTIFICATE sein.
  • Die Verschlüsselung muss aktiviert sein.
  • Der Verschlüsselungsalgorithmus muss AES sein.

Führen Sie die folgende Abfrage in SQL Server aus, um die Details für einen vorhandenen Datenbankspiegelungsendpunkt anzuzeigen:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Wenn die Ausgabe für den vorhandenen Endpunkt vom Typ DATABASE_MIRRORING zeigt, dass connection_auth_desc nicht CERTIFICATE oder encryption_algorthm_desc nicht AES ist, muss der Endpunkt geändert werden, um die Anforderungen zu erfüllen.

In SQL Server wird der gleiche Datenbankspiegelungsendpunkt sowohl für Verfügbarkeitsgruppen als auch für verteilte Verfügbarkeitsgruppen verwendet. Wenn Ihr connection_auth_desc-Endpunkt NTLM (Windows-Authentifizierung) oder KERBEROS ist und Sie die Windows-Authentifizierung für eine vorhandene Verfügbarkeitsgruppe benötigen, können Sie die Authentifizierungsoption für den Endpunkt in NEGOTIATE CERTIFICATE ändern, um mehrere Authentifizierungsmethoden zu verwenden. Dadurch kann die vorhandene Verfügbarkeitsgruppe die Windows-Authentifizierung verwenden, während für SQL Managed Instance die Zertifikatauthentifizierung verwendet wird.

Ebenso ist es möglich, den Endpunkt so zu ändern, dass beide Algorithmen verwendet werden, wenn die Verschlüsselung keine AES-Verschlüsselung umfasst und die RC4-Verschlüsselung benötigt wird. Ausführliche Informationen zu möglichen Änderungsoptionen für Endpunkte finden Sie auf der Dokumentationsseite für „sys.database_mirroring_endpoints“.

Das folgende Skript ist ein Beispiel für die Anpassung Ihres vorhandenen Datenbankspiegelungsendpunkts in SQL Server. Ersetzen Sie:

  • <YourExistingEndpointName> durch den Namen des vorhandenen Endpunkts
  • <SQLServerCertName> durch den Namen des generierten SQL Server-Zertifikats (das Sie in einem der vorherigen Schritte erhalten haben)

Abhängig von Ihrer spezifischen Konfiguration muss das Skript ggf. weiter angepasst werden. Sie können auch SELECT * FROM sys.certificates verwenden, um den Namen des erstellten Zertifikats in SQL Server abzurufen.

-- Run on SQL Server
-- Alter the existing database mirroring endpoint to use CERTIFICATE for authentication and AES for encryption
USE MASTER
ALTER ENDPOINT [<YourExistingEndpointName>]   
    STATE=STARTED   
    AS TCP (LISTENER_PORT=5022, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Verwenden Sie diese Abfrage in SQL Server erneut, um die Details für den Datenbankspiegelungsendpunkt anzuzeigen, nachdem Sie die ALTER-Endpunktabfrage ausgeführt und den dualen Authentifizierungsmodus mit Windows und Zertifikat festgelegt haben:

-- Run on SQL Server
-- View database mirroring endpoints on SQL Server
SELECT
    name, type_desc, state_desc, role_desc, connection_auth_desc,
    is_encryption_enabled, encryption_algorithm_desc
FROM
    sys.database_mirroring_endpoints

Damit haben Sie Ihren Datenbankspiegelungsendpunkt für einen SQL Managed Instance-Link erfolgreich geändert.

Erstellen einer Verfügbarkeitsgruppe in SQL Server

Wenn Sie noch keine Verfügbarkeitsgruppe haben, müssen Sie im nächsten Schritt eine auf dem SQL Server erstellen, unabhängig davon, welcher Server die erste Primärinstanz sein wird. Die Befehle zur Erstellung der Verfügbarkeitsgruppe unterscheiden sich, wenn Ihre SQL Managed Instance die erste Primärinstanz ist, was erst ab SQL Server 2022 CU10 unterstützt wird.

Es ist zwar möglich, mehrere Links für dieselbe Datenbank zu erstellen, aber der Link unterstützt nur die Replikation einer Datenbank pro Link. Wenn Sie mehrere Verknüpfungen für dieselbe Datenbank erstellen möchten, verwenden Sie dieselbe Verfügbarkeitsgruppe für alle Verknüpfungen, erstellen dann aber für jede Datenbankverknüpfung zwischen SQL Server und SQL Managed Instance eine neue verteilte Verfügbarkeitsgruppe.

Wenn SQL Server Ihre ursprüngliche Primärinstanz ist, erstellen Sie eine Verfügbarkeitsgruppe mit den folgenden Parametern für eine Verknüpfung:

  • Ursprünglicher Primärservername
  • Datenbankname
  • Failovermodus MANUAL
  • Seedingmodus AUTOMATIC

Ermitteln Sie zunächst mithilfe der folgenden T-SQL-Anweisung Ihren SQL Server-Namen:

-- Run on the initial primary
SELECT @@SERVERNAME AS SQLServerName

Verwenden Sie dann das folgende Skript, um die Verfügbarkeitsgruppe in SQL Server zu erstellen. Ersetzen Sie:

  • <AGName> durch den Namen Ihrer Verfügbarkeitsgruppe. Für einen Managed Instance-Link ist jeweils eine Datenbank pro Verfügbarkeitsgruppe erforderlich. Für mehrere Datenbanken müssen mehrere Verfügbarkeitsgruppen erstellt werden. Es empfiehlt sich gegebenenfalls, die einzelnen Verfügbarkeitsgruppen jeweils so zu benennen, dass der Name die entsprechende Datenbank widerspiegelt (beispielsweise AG_<db_name>).
  • <DatabaseName> durch den Namen der Datenbank, die Sie replizieren möchten
  • <SQLServerName> durch den Namen Ihrer SQL Server-Instanz, den Sie im vorherigen Schritt erhalten haben
  • <SQLServerIP> durch die IP-Adresse von SQL Server. Alternativ kann ein auflösbarer SQL Server-Hostcomputername verwendet werden. Der Name muss jedoch über das virtuelle Netzwerk von SQL Managed Instance auflösbar sein.
-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGName>]
WITH (CLUSTER_TYPE = NONE) -- <- Delete this line for SQL Server 2016 only. Leave as-is for all higher versions.
    FOR database [<DatabaseName>]  
    REPLICA ON   
        N'<SQLServerName>' WITH   
            (  
            ENDPOINT_URL = 'TCP://<SQLServerIP>:5022',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

Wichtig

Löschen Sie WITH (CLUSTER_TYPE = NONE) für SQL Server 2016 aus der obigen T-SQL-Anweisung. Belassen Sie es für alle späteren SQL Server-Versionen unverändert.

Als Nächstes erstellen Sie eine verteilte Verfügbarkeitsgruppe auf SQL Server. Wenn Sie mehrere Links erstellen möchten, müssen Sie für jeden Link eine verteilte Verfügbarkeitsgruppe erstellen, auch wenn Sie mehrere Links für dieselbe Datenbank erstellen.

Ersetzen Sie die folgenden Werte und führen Sie dann das T-SQL-Skript aus, um Ihre verteilte Verfügbarkeitsgruppe zu erstellen.

  • <DAGName> durch den Namen Ihrer verteilten Verfügbarkeitsgruppe. Da Sie mehrere Verbindungen für dieselbe Datenbank konfigurieren können, indem Sie für jede Verbindung eine verteilte Verfügbarkeitsgruppe erstellen, sollten Sie jede verteilte Verfügbarkeitsgruppe entsprechend benennen, zum Beispiel DAG1_<db_name>, DAG2_<db_name>.
  • <AGName> durch den Namen der im vorherigen Schritt erstellten Verfügbarkeitsgruppe
  • <SQLServerIP> durch die im vorherigen Schritt ermittelte IP-Adresse von SQL Server. Sie können alternativ einen auflösbaren SQL Server-Hostcomputernamen verwenden. Stellen Sie jedoch sicher, dass der Name vom virtuellen Netzwerk von SQL Managed Instance aus auflösbar ist (erfordert die Konfiguration eines benutzerdefinierten Azure DNS für das Subnetz der verwalteten Instanz).
  • <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz
  • <ManagedInstanceFQDN> durch den vollqualifizierten Domänennamen Ihrer verwalteten Instanz
-- Run on SQL Server
-- Create a distributed availability group for the availability group and database
-- ManagedInstanceName example: 'sqlmi1'
-- ManagedInstanceFQDN example: 'sqlmi1.73d19f36a420a.database.windows.net'
USE MASTER
CREATE AVAILABILITY GROUP [<DAGName>]
WITH (DISTRIBUTED) 
    AVAILABILITY GROUP ON  
    N'<AGName>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<ManagedInstanceName>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

Überprüfen von Verfügbarkeitsgruppen

Verwenden Sie das folgende Skript, um alle Verfügbarkeitsgruppen und verteilten Verfügbarkeitsgruppen in der SQL Server-Instanz aufzulisten. An diesem Punkt muss der Zustand Ihrer Verfügbarkeitsgruppe connected lauten, und der Zustand Ihrer verteilten Verfügbarkeitsgruppen muss disconnected lauten. Der Zustand der verteilten Verfügbarkeitsgruppe ändert sich erst in connected, nachdem sie mit SQL Managed Instance verknüpft wurde.

-- Run on SQL Server
-- This will show that the availability group and distributed availability group have been created on SQL Server.
SELECT * FROM sys.availability_groups

Alternativ können Sie für die Suche nach Verfügbarkeitsgruppen und verteilten Verfügbarkeitsgruppen den Objekt-Explorer von SSMS verwenden. Erweitern Sie den Ordner Hochverfügbarkeit mit Always On und anschließend den Ordner Verfügbarkeitsgruppen.

Jetzt können Sie den Link erstellen. Die Befehle unterscheiden sich je nachdem, welche Instanz die ursprüngliche Primärinstanz ist. Verwenden Sie den PowerShell-Befehl New-AzSqlInstanceLink oder den Azure CLI-Befehl az sql mi link create, um den Link zu erstellen, wie das PowerShell-Beispiel in diesem Abschnitt zeigt. Das Erstellen der Verknüpfung von einer primären SQL Managed Instance wird derzeit von der Azure CLI nicht unterstützt.

Wenn Sie alle Links auf einer verwalteten Instanz sehen möchten, verwenden Sie den PowerShell-Befehl Get-AzSqlInstanceLink oder den Azure CLI-Befehl az sql mi link show Azure in Azure Cloud Shell.

Melden Sie sich der Einfachheit halber beim Azure-Portal an, und führen Sie das folgende Skript über Azure Cloud Shell aus. Ersetzen Sie:

  • <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz
  • <AGName> durch den Namen der Verfügbarkeitsgruppe, die in SQL Server erstellt wurde
  • <DAGName> durch den Namen der verteilten Verfügbarkeitsgruppe, die in SQL Server erstellt wurde
  • <DatabaseName> durch die Datenbank, die in der Verfügbarkeitsgruppe in SQL Server repliziert wurde
  • <SQLServerIP> durch die IP-Adresse Ihrer SQL Server-Instanz Die angegebene IP-Adresse muss für die verwaltete Instanz zugänglich sein.
#  Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO CREATE MANAGED INSTANCE LINK
# Instructs Managed Instance to join distributed availability group on SQL Server
# ===== Enter user variables here ====

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

# Enter the availability group name that was created on SQL Server
$AGName = "<AGName>"

# Enter the distributed availability group name that was created on SQL Server
$DAGName = "<DAGName>"

# Enter the database name that was placed in the availability group for replication
$DatabaseName = "<DatabaseName>"

# Enter the SQL Server IP
$SQLServerIP = "<SQLServerIP>"

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

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

# Build properly formatted connection endpoint
$SourceIP = "TCP://" + $SQLServerIP + ":5022"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGName -SecondaryAvailabilityGroupName $ManagedInstanceName |
-TargetDatabase $DatabaseName -SourceEndpoint $SourceIP

Das Ergebnis dieses Vorgangs ist ein Zeitstempel der erfolgreichen Ausführung einer Linkerstellungsanforderung.

Führen Sie die folgende Abfrage in SQL Server aus, um sich zu vergewissern, dass eine Verbindung zwischen SQL Managed Instance und SQL Server hergestellt wurde. Die Verbindung wird nicht sofort hergestellt. Es kann bis zu einer Minute dauern, bis die verteilte Verfügbarkeitsgruppe anzeigt, dass die Verbindung erfolgreich hergestellt wurde. Aktualisieren Sie die dynamische Verwaltungssicht, bis die Verbindung für das SQL Managed Instance-Replikat als CONNECTED angezeigt wird.

-- Run on SQL Server
SELECT
    r.replica_server_name AS [Replica],
    r.endpoint_url AS [Endpoint],
    rs.connected_state_desc AS [Connected state],
    rs.last_connect_error_description AS [Last connection error],
    rs.last_connect_error_number AS [Last connection error No],
    rs.last_connect_error_timestamp AS [Last error timestamp]
FROM
    sys.dm_hadr_availability_replica_states rs
    JOIN sys.availability_replicas r
    ON rs.replica_id = r.replica_id

Nachdem die Verbindung hergestellt wurde, zeigt Objekt-Explorer in SSMS die replizierte Datenbank auf dem sekundären Replikat möglicherweise zunächst im Status Wiederherstellen an, da in der ersten Seeding-Phase die vollständige Sicherung der Datenbank verschoben und vollständig gesichert wird. Nachdem die Datenbank wiederhergestellt wurde, muss die Replikation auf den neuesten Stand gebracht werden, um die beiden Datenbanken zu synchronisieren. Die Datenbank befindet sich nach Abschluss des anfänglichen Seedings nicht mehr im Zustand Wiederherstellung. Bei kleinen Datenbanken ist das Seeding möglicherweise so schnell, dass der anfängliche Zustand Wiederherstellung in SSMS gar nicht angezeigt wird.

Wichtig

  • Der Link funktioniert nur, wenn eine Netzwerkverbindung zwischen SQL Server und SQL Managed Instance besteht. Führen Sie zum Behandeln von Problemen mit der Netzwerkkonnektivität die unter Testen der Netzwerkverbindung beschriebenen Schritte aus.
  • Sichern Sie die Protokolldatei in SQL Server regelmäßig. Wenn der beanspruchte Protokollspeicherplatz 100 Prozent erreicht, wird die Replikation in SQL Managed Instance beendet, bis der beanspruchte Speicherplatz verringert wird. Es wird dringend empfohlen, Protokollsicherungen durch die Einrichtung eines täglichen Auftrags zu automatisieren. Ausführliche Informationen finden Sie unter Regelmäßiges Erstellen von Protokollsicherungen.

Beenden einer Workload

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 nachziehen und Sie können ohne Datenverlust zu Azure migrieren oder ausfallen. Obwohl die primäre Datenbank Teil einer AlwaysOn-Verfügbarkeitsgruppe ist, können Sie den schreibgeschützten Modus für sie nicht festlegen. Sie müssen sicherstellen, dass die Anwendungen vor dem Failover keine Transaktionen an das primäre Replikat übertragen.

Wechseln des Replikationsmodus

Die Replikation zwischen SQL Server und SQL Managed Instance erfolgt standardmäßig asynchron. Bevor Sie Ihre Datenbank auf den sekundären Server übertragen, wechseln Sie die Verbindung in den synchronen Modus. Die synchrone Replikation in großen Netzwerken kann Transaktionen auf dem primären Replikat verlangsamen.

Für den Wechsel vom asynchronen Modus zum synchronen Modus ist eine Änderung des Replikationsmodus in SQL Managed Instance und SQL Server erforderlich.

Wechseln des Replikationsmodus (SQL Managed Instance)

Verwenden Sie Azure PowerShell oder die Azure-Befehlszeilenschnittstelle, um den Replikationsmodus in SQL Managed Instance zu ändern.

Vergewissern Sie sich zunächst, dass Sie bei Azure angemeldet sind und dass Sie das Abonnement ausgewählt haben, in dem Ihre verwaltete Instanz gehostet wird, indem Sie den PowerShell-Befehl Select-AzSubscription oder den CLI-Befehl az account set Azure verwenden. Die Auswahl des richtigen Abonnements ist besonders wichtig, wenn Sie über mehr als ein Azure-Abonnement in Ihrem Konto verfügen.

Ersetzen Sie <SubscriptionID> im folgenden PowerShell-Beispiel durch Ihre Azure-Abonnement-ID.

# Run in Azure Cloud Shell (select PowerShell console)

# Enter your Azure subscription ID
$SubscriptionID = "<SubscriptionID>"

# Login to Azure and select subscription ID
if ((Get-AzContext ) -eq $null)
{
    echo "Logging to Azure subscription"
    Login-AzAccount
}
Select-AzSubscription -SubscriptionName $SubscriptionID

Vergewissern Sie sich, dass Sie den Namen des Links kennen, für den Sie das Failover ausführen möchten. Sie können den PowerShell-Befehl Get-AzSqlInstanceLink oder den Azure CLI-Befehl az sql mi link list verwenden.

Verwenden Sie das folgende PowerShell-Skript, um alle aktiven Links auf der SQL Managed Instance aufzulisten. Ersetzen Sie <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz.

# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO LIST ALL LINKS ON MANAGED INSTANCE
# ===== Enter user variables here ====

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

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

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

# List all links on the specified managed instance
Get-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName

Notieren Sie sich in der Ausgabe des obigen Skripts die Name-Eigenschaft des Links, für den Sie das Failover ausführen möchten.

Schalten Sie dann den Replikationsmodus auf der SQL Managed Instance für den identifizierten Link von async auf sync um, indem Sie den PowerShell-Befehl Update-AzSqlInstanceLinkz oder den Azure CLI-Befehl az sql mi link update verwenden.

In dem folgenden PowerShell-Beispiel ersetzen Sie:

  • <ManagedInstanceName> durch den Kurznamen Ihrer verwalteten Instanz
  • <DAGName> durch den Namen des Links, den Sie im vorherigen Schritt herausgefunden haben (die Name-Eigenschaft aus dem vorherigen Schritt).
# Run in Azure Cloud Shell (select PowerShell console)
# =============================================================================
# POWERSHELL SCRIPT TO SWITCH LINK REPLICATION MODE (ASYNC\SYNC)
# ===== Enter user variables here ====

# Enter the link name 
$LinkName = "<DAGName>"  

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

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

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

# Update replication mode of the specified link
Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName |
-Name $LinkName -ReplicationMode "Sync"

Der obige Befehl zeigt den Erfolg an, indem eine Zusammenfassung des Vorgangs angezeigt wird, wobei für die ReplicationMode-Eigenschaft der Wert Sync angezeigt wird.

Falls Sie diesen Vorgang rückgängig machen müssen, führen Sie das obige Skript aus, um den Replikationsmodus zu ändern. Ersetzen Sie dabei jedoch die Zeichenfolge Sync in -ReplicationMode durch Async.

Wechseln des Replikationsmodus (SQL Server)

Verwenden Sie das folgende T-SQL-Skript auf SQL Server, um den Replikationsmodus der verteilten Verfügbarkeitsgruppe unter SQL Server 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_COMIT 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 Managed Instance und SQL Server jetzt in den synchronen Modus umgeschaltet wurden, erfolgt die Replikation zwischen den beiden Instanzen synchron. Wenn Sie diesen Zustand wieder rückgängig machen möchten, folgen Sie denselben Schritten und setzen Sie den Zustand sowohl für SQL Server als auch für SQL Managed Instance auf async.

Ü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 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, können Sie davon ausgehen, dass 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 Managed Instance 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.
  • Der Failover einer Datenbank unter Beibehaltung der Verbindung zu SQL Server 2022 befindet sich derzeit in Planung.

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 eine Lese-/Schreibworkload ausführen. Sie sind vollständig unabhängig. Verweisen Sie die Verbindungszeichenfolge Ihrer Anwendung auf die Datenbank, die Sie aktiv nutzen möchten.

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.

Bereinigen von Verfügbarkeitsgruppen

Da ein Failover mit SQL Server 2022 die Verbindung nicht unterbricht, können Sie die Verbindung und die Verfügbarkeitsgruppen bestehen lassen.

Wenn Sie sich entscheiden, die Verknüpfung aufzulösen, oder wenn Sie mit SQL Server 2019 und früheren Versionen einen Failover durchführen, müssen Sie die verteilte Verfügbarkeitsgruppe auflösen, um die Verknüpfungsmetadaten von SQL Server zu entfernen. Sie können die Verfügbarkeitsgruppe jedoch auch auf SQL Server belassen.

Um Ihre Verfügbarkeitsgruppenressourcen zu bereinigen, ersetzen Sie die folgenden Werte und führen dann den Beispielcode aus. Ersetzen Sie im folgenden Code:

  • <DAGName> durch den Namen der verteilten Verfügbarkeitsgruppe auf der SQL Server-Instanz (zur Erstellung des Links verwendet)
  • <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 <DAGName> --mandatory
GO
-- DROP AVAILABILITY GROUP <AGName> --optional
-- GO

Problembehandlung

Dieser Abschnitt enthält Anleitungen zur Konfiguration und Verwendung des Links.

Fehler

Wenn Sie beim Erstellen der Verknüpfung oder beim Failover einer Datenbank auf eine Fehlermeldung stoßen, lesen Sie die Fehlermeldung im Abfrageausgabefenster, um weitere Informationen zu erhalten.

Wenn Sie bei der Arbeit mit der Verknüpfung auf einen Fehler stoßen, wird die Ausführung der Abfrage bei dem fehlgeschlagenen Schritt abgebrochen. Nachdem die Fehlerbedingung behoben ist, führen Sie den Befehl erneut aus, um mit Ihrer Aktion fortzufahren.

Inkonsistenter Zustand nach erzwungenem Failover

Die Verwendung von einem erzwungenem Failover kann zu einem inkonsistenten Zustand zwischen dem primären und dem sekundären Replikat führen, was zu einem Split-Brain-Szenario führt, da beide Replikate dieselbe Rolle einnehmen. Die Datenreplikation schlägt in diesem Zustand fehl, bis der Benutzer die Situation löst, indem er ein Replikat manuell als primäres und das andere als sekundäres Replikat festlegt.

Zugehöriger Inhalt

Weitere Informationen zum Linkfeature finden Sie in den folgenden Ressourcen: