Transaktionsreplikation mit Azure SQL Managed Instance

Gilt für:Azure SQL Managed Instance

Transaktionsreplikation ist ein Feature von Azure SQL Managed Instance und SQL Server, das Ihnen die Replikation von Daten aus einer Tabelle in einer Instanz von Azure SQL Managed Instance oder SQL Server in Tabellen ermöglicht, die in Remotedatenbanken gespeichert sind. Mit diesem Feature können Sie mehrere Tabellen in unterschiedlichen Datenbanken synchronisieren.

Overview

Sie können die Transaktionsreplikation verwenden, um Änderungen an einer Azure SQL Managed Instance zu übermitteln:

• Eine SQL Server-Datenbank (lokal oder auf Azure-VMs)
• Eine Datenbank in Azure SQL-Datenbank
• Eine Datenbank in azure SQL Managed Instance

Components

Die wichtigsten Komponenten der Transaktionsreplikation (Verleger, Verteiler und Abonnent) sind in der folgenden Abbildung dargestellt:

Der Publisher veröffentlicht Änderungen an einigen Tabellen (Artikeln), indem er die Aktualisierungen an den Verteiler sendet. Der Herausgeber kann Azure SQL Managed Instance oder eine SQL Server-Instanz sein.

Der Verteiler sammelt Änderungen an den Artikeln von einem Verleger und verteilt sie an die Abonnenten. Der Verteiler kann entweder eine Azure SQL Managed Instance oder eine SQL Server Instanz sein (jede Version, solange sie gleich oder neuer als die Herausgeberversion ist).

Der Abonnent empfängt Änderungen, die beim Publisher vorgenommen wurden. Eine SQL Server-Instanz und Azure SQL Managed Instance können sowohl Push- als auch Pullabonnenten sein. Ein Pullabonnement wird jedoch nicht unterstützt, wenn der Verteiler eine Instanz von Azure SQL Managed Instance ist und der Abonnent nicht. Eine Datenbank in Azure SQL-Datenbank kann nur ein Push-Abonnement sein.

Azure SQL Managed Instance kann als Abonnent der folgenden Versionen von SQL Server fungieren:

• SQL Server 2016 und höher
• SQL Server 2014 RTM CU10 (12.0.4427.24) oder SP1 CU3 (12.0.2556.4)
• SQL Server 2012 SP2 CU8 (11.0.5634.1) oder SP3 (11.0.6020.0) oder SP4 (11.0.7001.0)

Replikationstypen

Es gibt verschiedene Replikationstypen:

Unterstützungsmatrix

Die Matrix für die Unterstützung von Transaktions- und Snapshot-Replikation für Azure SQL Managed Instance entspricht derjenigen für SQL Server.

^AUTD- Gilt für Azure SQL Managed Instance-Instanzen, die mit der Updaterichtlinie konfiguriert sind, die sicherstellt, dass die Instanzen immer auf dem neuesten Stand sind.
²⁰²⁵ Gilt für azure SQL Managed Instance, die mit der SQL Server 2025-Updaterichtlinie konfiguriert ist.
²⁰²² gilt für azure SQL Managed Instance, die mit der SQL Server 2022-Updaterichtliniekonfiguriert ist.
¹ Gilt basierend auf den Anforderungen der unterstützten Konfigurationen für die SQL-Datenbank in Microsoft Fabric.

Wann zu verwenden

Die Transaktionsreplikation ist in den folgenden Szenarien nützlich:

• Veröffentlichen von Änderungen an Tabellen in einer Datenbank, die an eine oder mehrere Datenbanken in einer SQL Server-Instanz oder eine Azure SQL-Datenbank-Instanz verteilt werden, die die Änderungen abonniert haben
• Synchronisierthalten mehrerer verteilter Datenbanken
• Migrieren von Datenbanken aus einer SQL Server-Instanz oder Azure SQL Managed Instance in eine andere Datenbank durch fortlaufendes Veröffentlichen der Änderungen

Vergleich von Datensynchronisierung und Transaktionsreplikation

Allgemeine Konfigurationen

Im Allgemeinen müssen sich der Publisher und der Distributor entweder in der Cloud oder lokal befinden. Die folgenden Konfigurationen werden unterstützt:

Verleger mit lokalem Verteiler in SQL Managed Instance

Herausgeber und Verteiler sind in einer einzelnen Instanz von SQL Managed Instance konfiguriert und verteilen Änderungen an eine andere Instanz von SQL Managed Instance, SQL-Datenbank oder SQL Server.

Verleger mit Remoteverteiler in SQL Managed Instance

In dieser Konfiguration veröffentlicht eine SQL Managed Instance Änderungen an einen Verteiler, der sich in einer anderen SQL Managed Instance befindet. Dieser Verteiler kann vielen Quell-SQL Managed Instances dienen und Änderungen an ein oder mehrere Ziele in Azure SQL-Datenbank, Azure SQL Managed Instance oder SQL Server verteilen.

Verleger und Verteiler werden in zwei verwalteten Instanzen konfiguriert. Bei dieser Konfiguration gibt es einige Einschränkungen:

• Beide verwaltete Instanzen befinden sich im gleichen VNET.
• Die beiden verwalteten Instanzen befinden sich am gleichen Standort.

Lokaler Verleger/Verteiler mit Remoteabonnent

Bei dieser Konfiguration ist eine Datenbank in Azure SQL-Datenbank oder Azure SQL Managed Instance ein Abonnent. Diese Konfiguration unterstützt die Migration vom lokalen Standort zu Azure. Für einen Abonnenten in einer Datenbank in Azure SQL-Datenbank muss der Pushmodus aktiviert sein.

Requirements

• Für die Verbindung zwischen Teilnehmern an der Replikation wird SQL-Authentifizierung verwendet.
• Nutzen Sie für das von der Replikation verwendete Arbeitsverzeichnis eine Azure Storage-Kontofreigabe.
• Öffnen Sie den ausgehenden TCP-Port 445 in den Sicherheitsregeln des Subnetzes, um auf die Azure-Dateifreigabe zuzugreifen.
• Öffnen Sie den ausgehenden TCP-Port 1433, wenn die SQL Managed Instance als Herausgeber/Verteiler fungiert und der Abonnent dies nicht tut. Möglicherweise müssen Sie auch die Ausgangssicherheitsregel der Netzwerksicherheitsgruppe von SQL Managed Instance für allow_linkedserver_outbound ändern, um das Dienstziel-Tag von Port 1433 von virtualnetwork auf internet zu setzen.
• Platzieren Sie sowohl den Verleger als auch den Verteiler in der Cloud oder beide vor Ort.
• Konfigurieren Sie VPN-Peering zwischen den virtuellen Netzwerken der Replikationsteilnehmer, sofern die virtuellen Netzwerke unterschiedlich sind.

Security

Unterstützung für TLS 1.3

Azure SQL Managed Instance unterstützt TLS 1.3 für Replikationsverbindungen, die von Agents initialisiert werden, die für die Ausführung auf einer SQL-verwalteten Instanz konfiguriert sind. Dies gilt für eine Replikationstopologie zwischen zwei SQL-verwalteten Instanzen und auch für jede Version von SQL Server als Abonnent von einem Publisher und Distributor einer SQL-verwalteten Instanz.

Wenn Sie TLS 1.3 zum Sichern der Verbindungen zwischen Instanzen in einer Replikationstopologie verwenden, geben Sie den Wert 3 oder 4 für den Parameter "-EncryptionLevel " jedes Replikations-Agents an:

• Verteilungs-Agent
• Protokollleseagent
• Snapshot-Agent

Ein Wert von 3 erzwingt TLS 1.3-Verbindungen mit verwalteten SQL-Instanzen, hat jedoch keine Auswirkung auf Verbindungen zu SQL-Servern. Ein Wert von 4 erzwingt TLS 1.3-Verbindungen zwischen SQL-verwalteten Instanzen sowie Verbindungen von der SQL-verwalteten Instanz zu SQL Server und erfordert, dass Sie das Zertifikat auf dem SQL Server-Host installieren.

Melden Sie sich unter replAgentUser an.

Instanzen, die mit einem Verteilungs- oder Snapshot-Agent konfiguriert sind, haben die replAgentUser Anmeldung automatisch erstellt. Der Distributions- und Snapshot-Agent verwendet die replAgentUser Anmeldung, um eine Verbindung mit der jeweiligen Datenbank herzustellen. Für ein Pushabonnement wird der Login für den Distributor erstellt. Bei einem Pull- oder anonymen Abonnement wird die Benutzeranmeldung auf dem Abonnenten erstellt. Die Anmeldung ist ein Mitglied der festen db_owner Datenbankrolle in der Verteilungs- oder Abonnementdatenbank.

Die replAgentUser Anmeldung wird automatisch erstellt, wenn der Replikations-Agent zum ersten Mal gestartet wird. Die Anmeldung wird automatisch von Distributor gelöscht, wenn die gespeicherte sp_dropdistributor Prozedur ausgeführt wird. Der Login wird automatisch vom Abonnenten gelöscht, wenn das letzte Pull- oder anonyme Abonnement gelöscht wird.

Limitations

Die Transaktionsreplikation weist einige Einschränkungen auf, die für Azure SQL Managed Instance spezifisch sind. Weitere Informationen zu diesen Einschränkungen finden Sie in diesem Abschnitt.

Momentaufnahmedateien werden nicht aus dem Azure Storage-Konto gelöscht.

Azure SQL Managed Instance verwendet ein benutzerseitig konfiguriertes Azure Storage-Konto für Momentaufnahmedateien, die für die Transaktionsreplikation verwendet werden. Im Gegensatz zu SQL Server in der lokalen Umgebung löscht Azure SQL Managed Instance keine Momentaufnahmedateien aus dem Azure Storage-Konto. Wenn Dateien nicht mehr benötigt werden, sollten Sie sie löschen. Dies kann über die Azure Storage-Schnittstelle im Azure-Portal, Microsoft Azure Storage-Explorer oder über Befehlszeilenclients (Azure PowerShell oder CLI) oder die Azure Storage Management-REST-API erfolgen.

Im Folgenden finden Sie ein Beispiel dafür, wie Sie eine Datei und einen leeren Ordner löschen können.

az storage file delete-batch --source <file_path> --account-key <account_key> --account-name <account_name>
az storage directory delete --name <directory_name> --share-name <share_name> --account-key <account_key> --account-name <account_name>

Anzahl der Verteilungs-Agenten, die kontinuierlich ausgeführt werden

Die Anzahl der für die fortlaufende Ausführung konfigurierten Verteilungs-Agents ist in Azure SQL Managed Instance auf 30 beschränkt. Um mehr Verteilungsagenten zu haben, müssen sie entweder bedarfsgesteuert oder nach einem definierten Zeitplan ausgeführt werden. Der Zeitplan kann mit täglicher Häufigkeit und Wiederholungen alle 10 Sekunden (oder mehr) definiert werden. Auch wenn er nicht kontinuierlich ist, können Sie dennoch einen Verteiler haben, der lediglich eine Latenz von einigen Sekunden einführt. Wenn eine große Anzahl von Verteilern benötigt wird, sollten Sie eine geplante und keine fortlaufende Konfiguration verwenden.

Mit Ausfallgruppen

Die Verwendung der Transaktionsreplikation mit Instanzen, die sich in einer Failovergruppe befinden, wird unterstützt. Wenn Sie jedoch die Replikation konfigurieren, bevor Sie Ihre Instanz von SQL Managed Instance einer Failovergruppe hinzufügen, wird die Replikation angehalten, wenn Sie mit der Erstellung Ihrer Failovergruppe beginnen, und im Replikationsmonitor wird der Status Replicated transactions are waiting for the next log backup or for mirroring partner to catch up angezeigt. Die Replikation wird fortgesetzt, sobald die Failovergruppe erfolgreich erstellt wurde.

Wenn eine als Herausgeber oder Verteiler fungierende Instanz von SQL Managed Instance Teil einer Failovergruppe ist, müssen die SQL Managed Instance-Administrator*innen alle Veröffentlichungen für die alte primäre Instanz bereinigen und nach einem Failover für die neue primäre Instanz erneut konfigurieren. Die folgenden Aktivitäten sind in diesem Szenario erforderlich:

1. Beenden aller Replikationsaufträge, die für die Datenbank ausgeführt werden, sofern vorhanden.

2. Löschen der Abonnementmetadaten vom Herausgeber, indem das folgende Skript für die Herausgeberdatenbank ausgeführt wird. Ersetzen der Werte <name of publication> und <name of subscriber>

   EXEC sp_dropsubscription @publication = '<name of publication>',
       @article = 'all',
       @subscriber = '<name of subscriber>'
   

3. Entfernen von Abonnementmetadaten vom Abonnenten. Führen Sie das folgende Skript in der Abonnementdatenbank der SQL Managed Instance des Abonnenten aus. Ersetzen Sie den Wert <full DNS of publisher>. Zum Beispiel example.ac2d23028af5.database.windows.net:

   EXEC sp_subscription_cleanup
      @publisher = N'<full DNS of publisher>',
      @publisher_db = N'<publisher database>',
      @publication = N'<name of publication>';
   

4. Erzwingen Sie das Entfernen aller Replikationsobjekte vom Publisher, indem Sie in der veröffentlichten Datenbank das folgende Skript ausführen.

   EXEC sp_removedbreplication;
   

5. Erzwingen Sie das Löschen des alten Verteilers aus der ursprünglichen primären Instanz von SQL Managed Instance (bei einem Failback auf eine alte primäre Instanz, die einen Verteiler hatte). Führen Sie das folgende Skript in der master-Datenbank in der alten als Verteiler fungierenden Instanz von SQL Managed Instance aus:

   EXEC sp_dropdistributor 1, 1;
   

Wenn eine SQL Managed Instance vom Typ Abonnent Teil einer Failovergruppe ist, sollte die Veröffentlichung so konfiguriert werden, dass sie eine Verbindung mit dem Listener-Endpunkt der Failovergruppe für die Abonnenten-SQL-Managed Instance herstellt. Im Fall eines Failovers hängt die nachfolgende Aktion durch die Administrator*innen der Instanz von SQL Managed Instance vom Failovertyp ab, der aufgetreten ist:

• Bei einem Failover ohne Datenverlust wird die Replikation nach dem Failover fortgesetzt.
• Bei einem Failover mit Datenverlust funktioniert die Replikation ebenfalls. Die verlorenen Änderungen werden dann erneut repliziert.
• Für ein Failover mit Datenverlust, der aber außerhalb des Aufbewahrungszeitraums der Verteilungsdatenbank liegt, müssen die SQL Managed Instance-Administrator*innen die Abonnementdatenbank erneut initialisieren.

Behandlung häufiger Probleme

Transaktionsprotokoll und Transaktionsreplikation

In der Regel wird das Transaktionsprotokoll zum Aufzeichnen von Änderungen der Daten in einer Datenbank verwendet. Änderungen werden im Transaktionsprotokoll aufgezeichnet, wodurch mehr Speicherplatz für das Protokoll benötigt wird. Es gibt außerdem einen automatischen Prozess, der ein sicheres Abschneiden des Transaktionsprotokolls ermöglicht. Dieser Prozess reduziert den für das Protokoll belegten Speicherplatz. Wenn die Veröffentlichung für die Transaktionsreplikation konfiguriert ist, wird das Abschneiden des Transaktionsprotokolls verhindert, bis Änderungen im Protokoll vom Protokollleseauftrag verarbeitet werden. In einigen Fällen wird die Verarbeitung des Transaktionsprotokolls praktisch blockiert. Das kann dazu führen, dass der gesamte für das Transaktionsprotokoll reservierte Speicher gefüllt wird. Wenn kein freier Speicherplatz für das weitere Anwachsen des Transaktionsprotokolls vorhanden ist, ist das Transaktionsprotokoll voll. In diesem Zustand kann die Datenbank keine Schreiboperationen mehr verarbeiten und wird effektiv zu einer schreibgeschützten Datenbank.

