Teilen über

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

Ü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 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, wird die Datenbank 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 Verknüpfung beizubehalten und Failover zwischen den beiden Replikaten durchzuführen.

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

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.
  • Um eine Verknüpfung oder einen Failover von SQL Managed Instance zu SQL Server 2022 herzustellen, muss Ihre verwaltete Instanz mit der SQL Server 2022-Updaterichtlinie konfiguriert werden. Datenreplikation und Failover von SQL Managed Instance zu SQL Server 2022 werden von Instanzen, die mit der Always-up-to-date-Updaterichtlinie konfiguriert sind, nicht unterstützt.
  • Sie können zwar eine Verknüpfung von SQL Server 2022 zu einer SQL Managed Instance herstellen, die mit der Always-up-to-date-Updaterichtlinie konfiguriert ist, aber nach einem Failover zur SQL Managed Instance können Sie die Daten nicht mehr replizieren oder einen Failback nach SQL Server 2022 durchführen.

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

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 auf SQL Server aus, um das MI-Endpunktzertifikat zu erstellen. 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 = 0x308205A830820390A00302010202101ED397095FD8B4B347701EAABE7F45B3300D06092A864886F70D01010C05003065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F726974792032303137301E170D3139313231383232353132325A170D3432303731383233303032335A3065310B3009060355040613025553311E301C060355040A13154D6963726F736F667420436F72706F726174696F6E313630340603550403132D4D6963726F736F66742052534120526F6F7420436572746966696361746520417574686F72697479203230313730820222300D06092A864886F70D01010105000382020F003082020A0282020100CA5BBE94338C299591160A95BD4762C189F39936DF4690C9A5ED786A6F479168F8276750331DA1A6FBE0E543A3840257015D9C4840825310BCBFC73B6890B6822DE5F465D0CC6D19CC95F97BAC4A94AD0EDE4B431D8707921390808364353904FCE5E96CB3B61F50943865505C1746B9B685B51CB517E8D6459DD8B226B0CAC4704AAE60A4DDB3D9ECFC3BD55772BC3FC8C9B2DE4B6BF8236C03C005BD95C7CD733B668064E31AAC2EF94705F206B69B73F578335BC7A1FB272AA1B49A918C91D33A823E7640B4CD52615170283FC5C55AF2C98C49BB145B4DC8FF674D4C1296ADF5FE78A89787D7FD5E2080DCA14B22FBD489ADBACE479747557B8F45C8672884951C6830EFEF49E0357B64E798B094DA4D853B3E55C428AF57F39E13DB46279F1EA25E4483A4A5CAD513B34B3FC4E3C2E68661A45230B97A204F6F0F3853CB330C132B8FD69ABD2AC82DB11C7D4B51CA47D14827725D87EBD545E648659DAF5290BA5BA2186557129F68B9D4156B94C4692298F433E0EDF9518E4150C9344F7690ACFC38C1D8E17BB9E3E394E14669CB0E0A506B13BAAC0F375AB712B590811E56AE572286D9C9D2D1D751E3AB3BC655FD1E0ED3740AD1DAAAEA69B897288F48C407F852433AF4CA55352CB0A66AC09CF9F281E1126AC045D967B3CEFF23A2890A54D414B92AA8D7ECF9ABCD255832798F905B9839C40806C1AC7F0E3D00A50203010001A3543052300E0603551D0F0101FF040403020186300F0603551D130101FF040530030101FF301D0603551D0E0416041409CB597F86B2708F1AC339E3C0D9E9BFBB4DB223301006092B06010401823715010403020100300D06092A864886F70D01010C05000382020100ACAF3E5DC21196898EA3E792D69715B813A2A6422E02CD16055927CA20E8BAB8E81AEC4DA89756AE6543B18F009B52CD55CD53396D624C8B0D5B7C2E44BF83108FF3538280C34F3AC76E113FE6E3169184FB6D847F3474AD89A7CEB9D7D79F846492BE95A1AD095333DDEE0AEA4A518E6F55ABBAB59446AE8C7FD8A2502565608046DB3304AE6CB598745425DC93E4F8E355153DB86DC30AA412C169856EDF64F15399E14A75209D950FE4D6DC03F15918E84789B2575A94B6A9D8172B1749E576CBC156993A37B1FF692C919193E1DF4CA337764DA19FF86D1E1DD3FAECFBF4451D136DCFF759E52227722B86F357BB30ED244DDC7D56BBA3B3F8347989C1E0F20261F7A6FC0FBB1C170BAE41D97CBD27A3FD2E3AD19394B1731D248BAF5B2089ADB7676679F53AC6A69633FE5392C846B11191C6997F8FC9D66631204110872D0CD6C1AF3498CA6483FB1357D1C1F03C7A8CA5C1FD9521A071C193677112EA8F880A691964992356FBAC2A2E70BE66C40C84EFE58BF39301F86A9093674BB268A3B5628FE93F8C7A3B5E0FE78CB8C67CEF37FD74E2C84F3372E194396DBD12AFBE0C4E707C1B6F8DB332937344166DE8F4F7E095808F965D38A4F4ABDE0A308793D84D00716245274B3A42845B7F65B76734522D9C166BAAA8D87BA3424C71C70CCA3E83E4A6EFB701305E51A379F57069A641440F86B02C91C63DEAAE0F84

    --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 exists.'
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 = 0x3082038E30820276A0030201020210033AF1E6A711A9A0BB2864B11D09FAE5300D06092A864886F70D01010B05003061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F74204732301E170D3133303830313132303030305A170D3338303131353132303030305A3061310B300906035504061302555331153013060355040A130C446967694365727420496E6331193017060355040B13107777772E64696769636572742E636F6D3120301E06035504031317446967694365727420476C6F62616C20526F6F7420473230820122300D06092A864886F70D01010105000382010F003082010A0282010100BB37CD34DC7B6BC9B26890AD4A75FF46BA210A088DF51954C9FB88DBF3AEF23A89913C7AE6AB061A6BCFAC2DE85E092444BA629A7ED6A3A87EE054752005AC50B79C631A6C30DCDA1F19B1D71EDEFDD7E0CB948337AEEC1F434EDD7B2CD2BD2EA52FE4A9B8AD3AD499A4B625E99B6B00609260FF4F214918F76790AB61069C8FF2BAE9B4E992326BB5F357E85D1BCD8C1DAB95049549F3352D96E3496DDD77E3FB494BB4AC5507A98F95B3B423BB4C6D45F0F6A9B29530B4FD4C558C274A57147C829DCD7392D3164A060C8C50D18F1E09BE17A1E621CAFD83E510BC83A50AC46728F67314143D4676C387148921344DAF0F450CA649A1BABB9CC5B1338329850203010001A3423040300F0603551D130101FF040530030101FF300E0603551D0F0101FF040403020186301D0603551D0E041604144E2254201895E6E36EE60FFAFAB912ED06178F39300D06092A864886F70D01010B05000382010100606728946F0E4863EB31DDEA6718D5897D3CC58B4A7FE9BEDB2B17DFB05F73772A3213398167428423F2456735EC88BFF88FB0610C34A4AE204C84C6DBF835E176D9DFA642BBC74408867F3674245ADA6C0D145935BDF249DDB61FC9B30D472A3D992FBB5CBBB5D420E1995F534615DB689BF0F330D53E31E28D849EE38ADADA963E3513A55FF0F970507047411157194EC08FAE06C49513172F1B259F75F2B18E99A16F13B14171FE882AC84F102055D7F31445E5E044F4EA879532930EFE5346FA2C9DFF8B22B94BD90945A4DEA4B89A58DD1B7D529F8E59438881A49E26D56FADDD0DC6377DED03921BE5775F76EE3C8DC45D565BA2D9666EB33537E532B6

    --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 exists.'
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

