Konfigurieren von Verknüpfungen mit Skripten – Azure SQL Managed Instance
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
- Es ist auch möglich, die Verknüpfung mit SQL Server Management Studio (SSMS) zu konfigurieren.
- 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.
Ü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 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:
- Eine aktive Azure-Subscription. Falls Sie nicht über ein Abonnement verfügen, können Sie ein kostenloses Konto erstellen.
- Unterstützte Version von SQL Server mit installiertem erforderlichem Dienstupdate
- Azure SQL Managed Instance. Erstellen Sie eine verwaltete Azure SQL-Instanz, falls Sie noch nicht über eine Instanz verfügen.
- PowerShell-Modul Az.SQL 3.9.0 oder höher oder Azure CLI 2.47.0 oder höher Oder verwenden Sie vorzugsweise Azure Cloud Shell online über den Webbrowser, um die Befehle auszuführen, da es 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. 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 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:
- Generieren Sie ein Zertifikat in SQL Server, und rufen Sie den zugehörigen öffentlichen Schlüssel ab.
- Rufen Sie einen öffentlichen Schlüssel des SQL Managed Instance-Zertifikats ab.
- Tauschen Sie die öffentlichen Schlüssel zwischen SQL Server und SQL Managed Instance aus.
- 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 mit0x
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 mit0x
) 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
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:
<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 (beispielsweiseAG_<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 BeispielDAG1_<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 (beispielsweiseAG_<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.
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 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.
# 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.
Überprüfen des Links
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.
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: