Erweitern Sie eine Always On Verfügbarkeitsgruppe auf Azure SQL Managed Instance (Vorschau)

Gilt für:Azure SQL Managed Instance

Dieser Artikel zeigt Ihnen, wie Sie eine Always On-Verfügbarkeitsgruppe mit mehreren Datenbanken zwischen SQL Server und Azure SQL Managed Instance mit dem verwaltete Instanz-Link erweitern können, indem Sie SQL Server Management Studio (SSMS), PowerShell oder Azure CLI verwenden.

Dieser Artikel behandelt den Multiple-Database-Link-Modus, der alle Datenbanken in einer Verfügbarkeitsgruppe über einen Link repliziert. Der Single-Database-Link-Modus repliziert pro Link eine Datenbank.

Overview

Wenn Sie eine Always On-Verfügbarkeitsgruppe zwischen SQL Server und Azure SQL Managed Instance erweitern, erstellen Sie eine Verbindung, die mehrere Datenbanken in einer Verfügbarkeitsgruppe zum Zielreplikat repliziert. Der Link verwendet eine verteilte Verfügbarkeitsgruppe, um Änderungen nahezu in Echtzeit von der aktuellen primären Replik zu den schreibgeschützten Datenbankkopien auf der sekundären Replik zu replizieren. Dies stellt sicher, dass die schreibgeschützten Kopien auf dem Sekundärsystem auf dem neuesten Stand des Primärsystems bleiben.

Du kannst eine bestehende Verfügbarkeitsgruppe verwenden oder mit eigenständigen Datenbanken beginnen. Wenn Sie eigenständige Datenbanken in SSMS auswählen, erstellt der Assistent eine Einzelknoten-Verfügbarkeitsgruppe auf der initialen primären Datenbank und repliziert die ausgewählten Datenbanken über einen Link.

Entweder SQL Server oder Azure SQL Managed Instance können die anfängliche Hauptinstanz sein. Um den Link von SQL Managed Instance zu erstellen, benötigt man SQL Server 2022 oder SQL Server 2025 mit dem erforderlichen kumulativen Update und einer passenden SQL Managed Instance-Update-Policy. Die Erstellungsbeispiele in diesem Artikel beginnen mit SQL Server. Sie laufen nicht durch die Erstellung von SQL Managed Instance. Failover mit Rollentausch zwischen SQL Server und Azure SQL Managed Instance wird für Instanzen unterstützt, die mit passenden Update-Richtlinien konfiguriert sind.

Haltbarkeit

Die folgenden Anforderungen gelten für die Erweiterung einer Verfügbarkeitsgruppe über einen Link mit mehreren Datenbanken während der Vorschau. SQL Server unter Windows und Linux wird unterstützt. Du musst das erforderliche kumulative Update (CU) installieren. Frühere Versionen unterstützen diese Funktion nicht.

Beachte Folgendes:

• Die Standardausgabe wird nicht unterstützt, da Basic Availability Groups nur eine Datenbank unterstützen.
• SQL Server 2019 und frühere Versionen werden für den Mehrfachdatenbank-Link-Modus nicht unterstützt, da ihnen die in SQL Server 2022 eingeführte Technologie fehlt.
• Um die Verknüpfung von SQL Managed Instance aus zu erstellen oder Rollen wieder auf SQL Server zurückzuführen, muss Ihre SQL Managed Instance die Updaterichtlinie verwenden, die Ihrer SQL Server-Version entspricht. Bei der Einweg-Replikation und der Umschaltung von SQL Server muss die Update-Richtlinie des Ziels Ihrer SQL Server-Version entsprechen oder höher sein.
  • SQL Server 2022 unterstützt Replikation zu Instanzen, die mit den Richtlinien SQL Server 2022, SQL Server 2025 und Always-up-to-Date konfiguriert sind.
  • SQL Server 2025 unterstützt die Replikation auf Instanzen, die mit den Richtlinien SQL Server 2025 und Always-up-to-date konfiguriert sind, aber nicht SQL Server 2022. Du kannst nach dem Cutover keine Daten replizieren oder zurück zu SQL Server zurückkehren, wenn die Richtlinien nicht übereinstimmen.

Für SQL Server-Versionen und -Editionen, die Single-Database-Links unterstützen, siehe verwaltete Instanz Link Version Supportability.

Voraussetzungen

Um Ihre Verfügbarkeitsgruppe zwischen SQL Server und Azure SQL Managed Instance zu erweitern, benötigen Sie folgende Voraussetzungen:

• Ein aktives Azure-Abonnement. Wenn Sie kein Konto haben, erstellen Sie ein kostenloses Konto.
• Eine unterstützte SQL Server-Version und -Edition mit dem erforderlichen Service-Update installiert. Sie können eine bestehende Always On-Verfügbarkeitsgruppe oder eigenständige Datenbanken verwenden, die SSMS in einer neuen Einzelknoten-Verfügbarkeitsgruppe platziert. Eigenständige Verfügbarkeitsgruppen werden nicht unterstützt.
• Azure SQL Managed Instance mit einer Update-Richtlinie, die zu Ihrem Szenario passt. Eine Abgleichsrichtlinie ist erforderlich, wenn die SQL Managed Instance die ursprüngliche primäre Instanz ist oder wenn eine Rollenumkehr erfolgt. Fang an , wenn du keine SQL-verwaltete Instanz hast.
• SQL Server Management Studio (SSMS) 22.10.2 oder neuer.
• Für die geskriptete Konfiguration: Azure PowerShell mit dem Az-Modul Version 16.3.0 oder höher und Az.Sql Version 7.1.0 oder neuer, oder Azure CLI Version 2.90.0 oder neuer. Sie können auch Azure Cloud Shell verwenden. Überprüfen Sie, ob die installierten Module oder die CLI diese Versionsanforderungen erfüllen.
• Eine ordnungsgemäß vorbereitete Umgebung
• Für eine Verfügbarkeitsgruppe mit mehreren Knoten ein konfigurierter Verfügbarkeitsgruppen-Listener. Verwenden Sie bei der Konfiguration der Verbindung die IP-Adresse des Listeners, nicht die IP-Adresse eines einzelnen SQL Server-Replikats. Mit dem Listener kann die Verbindung nach einem Failover einer lokalen Verfügbarkeitsgruppe weiterhin funktionieren.
• Keine vorhandenen Verbindungen auf einem SQL Server-Replik, wenn du den Mehrfach-Datenbank-Link-Modus aktivierst. Entferne vor Beginn alle Links, die den älteren Single-Database-Link-Modus verwenden.
• Ausreichend verfügbare Datenbankkapazität und Speicher auf der verwalteten Zielinstanz für alle Datenbanken in Ihrer Verfügbarkeitsgruppe. Überprüfen Sie die Ressourcenbeschränkungen.

Erlaubnisse

Für SQL Server benötigen Sie sysadmin-Berechtigungen .

Für Azure SQL Managed Instance müssen Sie Mitglied der Rolle SQL Managed Instance Mitwirkender sein oder über die folgenden benutzerdefinierten Rollenberechtigungen verfügen:

Multiple-Database-Link-Modus aktivieren

Die Unterstützung für den Multiple-Database-Link-Modus ist während der Vorschau standardmäßig deaktiviert. Verwenden Sie das integrierte sys.sp_multidb_milink gespeicherte Verfahren, um es auf jedem SQL Server-Replikat in der Verfügbarkeitsgruppe oder auf der SQL Server-Instanz zu aktivieren, in der Sie eine Einzelknotengruppe erstellen möchten.

Führen Sie auf jedem SQL Server-Replik folgenden Befehl aus, um den Mehrfachdatenbank-Link-Modus zu aktivieren:

EXEC sys.sp_multidb_milink 1;

Die Einstellung bleibt während der Neustarts von SQL Server bestehen, daher musst du sie nur einmal pro Replik aktivieren.

Um die Einstellung zu überprüfen, führe die gespeicherte Prozedur ohne Parameter auf jeder Replik aus. Es kehrt zurück, 1 wenn es aktiviert ist, und 0 wenn es deaktiviert ist:

EXEC sys.sp_multidb_milink;

Wenn das gespeicherte Verfahren nicht verfügbar ist, überprüfen Sie, ob das Replikat eine unterstützte SQL Server-Version und ein kumulatives Update installiert hat.

Um den Multiple-Database-Link-Modus zu deaktivieren, entfernen Sie zunächst alle Links und führen Sie dann auf jedem SQL Server-Replik folgenden Befehl aus:

EXEC sys.sp_multidb_milink 0;

Bereite die Datenbanken der Verfügbarkeitsgruppen vor

Stelle jede SQL Server-Datenbank, die du replizieren möchtest, auf das vollständige Wiederherstellungsmodell ein und erstelle dann ein vollständiges Backup. Sowohl bestehende Verfügbarkeitsgruppendatenbanken als auch eigenständige Datenbanken erfordern diese Vorbereitung. Verwenden Sie das SSMS-Backup-Verfahren im Link-Konfigurationsleitfaden.

Für SQL Server-Datenbanken migrieren Sie das TDE-Zertifikat zu SQL Managed Instance. Für verschlüsselte SQL Managed Instance-Datenbanken, die mit SQL Server verknüpft sind, verwenden Sie einen vom Kunden verwalteten Schlüssel, der auf den Ziel-SQL Server zugänglich ist. Überprüfen Sie die TDE-Vorbereitung für den Link für die Anforderungen in jeder Richtung.

Der Link repliziert alle Datenbanken in der ausgewählten Verfügbarkeitsgruppe. Du kannst keine Teilmenge auswählen, also prüfe die verfügbare Kapazität der Ziel-SQL-verwalteten Instanz, bevor du den Link erstellst. Das Ziel darf keine Datenbanken mit denselben Namen enthalten wie die Datenbanken, die du replizieren möchtest. Bestehende Datenbanken mit unterschiedlichen Namen sind erlaubt, vorbehaltlich der Kapazitätsgrenzen der Instanz.

Die Verbindung unterstützt nur die Replikation von Benutzerdatenbanken. Die Replikation von Systemdatenbanken wird nicht unterstützt. Zum Replizieren von Objekten auf Instanzebene, die in master oder msdb gespeichert sind, erstellen Sie Skripte und führen Sie T-SQL-Skripts auf der Zielinstanz aus.

Konfigurieren Sie den Listener und die Zertifikate

Für eine Mehrknoten-Verfügbarkeitsgruppe verwenden Sie bei der Konfiguration der Verbindung die IP-Adresse des Zuhörers, sowohl in SSMS als auch in Skripten. Der Hörer leitet Verbindungen zur aktuellen primären Replik weiter. Verwenden Sie nicht die IP-Adresse eines einzelnen SQL Server-Replikats als Partner-Endpunkt der Verbindung. Ohne den Listener funktioniert die Verbindung nach einem Failover der lokalen Verfügbarkeitsgruppe nicht weiter. Für eine Einzelknoten-Verfügbarkeitsgruppe, einschließlich einer, die vom SSMS-Wizard für eigenständige Datenbanken erstellt wurde, verwenden Sie den IP-Endpunkt dieser SQL Server-Instanz.

Der SSMS-Assistent tauscht Zertifikate nur zwischen der Azure SQL Managed Instance und der aktuellen primären SQL Server-Replik aus. Es konfiguriert kein Zertifikatsvertrauen auf den anderen SQL Server-Replikaten. Sie müssen die erforderlichen Zertifikate auf jedem anderen SQL Server-Replik manuell kopieren und konfigurieren, damit die Verbindung auch nach einem Failover der lokalen Verfügbarkeitsgruppe weiterfunktioniert. Dieser manuelle Schritt gilt sowohl für SSMS als auch für die geskriptete Konfiguration. Überprüfung Stellen Sie Vertrauen zwischen den Instanzen für die Zertifikatsaustauschschritte her.

Bereite die Erstellung von geskripteten Links vor

Nutze SSMS für das empfohlene Setup-Erlebnis. Der Wizard automatisiert viele Konfigurationsschritte. Wenn du keine geskriptete Automatisierung brauchst, überspringe diesen Abschnitt und gehe zum SSMS-Tab in der Erweiterung der Verfügbarkeitsgruppe.

Scripted Setup ist eine fortgeschrittene Option, die Erfahrung in der Konfiguration von Verfügbarkeitsgruppen, Endpunkten und Zertifikatsvertrauen erfordert. Führen Sie diese Schritte nur aus, wenn Sie PowerShell oder die Azure CLI mit SQL Server als anfänglicher primärer Instanz verwenden.

Die Checkliste umfasst sowohl bestehende Verfügbarkeitsgruppen als auch eigenständige Datenbanken. Nachdem Sie die Datenbanken, den Trust und den Endpunkt vorbereitet haben, verwenden Sie Ihre bestehende Verfügbarkeitsgruppe erneut oder erstellen Sie eine in Schritt 4. Erstellen Sie dann die verteilte Verfügbarkeitsgruppe. Die PowerShell- und Azure CLI-Link-Erstellungsbefehle erstellen nicht für dich die Verfügbarkeitsgruppe.

Für ein auf Ihre Umgebung zugeschnittenes Skript verwenden Sie den SSMS-Verknüpfungs-Assistenten und wählen Sie auf der Seite Zusammenfassung die Option Skript aus. Überprüfen Sie das generierte Skript und führen Sie es separat aus.

1. Aktivieren Sie den Mehrfach-Datenbank-Link-Modus auf jeder SQL Server-Replik oder auf der eigenständigen SQL Server-Instanz und bereiten Sie die Datenbanken vor.
2. Einrichten der Vertrauensstellung zwischen Instanzen. Befolgen Sie die Schritte zur Zertifikatserstellung, zum Public-Key-Austausch, zum Import von Root-Zertifikaten und zur Validierung der Zertifikatskette. Für eine Gruppe mit mehreren Knoten wenden Sie die Zertifikatsanforderungen auf jede SQL Server-Replik an, nicht nur auf die aktuelle primäre.
3. Sichern Sie den Datenbankspiegelungs-Endpunkt. Wenn Ihre Verfügbarkeitsgruppe bereits einen Endpunkt hat, verwenden Sie einen bestehenden Endpunkt verändern , anstatt einen weiteren zu erstellen. Behalte den konfigurierten Endpunkt-Port für den Link-Erstellungsbefehl.
4. Bereitet die Verfügbarkeitsgruppe vor. Wenn du bereits eine Verfügbarkeitsgruppe mit allen Datenbanken hast, die du replizieren möchtest, verwende sie erneut und überspringe das Erstellen einer neuen Gruppe. Wenn du mit eigenständigen Datenbanken beginnst, erstelle zuerst eine Verfügbarkeitsgruppe auf SQL Server. Verwenden Sie auf der Registerkarte „SQL Server initial primary“ das CREATE AVAILABILITY GROUP-Einzelknotenbeispiel mit CLUSTER_TYPE = NONE, ersetzen Sie FOR DATABASE [<DatabaseName>] jedoch durch die vollständige Liste der Datenbanken, beispielsweise FOR DATABASE [DB01], [DB03], [DB05], [DB07]. Setze <AGNameOnSQLServer> den Namen, den du der neuen Gruppe geben möchtest. Führe dieses Skript aus, bevor du mit der Erstellung von verteilten Verfügbarkeitsgruppen fortsetzt. Führe es nicht gegen eine bestehende Gruppe aus und ändere auch nicht die Clusterkonfiguration einer bestehenden Gruppe.
5. Erstelle die verteilte Verfügbarkeitsgruppe auf SQL Server. Verwenden Sie die Registerkarte SQL Server initial primary und fahren Sie bei den Anweisungen zum Erstellen einer verteilten Verfügbarkeitsgruppe fort. Lege <AGNameOnSQLServer> auf die Verfügbarkeitsgruppe fest, die du im vorherigen Schritt wiederverwendet oder erstellt hast. Für eine Gruppe mit mehreren Knoten verwenden Sie die IP-Adresse des Zuhörers für <SQLServerIP>. Für eine Gruppe mit nur einem Knoten verwenden Sie den Endpunkt der SQL Server-Instanz. Behalte <DAGName> als deinen Linknamen und <AGNameOnSQLMI> als den Managed-Instance Availability-Gruppennamen für den untenstehenden Erstellungsbefehl.
6. Überprüfe die Verfügbarkeitsgruppen auf SQL Server. Bestätigen Sie, dass sowohl die Always On-Verfügbarkeitsgruppe als auch die verteilte Verfügbarkeitsgruppe vorhanden sind. Dann kehren Sie zur Erweiterung der Verfügbarkeitsgruppe zurück, wählen Sie PowerShell oder Azure CLI und führen Sie den Befehl zur Erstellung mehrerer Datenbanken aus diesem Artikel anstelle des Befehls für die Einzeldatenbank aus dem anderen Leitfaden aus.

Verfügbarkeitsgruppe erweitern

Um die für das Seeding benötigten Logdatensätze zu erhalten, wird empfohlen, das Trace-Flag 12381 bei unterstützten SQL Server-Builds vor der Erstellung von Links zu aktivieren, insbesondere für große Datenbanken oder viele Datenbanken im Multiple-Database-Link-Modus. Die Flagge ist jedoch nicht erforderlich, und es gibt alternative Minderungsmaßnahmen, die in Fehlerbehebungsfehler 1412 aufgeführt sind. Mit aktiviertem Flag können Log-Backups fortgesetzt werden, aber gespeicherte Logdatensätze werden nicht wiederverwendbar gemacht. Überwachen Sie das Wachstum des SQL Server-Logs und den freien Speicherplatz und deaktivieren Sie das Flag, sobald das Seeding für alle erstellten Verbindungen abgeschlossen ist.

Verwenden Sie SSMS, um die Linkerstellung zu automatisieren, oder wählen Sie PowerShell oder Azure CLI für fortgeschrittene skriptbasierte Konfigurationen. Die folgenden Beispiele verwenden SQL Server als initiales Hauptsystem. Man kann auch mit einer SQL Managed Instance mit einer passenden Aktualisierungsrichtlinie starten, aber dieser Erstellungs-Workflow wird hier nicht abgedeckt.

Für die geskriptete Konfiguration führen Sie die geskripteten Einrichtungsschritte durch, um eine Verfügbarkeitsgruppe mit allen Datenbanken zu verwenden, die Sie replizieren möchten, und erstellen Sie dann die verteilte Verfügbarkeitsgruppe, bevor Sie den PowerShell- oder Azure CLI-Erstellungsbefehl ausführen. Alternativ gilt: Wenn Sie mit eigenständigen Datenbanken beginnen, erstellt das in diesem Abschnitt beschriebene SSMS-Verfahren bei der Einrichtung des Links automatisch die Single-Node-Verfügbarkeitsgruppe.

Für den Modus für Verknüpfungen mit mehreren Datenbanken geben Sie in Skripten explizit MultiDatabase an und geben Sie in der Verfügbarkeitsgruppe alle Datenbanknamen an. PowerShell verwendet standardmäßig SingleDatabase, wenn -LinkMode weggelassen wird. Verwendung -LinkMode MultiDatabase in PowerShell oder --link-mode MultiDatabase in Azure CLI.

Update-Module -Name Az
Update-Module -Name Az.Sql

Get-InstalledModule -Name Az | Select-Object Name, Version
Get-InstalledModule -Name Az.Sql | Select-Object Name, Version

# Run in Azure Cloud Shell and select PowerShell.
$ManagedInstanceName = "<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
$DAGName = "<DAGName>"

# Enter the availability group names from the setup steps.
$AGNameOnSQLServer = "<AGNameOnSQLServer>"
$AGNameOnSQLMI = "<AGNameOnSQLMI>"

# Include every database in the availability group.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07")

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
$SQLEndpointIP = "<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
$EndpointPort = "<EndpointPort>"

$ResourceGroup = (Get-AzSqlInstance -InstanceName $ManagedInstanceName).ResourceGroupName
$SQLPartnerEndpoint = "TCP://" + $SQLEndpointIP + ":" + $EndpointPort

# Create the multi-database link with SQL Managed Instance as the secondary.
New-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -PartnerAvailabilityGroupName $AGNameOnSQLServer -InstanceAvailabilityGroupName $AGNameOnSQLMI -Database $DatabaseNames -PartnerEndpoint $SQLPartnerEndpoint -InstanceLinkRole "Secondary" -FailoverMode "Manual" -SeedingMode "Automatic" -LinkMode "MultiDatabase"

# Run in Azure Cloud Shell and select Bash.
ResourceGroupName="<ResourceGroupName>"
ManagedInstanceName="<ManagedInstanceName>"

# Use the distributed availability group name from SQL Server as the link name.
# Use lowercase letters and hyphens, with no leading or trailing hyphen.
# The name must not already identify another link on this managed instance.
DAGName="<DAGName>"

# Enter the availability group names from the setup steps.
AGNameOnSQLServer="<AGNameOnSQLServer>"
AGNameOnSQLMI="<AGNameOnSQLMI>"

# Include every database in the availability group.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07}]"

# Use the listener IP for multiple-node AGs or the instance IP for single-node AGs.
SQLEndpointIP="<SQLEndpointIP>"
# Use the database mirroring endpoint port, normally 5022 unless customized.
EndpointPort="<EndpointPort>"

SQLPartnerEndpoint="TCP://${SQLEndpointIP}:${EndpointPort}"

# Create the multi-database link with SQL Managed Instance as the secondary.
az sql mi link create --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --partner-availability-group-name "$AGNameOnSQLServer" --instance-availability-group-name "$AGNameOnSQLMI" --databases "$DatabaseNames" --partner-endpoint "$SQLPartnerEndpoint" --instance-link-role Secondary --failover-mode Manual --seeding-mode Automatic --link-mode MultiDatabase

Replikation überprüfen

Nachdem du den Link erstellt oder Datenbanken hinzugefügt hast, replizieren sich die Daten vom aktuellen primären auf das aktuelle sekundäre Replikat. Entweder SQL Server oder Azure SQL Managed Instance können die anfängliche Hauptinstanz sein. Nach der Rollenumkehr replizieren sich die Daten in die entgegengesetzte Richtung. Je nach Datenbankgröße und Netzwerkgeschwindigkeit könnte jede Datenbank zunächst im Wiederherstellungszustand der sekundären Replik sein. Nach Abschluss des anfänglichen Seedings wird die Datenbank auf das sekundäre Replikat wiederhergestellt und kann für schreibgeschützte Workloads verwendet werden.

Bei beiden Repliken verwenden Sie den Objekt-Explorer in SSMS, um den synchronisierten Zustand jeder replizierten Datenbank anzuzeigen. Erweitern Sie Always On High Availability und Availability Groups, um die für den Link erstellte verteilte Verfügbarkeitsgruppe anzuzeigen.

Wenn SQL Server primär ist, können Sie während des Seedings weiterhin Transaktionsprotokoll-Backups durchführen, wenn Trace-Flag 12381 auf einem unterstützten Build aktiviert ist. Wenn Sie Log-Backups pausieren, um ein vorzeitiges Abschneiden zu verhindern, setzen Sie sie fort, nachdem das anfängliche Seeding abgeschlossen ist. Für jede Datenbank ohne Protokoll-Backup-Plan sollte das erste Transaktionsprotokoll-Backup erst nach Abschluss des ersten Seedings gemacht werden, nicht während des Seedings. Nachdem das Seeding für alle erstellten Verbindungen abgeschlossen ist, deaktivieren Sie das Flag, falls Sie es aktiviert haben, und machen regelmäßig Backups von SQL Server-Transaktionsprotokollen, während SQL Server primär bleibt. Wenn die Azure SQL Managed Instance primär ist, nimmt sie automatisch Transaktionsprotokoll-Backups durch. Du musst keine manuellen SQL Server-Log-Backups für diese Datenbanken machen, solange SQL Server sekundär ist.

Eine vorzeitige Log-Abkürzung während des Seedings kann die Fehler 1408 und 1412 im SQL Managed Instance Error Log verursachen. In Builds, die dies unterstützen, verhindert das Trace-Flag 12381 diese Abschneidung. Deaktiviere es, sobald das Seeding für alle erstellten Verbindungen abgeschlossen ist, und überwache die Nutzung von Transaktionsprotokollen, die Wachstumsrate und den freien Speicherplatz, solange es aktiviert ist. Log-Backups können fortgesetzt werden, solange die erforderlichen Aufzeichnungen erhalten bleiben. Diese Aufbewahrung ersetzt nicht die regulären Protokollbackups nach der Aussaat. Siehe Vorzeitiges Kürzen von Protokollen verhindern.

Hinzufügen von Datenbanken