Überprüfen des Zertifikats

Nachdem Sie die Zertifikate erstellt haben, überprüfen Sie, ob das MI-Endpunktzertifikat ordnungsgemäß konfiguriert ist.

Ermitteln Sie zuerst den certificate_id des exportierten MI-Zertifikat, indem Sie den Wert von <ManagedInstanceFQDN> ersetzen und dann die folgende Abfrage auf SQL Server ausführen:

-- Run on SQL Server 
USE MASTER 
GO 

SELECT name, subject, certificate_id, start_date, expiry_date 
FROM sys.certificates 
WHERE issuer_name LIKE '%Microsoft Corporation%' AND name = '<ManagedInstanceFQDN>' 
GO

Überprüfen Sie als Nächstes das Zertifikat, indem Sie den Wert <certificate_id> aus dem Ergebnis der vorherigen Abfrage ersetzen und dann die folgende Abfrage auf SQL Server ausführen:

-- Run on SQL Server 

USE MASTER 
GO 

EXEC sp_validate_certificate_ca_chain <certificate_id> 
GO

Die Antwort Commands completed successfully. Completion time: … zeigt an, dass das MI-Endpunktzertifikat erfolgreich überprüft wurde.

Wenn ein Fehler auftritt, löschen Sie das Zertifikat, führen Sie die Schritte im Abschnitt Abrufen des öffentlichen Zertifikats aus SQL Managed Instance aus, und importieren Sie es in den SQL Server-Abschnitt, um das Zertifikat erneut zu importieren.