Deaktivierter Protokolllese-Agent

Manchmal ist die Veröffentlichung der Transaktionsreplikation für eine Datenbank konfiguriert, der Protokolllese-Agent jedoch nicht für die Ausführung konfiguriert. In diesem Fall werden Änderungen im Transaktionsprotokoll akkumuliert und nicht verarbeitet. Dies führt zu einem konstanten Wachstum des Transaktionsprotokolls und schließlich zum vollständigen Transaktionsprotokoll. Der Benutzer sollte sicherstellen, dass der Protokolllesedienst existiert und aktiv ist. Alternativ kann die Transaktionsreplikation deaktiviert werden, wenn sie nicht benötigt wird.

Abfragetimeouts des Protokolllese-Agents

Manchmal kann der Protokollleseauftrag aufgrund wiederholter Abfragetimeouts keine wirklichen Fortschritte erzielen. Eine Möglichkeit, Abfragetimeouts zu beheben, besteht darin, die Timeout-Einstellung für den Job des Protokollleseagents zu erhöhen.

Das Erhöhen des Abfrage-Timeouts für den Protokollleserauftrag kann mit SSMS erfolgen. Suchen Sie im Objekt-Explorer unter SQL Server-Agent den Auftrag, den Sie ändern möchten. Stoppen Sie es zuerst, und öffnen Sie dann seine Eigenschaften. Suchen Sie step 2 und bearbeiten Sie es. Fügen Sie den Befehlswert mit -QueryTimeout <timeout_in_seconds> an. Versuchen Sie für den Abfrage-Timeoutwert 21600 oder höher. Starten Sie schließlich den Auftrag erneut.

Maximale Größe des Protokollspeichers von 2 TB erreicht

Wenn die Größe des Transaktionsprotokollspeichers maximal 2 TB erreicht, kann das Protokoll physisch nicht größer werden als das. In diesem Fall besteht die einzige verfügbare Maßnahme darin, alle Transaktionen, die repliziert werden sollen, als verarbeitet zu markieren, damit das Transaktionsprotokoll abgeschnitten werden kann. Dies bedeutet effektiv, dass die verbleibenden Transaktionen im Protokoll nicht repliziert werden und dass Sie die Replikation neu initialisieren müssen.

Um die Entschärfung durchzuführen, müssen Sie als Erstes den Protokolllese-Agent auf dem Verteiler beenden. Anschließend sollten Sie die gespeicherte Prozedur sp_repldone ausführen, wobei die Kennzeichnung reset in der Verlegerdatenbank auf 1 festgelegt ist, um das Abschneiden des Transaktionsprotokolls zu ermöglichen. Dieser Befehl sollte wie folgt aussehen EXEC sp_repldone @xactid = NULL, @xact_seqno = NULL, @numtrans = 0, @time = 0, @reset = 1. Danach müssen Sie die Replikation erneut initialisieren.

Nächste Schritte

Weitere Informationen zum Konfigurieren von Transaktionsreplikation finden Sie in den folgenden Tutorials:

• Konfigurieren der Replikation zwischen einem SQL Managed Instance-Herausgeber und -Abonnenten.
• Konfigurieren der Replikation zwischen einem SQL Managed Instance-Herausgeber, SQL Managed Instance-Verteiler und SQL Server-Abonnenten.
• Erstellen Sie eine Veröffentlichung.
• Erstellen Sie ein Pushabonnement mit dem Servernamen als Abonnent (z. B. N'azuresqldbdns.database.windows.net) und dem Namen der Datenbank in Azure SQL-Datenbank als Zieldatenbank (z. B. Adventureworks).

Verwandte Inhalte

• Replikation mit einer SQL Managed Instance und einer Failovergruppe
• Replikation zur SQL-Datenbank
• Replikation zu einer verwalteten Instanz
• Erstellen einer Veröffentlichung
• Erstellen eines Pushabonnements
• Replikationstypen
• Überwachung (Replikation)
• Initialisieren eines Abonnements