Konfigurieren des Links mit Skripts – Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

In diesem Artikel erfahren Sie, wie Sie einen link zwischen SQL Server und Azure SQL Managed Instance mit Transact-SQL- und PowerShell- oder Azure CLI-Skripts 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.

Übersicht

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

Sie können die Verknüpfung für die fortlaufende Datenreplikation in einer Hybridumgebung zwischen dem primären und sekundären Replikat beibehalten, oder Sie können ein Failover der Datenbank auf das sekundäre Replikat durchführen, zu Azure migrieren oder für die Notfallwiederherstellung nutzen. Für SQL Server 2019 und frühere Versionen wird das Failover zur Azure SQL Managed Instance die Verbindung unterbrechen und ein Failback wird nicht unterstützt. Mit SQL Server 2022 haben Sie die Möglichkeit, die Verbindung beizubehalten und zwischen den beiden Replikaten hin- und herzuschalten.

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.

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

Voraussetzungen

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

• Ein aktives Azure-Abonnement. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
• Unterstützte Version von SQL Server mit installiertem erforderlichem Service-Update.
• Azure SQL Managed Instance. Fangen Sie an, wenn Sie es noch nicht haben.
• PowerShell-Modul Az.SQL 6.0.0 oder höher oder Azure CLI 2.67.0 oder höher. Oder vorzugsweise verwenden Sie Azure Cloud Shell online aus dem Webbrowser, um die Befehle auszuführen, da sie immer mit den neuesten Modulversionen aktualisiert wird.
• Eine ordnungsgemäß vorbereitete Umgebung

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. Um beispielsweise 10 Datenbanken in SQL Managed Instance zu replizieren, erstellen Sie 10 einzelne Links.
• Die Sortierung zwischen SQL Server und SQL Managed Instance sollte identisch sein. Ein Mismatch bei der Kollation kann zu einem Mismatch in der Groß-/Kleinschreibung des Servernamens führen und verhindern, dass eine erfolgreiche Verbindung von SQL Server zu SQL Managed Instance hergestellt wird.
• Fehler 1475 auf Ihrem ersten SQL Server-Primärserver weist darauf hin, dass Sie eine neue Sicherungskette starten müssen, indem Sie eine vollständige Sicherung ohne die Option COPY ONLY erstellen.
• Um ein Failover durchzuführen oder eine Verknüpfung von SQL Managed Instance zu SQL Server 2025 herzustellen, muss Ihre SQL Managed Instance mit der SQL Server 2025-Updaterichtlinie konfiguriert sein. Die Datenreplikation und das Failover von SQL Managed Instance zu SQL Server 2025 werden nicht von Instanzen unterstützt, die mit einer nicht übereinstimmenden Updaterichtlinie konfiguriert sind.
• Um eine Verknüpfung herzustellen oder einen Failover von SQL Managed Instance zu SQL Server 2022 durchzuführen, muss Ihre SQL Managed Instance mit der SQL Server 2022-Updaterichtlinie konfiguriert werden. Datenreplikation und Failover von SQL Managed Instance zu SQL Server 2022 werden nicht unterstützt, wenn Instanzen mit einer nicht übereinstimmenden Aktualisierungsrichtlinie konfiguriert sind.
• Sie können zwar einen Link aus einer unterstützten Version von SQL Server zu einer SQL managed instance herstellen, die mit der Always-up-to-date Updaterichtlinie konfiguriert ist, nach dem Failover auf SQL Managed Instance können Sie daten nicht mehr replizieren oder nicht mehr in Ihre SQL Server Instanz zurückkehren.

Berechtigungen

Für SQL Server sollten Sie über sysadminBerechtigungen verfügen.

Für Azure SQL Managed Instance sollten Sie Mitglied des SQL Managed Instance Mitwirkenden sein oder über die folgenden benutzerdefinierten Rollenberechtigungen verfügen:

Terminologie und Benennungskonventionen

Während Sie Skripts aus diesem Leitfaden ausführen, ist es wichtig, die Namen von SQL Server und SQL Managed Instance nicht mit ihren vollqualifizierten Domänennamen (FQDNs) zu verwechseln. Die folgende Tabelle zeigt, was die verschiedenen Namen genau darstellen und wie Sie die jeweiligen Werte erhalten:

Das Konfigurieren von Azure SQL Managed Instance als primäre Instanz wird ab SQL Server 2022 CU10 unterstützt.

Einrichten der Datenbankwiederherstellung und -sicherung

Wenn SQL Server Ihr anfänglicher primärer Server ist, müssen Datenbanken, die über den Link repliziert werden sollen, im vollständigen Wiederherstellungsmodell betrieben werden und mindestens eine Sicherung haben. Da Azure SQL Managed Instance Sicherungen automatisch ausführt, überspringen Sie diesen Schritt, wenn SQL Managed Instance Ihre erste Primäre ist.

Wenn Sie eine Verknüpfung erstellen, erfolgt das anfängliche Seeding zwischen den primären und sekundären Replikaten, indem eine vollständige Sicherung der Datenbank auf dem primären Replikat durchgeführt, sie an das sekundäre Replikat übertragen und dort wiederhergestellt wird. Wenn Sie die vollständige Sicherung übernehmen, empfiehlt es sich, die WITH CHECKSUM Option zu verwenden, um sicherzustellen, dass die Sicherung gültig ist und keine Beschädigung hat. Weitere Informationen finden Sie unter BACKUP (Transact-SQL).

Führen Sie den folgenden Code für SQL Server 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.

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.

Zertifikatbasierte Vertrauensstellung ist die einzige unterstützte Möglichkeit zum Sichern der Datenbankspiegelungsendpunkte für SQL Server und SQL Managed Instance. Wenn Sie über vorhandene Verfügbarkeitsgruppen verfügen, die Windows-Authentifizierung verwenden, müssen Sie dem vorhandenen Spiegelungsendpunkt eine zertifikatbasierte Vertrauensstellung als sekundäre Authentifizierungsoption hinzufügen. Sie können dies mithilfe der ALTER ENDPOINT-Anweisung erreichen, wie weiter unten in diesem Artikel beschrieben.

Im Folgenden finden Sie eine Übersicht über den Prozess zum Sichern der Datenbankspiegelungsendpunkte für SQL Server und SQL Managed Instance:

1. Generieren Sie ein Zertifikat für SQL Server, und rufen Sie den ö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 Azure-vertrauenswürdigen Root-Zertifizierungsstellenschlüsseln in SQL Server

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

Erstellen eines Zertifikats für SQL Server und Importieren des ö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 auf 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 für SQL Server. 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.

-- 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 für 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.

Jetzt können Sie den öffentlichen Schlüssel des generierten Zertifikats auf 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.

Stellen Sie zunächst sicher, 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 für Ihr 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 die New-AzSqlInstanceServerTrustCertificate PowerShell oder az sql mi partner-cert create Azure CLI Befehl, um den öffentlichen Schlüssel des Authentifizierungszertifikats von SQL Server in Azure hochzuladen, z. B. das folgende 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> mit dem öffentlichen Teil des SQL Server Zertifikats im Binärformat, das Sie im vorherigen Schritt aufgezeichnet haben. (ein langer Zeichenfolgenwert, der mit 0x beginnt)
• <SQLServerCertName> mit dem SQL Server Zertifikatnamen, den Sie im vorherigen Schritt aufgezeichnet haben.
• <ManagedInstanceName> mit dem 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 hochgeladenen SQL Server Zertifikats auf Azure.

Wenn Sie alle in eine verwaltete Instanz hochgeladenen SQL Server Zertifikate anzeigen müssen, verwenden Sie die Get-AzSqlInstanceServerTrustCertificate PowerShell oder az sql mi partner-cert list Azure CLI befehl in Azure Cloud Shell. Um SQL Server Zertifikat zu entfernen, das in eine von SQL verwaltete Instanz hochgeladen wurde, verwenden Sie den Befehl Remove-AzSqlInstanceServerTrustCertificate PowerShell oder az sql mi partner-cert delete Azure CLI befehl in Azure Cloud Shell.

Abrufen des öffentlichen Zertifikatschlüssels aus SQL Managed Instance und Importieren in SQL Server

Das Zertifikat zum Sichern des Verknüpfungsendpunkts wird automatisch auf Azure SQL Managed Instance generiert. Rufen Sie den öffentlichen Schlüssel des Zertifikats von SQL Managed Instance ab, und importieren Sie ihn zu SQL Server, indem Sie den PowerShell-Befehl Get-AzSqlInstanceEndpointCertificate oder den Azure CLI-Befehl az sql mi endpoint-cert show verwenden, wie im folgenden PowerShell-Beispiel gezeigt.

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

• <SubscriptionID> mit Ihrer Azure Abonnement-ID.
• <ManagedInstanceName> mit dem 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.

Importieren Sie als Nächstes den erhaltenen öffentlichen Schlüssel des Sicherheitszertifikats der verwalteten Instanz in SQL Server. Führen Sie die folgende Abfrage für SQL Server aus, um das MI-Endpunktzertifikat zu erstellen. Ersetzen Sie:

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

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

Importieren von Azure-vertrauenswürdigen Root-Zertifizierungsstellenschlüsseln in SQL Server

Das Importieren von Azure-vertrauenswürdigen Stammzertifizierungsstellenschlüsseln in SQL Server ist erforderlich, damit Ihr SQL Server den öffentlichen Schlüsselzertifikaten von SQL Managed Instance, die von Azure ausgestellt wurden, vertraut.

Sie können die erforderlichen Stammzertifizierungsstellenschlüssel aus Azure Zertifizierungsstellendetails herunterladen. Laden Sie mindestens die DigiCert Global Root G2 und Microsoft RSA-Stammzertifizierungsstelle 2017 herunter, und importieren Sie sie in Ihre SQL Server Instanz. Wenn Sie den Link jedoch länger als ein paar Monate ausführen möchten, laden Sie alle 7 Zertifikate herunter, die in der Root-Zertifizierungsstellen aufgeführt sind, um potenzielle Unterbrechungen zu vermeiden, falls Azure die Liste der vertrauenswürdigen Zertifizierungsstellen aktualisiert.

Speichern Sie die Zertifikate lokal in der SQL Server Instanz, z. B. im Beispiel C:\Path\To\<name of certificate>.crt Pfad, und importieren Sie dann die Zertifikate aus diesem Pfad mithilfe des folgenden Transact-SQL Skripts. Ersetzen Sie <name of certificate> durch den tatsächlichen Zertifikatnamen, z. B. DigiCert Global Root G2 oder Microsoft RSA Root Certificate Authority 2017.

-- Run on SQL Server
-- Import <name of certificate> root-authority certificate (trusted by Azure), if not already present
IF NOT EXISTS (SELECT name FROM sys.certificates WHERE name = N'<name of certificate>')
BEGIN
    PRINT 'Creating <name of certificate> certificate.'
    CREATE CERTIFICATE [<name of certificate>] FROM FILE = 'C:\Path\To\<name of certificate>.crt'

    --Trust certificates issued by <name of certificate> root authority for Azure database.windows.net domains
    DECLARE @CERTID int
    SELECT @CERTID = CERT_ID('<name of certificate>')
    --For government cloud, use the corresponding SQL Database DNS suffix, e.g. '*.database.usgovcloudapi.net', '*.database.chinacloudapi.cn' etc.
    EXEC sp_certificate_add_issuer @CERTID, N'*.database.windows.net'
END
ELSE
    PRINT 'Certificate <name of certificate> already exists.'
GO

Überprüfen Sie schließlich alle erstellten Zertifikate mithilfe der folgenden dynamischen Verwaltungsansicht (DMV):

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

Überprüfen der Zertifikatkette

Geplante oder unbeabsichtigte Änderungen an Zertifikaten können die Verknüpfung beeinträchtigen. Um Unterbrechungen zu vermeiden, ist es wichtig, regelmäßig die Zertifikatkette auf dem SQL Server zu validieren.

Überspringen Sie diesen Schritt, wenn Sie einen neuen Link konfigurieren oder die Zertifikate kürzlich importiert haben, wie in den vorherigen Abschnitten beschrieben.

Den Endpunkt für die Datenbankspiegelung sichern

Wenn Sie über keine Verfügbarkeitsgruppe oder einen Datenbankspiegelungsendpunkt auf SQL Server verfügen, besteht der nächste Schritt darin, einen Datenbankspiegelungsendpunkt auf SQL Server zu erstellen und mit dem zuvor generierten SQL Server Zertifikat zu sichern. Wenn Sie bereits eine Verfügbarkeitsgruppe oder einen Spiegelungsendpunkt haben, fahren Sie mit dem Abschnitt Ändern eines bestehenden Endpunkts fort.

Erstellen und Sichern des Datenbankspiegelungsendpunkts auf 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 in der vorherigen Abfrage kein vorhandener Endpunkt für die Datenbankspiegelung angezeigt wird, führen Sie das folgende Skript auf SQL Server aus, um den Namen des zuvor generierten SQL Server Zertifikats abzurufen.

-- 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 am Port <EndpointPort> zu erstellen und den Endpunkt mit dem SQL Server Zertifikat zu sichern. Ersetzen Sie:

• <SQL_SERVER_CERTIFICATE> mit dem 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=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = CERTIFICATE [<SQL_SERVER_CERTIFICATE>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )  
GO

Überprüfen Sie, ob der Spiegelungsendpunkt erstellt wurde, indem Sie das folgende Skript auf 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

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 für SQL Server aus, um 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_algorithm_desc nicht AES ist, muss der Endpunkt geändert werden, um die Anforderungen zu erfüllen.

Auf SQL Server wird derselbe 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 Windows-Authentifizierung für eine vorhandene Verfügbarkeitsgruppe benötigen, ist es möglich, den Endpunkt so zu ändern, dass mehrere Authentifizierungsmethoden verwendet werden, indem Sie die Authentifizierungsoption auf NEGOTIATE CERTIFICATE wechseln. Diese Änderung ermöglicht es der vorhandenen Verfügbarkeitsgruppe, Windows-Authentifizierung zu verwenden, während die Zertifikatauthentifizierung für SQL Managed Instance 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 das Ändern des vorhandenen Datenbankspiegelungsendpunkts für SQL Server. Ersetzen Sie:

• <YourExistingEndpointName> mit dem Namen Ihres vorhandenen Endpunkts ersetzen
• <SQLServerCertName> mit dem Namen des generierten SQL Server Zertifikats (in einem der vorherigen Schritte oben abgerufen).

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 auf 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=<EndpointPort>, LISTENER_IP = ALL)
    FOR DATABASE_MIRRORING (
        ROLE=ALL,
        AUTHENTICATION = WINDOWS NEGOTIATE CERTIFICATE [<SQLServerCertName>],
        ENCRYPTION = REQUIRED ALGORITHM AES
    )
GO

Nachdem Sie die ALTER-Endpunktabfrage ausgeführt und den dualen Authentifizierungsmodus auf Windows und Zertifikat festgelegt haben, verwenden Sie diese Abfrage erneut auf SQL Server, um Details für den 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

Sie haben Ihren Datenbankspiegelungsendpunkt erfolgreich für eine SQL Managed Instance-Verbindung geändert.

Erstellen einer Verfügbarkeitsgruppe auf SQL Server

Wenn Sie nicht über eine vorhandene Verfügbarkeitsgruppe verfügen, besteht der nächste Schritt darin, eine für SQL Server zu erstellen, unabhängig davon, welche die erste primäre ist.

Befehle zum Erstellen der Verfügbarkeitsgruppe unterscheiden sich, wenn ihr SQL Managed Instance die erste primäre ist, die nur 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 sie dann jedoch eine neue verteilte Verfügbarkeitsgruppe für jede Datenbankverbindung zwischen SQL Server und SQL Managed Instance.

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

-- Run on SQL Server
-- Create the primary availability group on SQL Server
USE MASTER
CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>]
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>:<EndpointPort>',
            AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
            FAILOVER_MODE = MANUAL,
            SEEDING_MODE = AUTOMATIC
            );
GO

-- 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'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC,
      SESSION_TIMEOUT = 20
    ),
    N'<AGNameOnSQLMI>' WITH
    (
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>]',
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
      FAILOVER_MODE = MANUAL,
      SEEDING_MODE = AUTOMATIC
    );
GO

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

-- Run on SQL Server 
-- Create the availability group on SQL Server 

CREATE AVAILABILITY GROUP [<AGNameOnSQLServer>] 
WITH (CLUSTER_TYPE = NONE) 
FOR  
REPLICA ON N'<SQLServerName>' 
WITH ( 
    ENDPOINT_URL = N'TCP://<SQLServerIP>:<EndpointPort>', 
    FAILOVER_MODE = MANUAL, 
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT, 
    SEEDING_MODE = AUTOMATIC); 

GO 

-- Run on SQL Server 
-- Grant permission to the availability group to create databases 

ALTER AVAILABILITY GROUP [<AGNameOnSQLServer>] GRANT CREATE ANY DATABASE; 

-- 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'<AGNameOnSQLServer>' WITH  
    ( 
      LISTENER_URL = 'TCP://<SQLServerIP>:<EndpointPort>', 
      AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, 
      FAILOVER_MODE = MANUAL, 
      SEEDING_MODE = AUTOMATIC, 
      SESSION_TIMEOUT = 20 
    ), 
    N'<AGNameOnSQLMI>' WITH 
    ( 
      LISTENER_URL = 'tcp://<ManagedInstanceFQDN>:5022;Server=[<ManagedInstanceName>];Database=[<DatabaseName>]', 
      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 auf der SQL Server-Instanz auflisten. An diesem Punkt muss der Zustand Ihrer Verfügbarkeitsgruppe connected lauten, und der Zustand Ihrer verteilten Verfügbarkeitsgruppen muss disconnected lauten. Der Status der verteilten Verfügbarkeitsgruppe wechselt zu connected nur, wenn sie mit SQL Managed Instance verbunden ist.

-- 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 SSMS-Objekt-Explorer verwenden, um Verfügbarkeitsgruppen und verteilte Verfügbarkeitsgruppen zu finden. Erweitern Sie den Ordner Always On-Hochverfügbarkeit und anschließend den Ordner Verfügbarkeitsgruppen.

Erstellen einer Verknüpfung

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

Wenn Sie alle Links in einer verwalteten Instanz anzeigen müssen, verwenden Sie den Befehl Get-AzSqlInstanceLink PowerShell oder az sql mi link show Azure CLI befehl in Azure Cloud Shell.

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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 + ":<EndpointPort>"

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $SourceIP -InstanceLinkRole Secondary

#  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
$AGNameOnSQLServer = "<AGNameOnSQLServer>"

# Enter the availability group name that was created on SQL Managed Instance
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# 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>" 

# Enter the Azure subscription ID 
$SubscriptionID = "<SubscriptionID>" 
 
# ==== Do not customize the following cmdlet ==== 

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

# Build properly formatted connection endpoint 
$DestinationIP = "TCP://" + $SQLServerIP + ":<EndpointPort>"  

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI |
-Database @($DatabaseName) -PartnerEndpoint $DestinationIP -InstanceLinkRole Primary

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

Überprüfen des Links

Um die Verbindung zwischen SQL Managed Instance und SQL Server zu überprüfen, führen Sie die folgende Abfrage für SQL Server aus. Die Verbindung wird nicht sofort hergestellt. Es kann bis zu einer Minute dauern, bis das DMV anfängt, eine erfolgreiche Verbindung anzuzeigen. Aktualisieren Sie den DMV, bis die Verbindung für das SQL Managed Instance-Replikat als VERBUNDEN 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 der Objekt-Explorer in SSMS zunächst die replizierte Datenbank im sekundären Replikat, in einem Restoring-Zustand an, während die anfängliche Seeding-Phase abläuft und die vollständige Sicherung der Datenbank wiederhergestellt 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 der anfänglichen Seeding-Phase nicht mehr in der Wiederherstellung. Bei kleinen Datenbanken ist das Seeding möglicherweise so schnell, dass der anfängliche Zustand Wiederherstellung in SSMS gar nicht angezeigt wird.

Erste Transaktionsprotokollsicherung durchführen

Wenn SQL Server Ihr anfänglicher Primärserver ist, ist es wichtig, das erste Transaktionsprotokoll-Backup auf SQL Server nach Abschluss der anfänglichen Seeding durchzuführen, wenn sich die Datenbank nicht mehr im Zustand Restoring... auf der Azure SQL Managed Instance befindet. Erstellen Sie dann regelmäßig SQL Server Transaktionsprotokollsicherungen, um das übermäßige Protokollwachstum zu minimieren, während SQL Server die primäre Rolle innehat.

Wenn SQL Managed Instance Ihre primäre Ist, müssen Sie keine Maßnahmen ergreifen, da Azure SQL Managed Instance Protokollsicherungen automatisch ausführt.

Entfernen eines Links

Wenn Sie die Verlinkung entfernen möchten, entweder weil sie nicht mehr benötigt wird, oder weil sie sich in einem irreparablen Zustand befindet und neu erstellt werden muss, können Sie dies mit PowerShell und T-SQL tun.

Verwenden Sie zunächst den PowerShell-Befehl Remove-AzSqlInstanceLink, um die Verlinkung zu löschen, z. B. das folgende Beispiel:

Remove-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $managedInstanceName -Name $DAGName -Force 

Führen Sie dann das folgende T-SQL-Skript auf SQL Server aus, um die verteilte Verfügbarkeitsgruppe abzulegen. Ersetzen Sie <DAGName> durch den Namen der verteilten Verfügbarkeitsgruppe, die zur Erstellung der Verlinkung verwendet wird:

USE MASTER 
GO 

DROP AVAILABILITY GROUP <DAGName>  
GO 

Optional können Sie die Verfügbarkeitsgruppe entfernen, wenn Sie dafür keine Verwendung mehr haben. Ersetzen Sie dazu das <AGName> mit dem Namen der Verfügbarkeitsgruppe und führen Sie sie dann in der jeweiligen Instanz aus:

DROP AVAILABILITY GROUP <AGName>  
GO 

Problembehandlung

Wenn Sie beim Erstellen der Verknüpfung auf eine Fehlermeldung stoßen, lesen Sie die Fehlermeldung im Abfrageausgabefenster, um weitere Informationen zu erhalten. Weitere Informationen finden Sie unter Behandeln von Problemen mit dem Link.

Zugehöriger Inhalt

So verwenden Sie den Link:

• Umgebung für den verwaltete Instanz-Link vorbereiten
• Konfigurieren der Verbindung zwischen SQL Server und SQL Managed Instance mit SSMS
• Führen Sie ein Failover des Links aus
• Migrieren mit dem Link
• Bewährte Methoden zum Verwalten des Links
• Beheben von Problemen mit dem Link

Weitere Informationen zum Link finden Sie unter:

• verwaltete Instanz Linkübersicht
• Disasterwiederherstellung mit verwaltete Instanz Link

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter:

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