Verwenden Sie den SSMS-Wizard, um Datenbanken aus dem aktuellen primären System hinzuzufügen, egal ob SQL Server oder SQL Managed Instance. Der Zauberer automatisiert die erforderlichen Änderungen. Für fortgeschrittene Automatisierung verwenden Sie PowerShell oder die Azure CLI. Das Hinzufügen einer Datenbank ist eine einzige Operation auf der Primärseite.

Bevor Datenbanken hinzugefügt werden, sollten Sie überprüfen, ob der bestehende Link den Mehrfach-Datenbank-Link-Modus verwendet und dass das Ziel über ausreichend verfügbare Datenbankkapazität und Speicher verfügt, ohne bestehende Datenbanknamen, die mit den neuen Datenbanken kollidieren. Wenn SQL Server primär ist, setze jede neue Datenbank, die noch nicht in der Verfügbarkeitsgruppe ist, auf das vollständige Wiederherstellungsmodell und erstelle ein vollständiges Backup mithilfe des SSMS-Backup-Verfahrens.

Datenbanken mit SSMS hinzufügen

Verwenden Sie den Guiden "Add Database to Azure SQL Managed Instance Link, um Datenbanken zu einer bestehenden Verbindung mit mehreren Datenbanken hinzuzufügen:

1. Stellen Sie in SSMS eine Verbindung mit dem aktuellen Primärserver her. Im Objekt-Explorer erweitern Sie Always auf High Availability und Availability Groups.

2. Klicken Sie mit der rechten Maustaste auf die verteilte Verfügbarkeitsgruppe für Ihren Link, fahren Sie mit der Maus über den Link Azure SQL Managed Instance und wählen Sie Datenbank hinzufügen....

   

3. Fahren Sie durch Einführung und Azure Login durch und wählen Sie dann Ihren Link mit mehreren Datenbanken auf der Seite "Link auswählen" aus.

4. Wählen Sie auf der Seite "Datenbanken auswählen" die Datenbanken aus, die Sie hinzufügen möchten. Du kannst nur Datenbanken mit einem Bereitschaftszustand hinzufügen. Datenbanken, die bereits im Link sind, werden als bereits Teil des ausgewählten Links angezeigt. Klären Sie etwaige Berechtigungsprobleme, bevor Sie fortfahren.

   

5. Vollständige Validierung und Bewertungszusammenfassung. Wähle Beenden , um die Änderung auszuführen, oder wähle Script , um ein Skript zu generieren, ohne die Änderung auszuführen, damit du es überprüfen, anpassen und separat ausführen kannst. Wenn du die Änderung im Wizard ausführst, überprüfe die Ergebnisse, bevor du ihn schließt.

Datenbanken mit Skripten hinzufügen

Führen Sie die Erweiterung auf der aktuellen Primärwahl durch. Befolge die Anweisungen für diesen Fall.

Wenn SQL Server primär ist

Verwenden Sie T-SQL, um jede Datenbank zur Verfügbarkeitsgruppe hinzuzufügen. Der Link verbreitet die Ergänzung zur SQL Managed Instance. Für die SQL Managed Instance sind keine weiteren Maßnahmen erforderlich. Führe für diese Ergänzung kein PowerShell- oder Azure CLI-Update durch.

Wenn SQL Managed Instance primär ist

Verwenden Sie PowerShell oder Azure CLI, um den Link auf der SQL Managed Instance zu aktualisieren. Der Link leitet die hinzugefügten Datenbanken automatisch an die Verfügbarkeitsgruppe weiter. Es ist kein separater Schritt auf SQL Server erforderlich. Stellen Sie die vollständige beabsichtigte Mitgliedschaft bereit, einschließlich aller bestehenden Datenbanken, die Sie behalten möchten, sowie der neuen Datenbanken. Die bereitgestellte Liste ersetzt die aktuelle Mitgliedschaft. Das Weglassen einer Datenbank entfernt sie aus der Mitgliedschaft des Links.

Um beispielsweise DB09 hinzuzufügen, wenn der Link bereits DB01, DB03, DB05 und DB07 enthält, behalten Sie diese vier Namen in der Liste bei und fügen Sie DB09 der Liste ebenfalls hinzu. Ersetzen Sie die Ressourcen- und Datenbanknamen durch Ihre eigenen Werte.

# Include every existing database to retain and each new database to add.
$DatabaseNames = @("DB01", "DB03", "DB05", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include every existing database to retain and each new database to add.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB05},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Wiederholen Sie die Replikationsverifikationsschritte für jede neu hinzugefügte Datenbank. Folgen Sie den manuellen Backup-Schritten nur dann, wenn SQL Server primär ist.

Entfernen von Datenbanken

Nutze den SSMS-Wizard auf dem aktuellen Primär, um die Entfernung auf beiden Seiten zu automatisieren. Zum Entfernen einer Datenbank muss diese aus der Verknüpfung auf der SQL Managed Instance und aus der Verfügbarkeitsgruppe entfernt werden. Wenn es nur auf einer Seite entfernt wird, wird der Vorgang nicht abgeschlossen.

Datenbanken mit SSMS entfernen

Die folgenden Schritte gelten, egal ob SQL Server oder SQL Managed Instance primär ist:

1. Stellen Sie in SSMS eine Verbindung mit dem aktuellen Primärserver her. Im Objekt-Explorer erweitern Sie Always auf High Availability und Availability Groups.

2. Klicken Sie mit der rechten Maustaste auf die verteilte Verfügbarkeitsgruppe für den Link, fahren Sie mit der Maus über den Link Azure SQL Managed Instance und wählen Sie Datenbank entfernen... aus.

   

3. Im Assistenten Remove Database from Azure SQL Managed Instance Link gehen Sie durch Introduction und Azure Login, und wählen Sie auf Select Link den Link aus.

4. Bei "Datenbanken auswählen" wählen Sie die Datenbanken aus, die entfernt werden sollen. Zum Beispiel wählen Sie DB05 aus, um es aus dem Link zu entfernen, und wählen Sie dann Nächstes aus.

   

5. Validierung abschließen, Zusammenfassung überprüfen und Beenden auswählen, um die Entfernung durchzuführen, oder Skript auswählen, um zuerst die generierten Befehle zu überprüfen. Überprüfen Sie die Ergebnisse auf erfolgreichen Abschluss, bevor Sie den Zauberer schließen.

Datenbanken mit Skripten entfernen

Entferne die Datenbanken in beiden Instanzen. Die aktuelle Primärinstanz legt fest, welche Instanz zuerst aktualisiert werden soll.

Die PowerShell- und Azure CLI-Beispiele verwenden folgende Variablen:

Wenn SQL Server primär ist

1. Verwenden Sie T-SQL, um die Datenbanken aus der Verfügbarkeitsgruppe zu entfernen.
2. Verwenden Sie PowerShell oder Azure CLI, um die Datenbanken aus dem Link auf der SQL Managed Instance zu entfernen, wie in diesem Abschnitt gezeigt.

Für den SQL Managed Instance-Schritt stellen Sie die vollständige Liste der Datenbanken bereit, die man behalten soll, und lassen Sie nur diejenigen weg, die Sie entfernen möchten. Wenn zum Beispiel der Link DB01, DB03, DB05, , DB07, und DB09enthält, entfernt und behält der folgende Befehl DB05 die anderen vier. Ersetzen Sie die Ressourcen- und Datenbanknamen durch Ihre eigenen Werte.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Wenn SQL Managed Instance primär ist

1. Verwenden Sie PowerShell oder Azure CLI, um die Datenbanken aus dem Link auf der SQL Managed Instance zu entfernen, wie in diesem Abschnitt gezeigt.
2. Verwenden Sie T-SQL auf SQL Server, um die Datenbanken aus der Verfügbarkeitsgruppe zu entfernen. Die Entfernung ist erst abgeschlossen, wenn du diesen Schritt abgeschlossen hast.

Für den SQL Managed Instance-Schritt stellen Sie die vollständige Liste der Datenbanken bereit, die man behalten soll, und lassen Sie nur diejenigen weg, die Sie entfernen möchten. Wenn zum Beispiel der Link DB01, DB03, DB05, , DB07, und DB09enthält, entfernt und behält der folgende Befehl DB05 die anderen vier. Ersetzen Sie die Ressourcen- und Datenbanknamen durch Ihre eigenen Werte.

# Include only the databases to retain, excluding DB05.
$DatabaseNames = @("DB01", "DB03", "DB07", "DB09")

Update-AzSqlInstanceLink -ResourceGroupName $ResourceGroup -InstanceName $ManagedInstanceName -Name $DAGName -Database $DatabaseNames

# Include only the databases to retain, excluding DB05.
DatabaseNames="[{database-name:DB01},{database-name:DB03},{database-name:DB07},{database-name:DB09}]"

az sql mi link update --resource-group "$ResourceGroupName" --instance-name "$ManagedInstanceName" --name "$DAGName" --databases "$DatabaseNames"

Bestätigen Sie, dass die entfernten Datenbanken nicht mehr zur Link- oder Verfügbarkeitsgruppe gehören. Eine Datenbank aus der Replikation zu entfernen ist nicht dasselbe wie das Löschen ihrer behaltenen Kopie. Überprüfen Sie die Datenbanken beider Instanzen, bevor Sie entscheiden, ob Sie eine Kopie löschen, die Sie nicht mehr benötigen.

Zu Azure wechseln oder ein Failover zu Azure ausführen

Verwenden Sie die bestehenden Failover-Prozeduren in SSMS oder Skripten, um die Rollen zwischen SQL Server und Azure SQL Managed Instance umzutauschen. Rollenumkehr erfordert, dass die verwaltete SQL-Instanz die Aktualisierungsrichtlinie verwendet, die zu Ihrer SQL Server-Version passt. Für eine Einweg-Replikation und den Wechsel auf die Azure SQL Managed Instance muss die Aktualisierungsrichtlinie mit der Ihrer SQL Server-Version übereinstimmen oder höher sein. Du kannst keine Daten replizieren oder danach wieder zu SQL Server zurückgreifen, wenn die Richtlinien nicht übereinstimmen. Überprüfen Sie die unterstützten Kombinationen. Anleitungen zur Migration und zum Cutover finden Sie unter Migration mit Link.

Überwachung und Fehlerbehebung von Replikationen

Verwenden Sie die folgenden dynamischen Verwaltungsansichten (DMVs) und die Katalogansicht auf SQL Server, um die Hauptverfügbarkeitsgruppe, die Replikverbindung und die Replikationsgesundheit jeder Datenbank zu überprüfen:

SELECT * FROM sys.availability_groups;
SELECT * FROM sys.dm_hadr_availability_replica_states;
SELECT * FROM sys.dm_hadr_database_replica_states;
SELECT * FROM sys.dm_hadr_internal_availability_groups;
SELECT * FROM sys.dm_hadr_internal_availability_replicas;

Wenn die internen Replikations-DMVs nicht verfügbar sind oder die Ausführung der gespeicherten Prozedur sys.sp_multidb_milink ergibt, dass sie nicht verfügbar ist, überprüfen Sie die installierte SQL Server-Version und das kumulative Update auf diesem Replikat. Für allgemeine Fehlerbehebung von Konnektivität und Replikation siehe Troubleshoot the verwaltete Instanz Link.

Limitations

Beachten Sie die folgenden Einschränkungen bei der Erweiterung einer Verfügbarkeitsgruppe über eine Verbindung mit mehreren Datenbanken:

• Link-Namen müssen Kleinbuchstaben verwenden. Bindestriche sind erlaubt, aber ein Name darf nicht mit einem Bindestrich beginnen oder enden.
• Stufen Sie kein SQL Server-Replikat auf eine Version unterhalb von SQL Server 2022 CU27 bzw. SQL Server 2025 CU9 herab, solange ein Link im Mehrfachdatenbankmodus aktiv ist. Ein Herabstufen unter die erforderliche CU kann auch ohne Failover unvorhersehbare Probleme verursachen.
• Eigenständige Verfügbarkeitsgruppen werden nicht unterstützt.
• Single-database-Links und Multi-Datenbank-Links können nicht auf derselben SQL Server-Instanz koexistieren.
• Du kannst den Modus eines Links nicht dauerhaft ändern. Um zwischen Single-Database- und Multi-Database-Link-Modi zu wechseln, entfernen Sie alle bestehenden Links, ändern Sie den Modus auf jedem SQL Server-Replik und erstellen Sie dann die Links im neuen Modus neu.
• Wenn Sie einen Link für eine bestehende Verfügbarkeitsgruppe erstellen, müssen alle Datenbanken in dieser Gruppe repliziert werden. Du kannst nicht nur eine Teilmenge der Datenbanken in dieser Gruppe auswählen.
• Die verbleibende Datenbankkapazität der Ziel-SQL-verwalteten Instanz begrenzt die Anzahl der Datenbanken, die du replizieren kannst. General Purpose und Business Critical unterstützen bis zu 100 Datenbanken pro Instanz, Next-Gen General Purpose unterstützt bis zu 500. Bestehende Datenbanken werden auf diese Begrenzungen angerechnet. Zum Beispiel hat eine Instanz mit einem Limit von 100 Datenbanken und 10 bestehenden Datenbanken Kapazität für 90 weitere Datenbanken. Weitere Informationen finden Sie unter Ressourcenbegrenzungen.
• Das Hinzufügen von Datenbanken zur Verfügbarkeitsgruppe über die verfügbare Datenbankkapazität der SQL Managed Instance-Zielinstanz hinaus kann auf SQL Server erfolgreich sein, aber die Replikation auf die SQL Managed Instance schlägt fehl. Diese Bedingung kann den Link in einen inkonsistenten Zustand versetzen, der manuelle Entfernung der nicht replizierten Datenbanken aus der Verfügbarkeitsgruppe erfordert.
• Das Hinzufügen von Datenbanken erfolgt über den Link, aber das Entfernen einer Datenbank auf der einen Seite entfernt sie auf der anderen Seite nicht automatisch. Wenn Sie eine Datenbank aus der Verfügbarkeitsgruppe entfernen, bleibt ihre Kopie auf der SQL Managed Instance erhalten. Wenn Sie eine Datenbank aus dem Link in der SQL Managed Instance entfernen, bleibt die Datenbank in der Verfügbarkeitsgruppe ohne Replikation über den Link und benötigt eine manuelle Bereinigung.
• Beim Hinzufügen von Datenbanken zu einem bestehenden Link über SSMS kann man nur Datenbanken mit einem Bereitwilligen Zustand hinzufügen. Man kann keine Datenbanken hinzufügen, die zu einer anderen Verfügbarkeitsgruppe gehören oder bereits einen Namen auf dem Ziel haben.

Verwandte Inhalte

• Übersicht der verwalteten Instanz-Links
• Vorbereiten der Umgebung für den Link
• Konfigurieren des Links mit SSMS
• Bewährte Methoden zum Verwalten des Links
• Probleme mit dem Link beheben