Um das Zertifikat zu entfernen, führen Sie die folgende Abfrage auf SQL Server aus:

-- Run on SQL Server 

USE MASTER 
GO 

DROP CERTIFICATE [<ManagedInstanceFQDN>] 
GO

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.

Hinweis

Überspringen Sie diesen Abschnitt, wenn Sie bereits eine Verfügbarkeitsgruppe eingerichtet haben.

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:

  • <AGNameOnSQLServer> durch den Namen der Verfügbarkeitsgruppe in SQL Server. 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 [<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>: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>.
  • <AGNameOnSQLServer> durch den Namen der im vorherigen Schritt erstellten Verfügbarkeitsgruppe
  • <AGNameOnSQLMI> durch den Namen der Verfügbarkeitsgruppe in SQL Managed Instance. Der Name muss in SQL MI eindeutig sein. Es empfiehlt sich gegebenenfalls, die einzelnen Verfügbarkeitsgruppen jeweils so zu benennen, dass der Name die entsprechende Datenbank widerspiegelt (beispielsweise AG_<db_name>_MI).
  • <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'<AGNameOnSQLServer>' WITH 
    (
      LISTENER_URL = 'TCP://<SQLServerIP>:5022',
      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

Ü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
  • <AGNameOnSQLServer> durch den Namen der Verfügbarkeitsgruppe, die in SQL Server erstellt wurde
  • <AGNameOnSQLMI> durch den Namen der Verfügbarkeitsgruppe, die in SQL Managed Instance 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.

Hinweis

Wenn Sie einer Verlinkung zu einer bereits vorhandenen Verfügbarkeitsgruppe herstellen möchten, geben Sie beim Angeben des Parameters <SQLServerIP> die IP-Adresse des Listeners an.

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

# Create link on managed instance. Join distributed availability group on SQL Server.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName |
-PrimaryAvailabilityGroupName $AGNameOnSQLServer -SecondaryAvailabilityGroupName $AGNameOnSQLMI |
-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.

Erste Transaktionsprotokollsicherung durchführen

Wenn SQL Server Ihre erste primäre Instanz ist, ist es wichtig, die erste Transaktionsprotokollsicherung auf SQL Server nach Abschluss des anfänglichen Seedings durchzuführen, wenn sich die Datenbank nicht mehr im Zustand Wiederherstellen … auf Azure SQL Managed Instance befindet. Nehmen Sie dann regelmäßig SQL Server-Transaktionsprotokollsicherungen vor, um übermäßiges Protokollwachstum zu minimieren, während SQL Server in der primären Instanz ist.

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

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 zu löschen. 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.

Zugehöriger Inhalt

So verwenden Sie den Link:

Weitere Informationen zum Link finden Sie unter:

Informationen zu anderen Replikations- und Migrationsszenarios finden Sie unter: