Freigeben über

Transaktionsreplikation mit Azure SQL Managed Instance

  • Artikel

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.

Übersicht

Sie können die Transaktionsreplikation auch verwenden, um Änderungen an Azure SQL Managed Instance an folgende Ziele zu pushen:

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

Hinweis

Um alle Features von Azure SQL Managed Instance verwenden zu können, müssen Sie die neuesten Versionen von SQL Server Management Studio (SSMS) und SQL Server Data Tools (SSDT) verwenden.

Komponenten

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

Diagramm der Replikation mit Azure SQL

Role Azure SQL-Datenbank Verwaltete Azure SQL-Instanz
Herausgeber Nein Ja
Verteiler Nein Ja
Pull-Abonnent Nein Ja
Pushabonnent Yes Ja

Der Verleger veröffentlicht an Tabellen (Artikeln) erfolgte Änderungen, indem die Aktualisierungen zum Verteiler gesendet werden. 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 (beliebige Version, sofern nicht älter als die Herausgeberversion).

Der Abonnent empfängt auf dem Verleger erfolgte Änderungen. 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 Pushabonnent sein.

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

Hinweis

Für andere Versionen von SQL Server, die keine Veröffentlichung in Objekten in Azure unterstützen, können Sie die Methode der erneuten Veröffentlichung von Daten verwenden, um Daten in neuere Versionen von SQL Server verschieben.

Bei dem Versuch, die Replikation mit einer älteren Version zu konfigurieren, können folgende Fehler auftreten: MSSQL_REPL20084 (Der Prozess konnte keine Verbindung mit dem Abonnenten herstellen.) und MSSQL_REPL40532 (Der von der Anmeldung angeforderte Server <Name> kann nicht geöffnet werden. Fehler bei der Anmeldung).

Replikationstypen

Es gibt verschiedene Replikationstypen:

Replikation Azure SQL-Datenbank Verwaltete Azure SQL-Instanz
Standard-Transaktionsreplikation Ja (nur als Abonnent) Ja
Momentaufnahme Ja (nur als Abonnent) Ja
Mergereplikation Nein Nein
Peer-to-Peer Nein Nein
Bidirektional Nein Ja
Aktualisierbare Abonnements Nein Nein

Unterstützungsmatrix

Die Unterstützungsmatrix für die Transaktionsreplikation für Azure SQL Managed Instance ist identisch mit der für SQL Server.

Herausgeber Verteiler Abonnent
SQL Server 2022 SQL Server 2022 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2019 SQL Server 2022
SQL Server 2019		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2017 SQL Server 2022
SQL Server 2019
SQL Server 2017		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2016 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016		 SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2014 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014		 SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2012 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012		 SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2022
SQL Server 2019
SQL Server 2017
SQL Server 2016
SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008		 SQL Server 2014
SQL Server 2012
SQL Server 2008 R2
SQL Server 2008

Verwendung

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

Category Datensynchronisierung Transaktionsreplikation
Vorteile – Aktiv/Aktiv-Unterstützung
– Bidirektional zwischen lokaler und Azure SQL-Datenbank		 – Niedrigere Latenzzeiten
– Transaktionskonsistenz
– Wiederverwendung vorhandener Topologie nach der Migration
Nachteile – Keine Transaktionskonsistenz
– Größere Auswirkung auf die Leistung		 – Keine Veröffentlichung aus Azure SQL-Datenbank
– Hohe Wartungskosten

Häufig verwendete Konfigurationen

Im Allgemeinen müssen sich Verleger und Verteiler gemeinsam entweder in der Cloud oder an einem lokalen Standort befinden. Die folgenden Konfigurationen werden unterstützt:

Verleger mit lokalem Verteiler in SQL Managed Instance

Einzelinstanz als Herausgeber und Verteiler

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

Bei dieser Konfiguration veröffentlicht eine Instanz von SQL Managed Instance Änderungen in einem Verteiler in einer anderen Instanz von SQL Managed Instance, die vielen Instanzen von SQL Managed Instance als Quelle dienen und Änderungen an ein oder mehrere Ziele in Azure SQL-Datenbank, Azure SQL Managed Instance oder SQL Server verteilen kann.

Separate Instanzen als Herausgeber und Verteiler

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

Azure SQL-Datenbank als Abonnent

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 (Anforderungen)

  • 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 sich der Herausgeber/Verteiler in SQL Managed Instance befinden und der Abonnent nicht. Möglicherweise müssen Sie auch die Sicherheitsregel für ausgehenden Datenverkehr der Netzwerksicherheitsgruppe von SQL Managed Instance für allow_linkedserver_outbound für das Zieldiensttag von Port 1433 von virtualnetwork in internet ändern.
  • Platzieren Sie sowohl den Verleger als auch den VerteVerlegeriler in der Cloud oder beide lokal.
  • Konfigurieren Sie VPN-Peering zwischen den virtuellen Netzwerken der Replikationsteilnehmer, sofern die virtuellen Netzwerke unterschiedlich sind.

Hinweis

Möglicherweise tritt beim Herstellen einer Verbindung mit einer Azure Storage-Datei der Fehler 53 auf, wenn Port 445 (ausgehend) der Netzwerksicherheitsgruppe gesperrt ist und der Verteiler eine Azure SQL Managed Instance-Datenbank und der Abonnent ein lokales System ist. Aktualisieren Sie die vNet-Netzwerksicherheitsgruppe, um dieses Problem zu beheben.

Sicherheit

Melden Sie sich unter replAgentUser an.

Für die Transaktionsreplikation verfügt eine Instanz von SQL Managed Instance über eine vordefinierte Anmeldung mit dem Namen replAgentUser. Diese Anmeldung ist ein Mitglied der Serverrolle sysadmin und wird von Replikations-Agents verwendet, die eine Verbindung mit einer Instanz von SQL Managed Instance herstellen müssen, die an der Einrichtung der Transaktionsreplikation beteiligt ist.

Wird die Transaktionsreplikation nicht genutzt, kann die Anmeldung replAgentUser deaktiviert werden. Sie kann später erneut aktiviert werden, wenn Sie die Transaktionsreplikation verwenden möchten.

Begrenzungen

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 dauerhaft ausgeführten Verteilungs-Agents

Die Anzahl der für die fortlaufende Ausführung konfigurierten Verteilungs-Agents ist in Azure SQL Managed Instance auf 30 beschränkt. Um mehr Verteilungs-Agents zu erhalten, 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, haben Sie so immer noch einen Verteiler, der eine Latenz von nur einigen Sekunden verursacht. Wenn eine große Anzahl von Verteilern benötigt wird, sollten Sie eine geplante und keine fortlaufende Konfiguration zu verwenden.

Mit Failovergruppen

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. Löschen von Abonnementmetadaten aus dem Abonnenten. Ausführen des folgenden Skripts auf die Abonnementdatenbank der Instanz von SQL Managed Instance des Abonnenten Ersetzen des Werts <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 Löschen aller Replikationsobjekte aus dem Verleger, indem Sie das folgende Skript in der veröffentlichten Datenbank 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 sich eine Instanz von SQL Managed Instance vom Typ Abonnent Teil einer Failovergruppe ist, sollte die Veröffentlichung so konfiguriert werden, dass eine Verbindung mit dem Failovergruppen-Listenerendpunkt für die als Abonnent fungierende Instanz von SQL Managed Instance hergestellt wird. 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 einem Failover fortgesetzt.
  • Bei einem Failover mit Datenverlust funktioniert die Replikation ebenfalls. Die verlorenen Änderungen werden dann erneut repliziert.
  • Für ein Failover mit Datenverlust, bei dem der Datenverlust aber außerhalb des Aufbewahrungszeitraums der Verteilungsdatenbank liegt, müssen die Administrator*innen der Instanz von SQL Managed Instance die Abonnementdatenbank erneut initialisieren.

Allgemeine Problembehandlung

Transaktionsprotokoll und Transaktionsreplikation

Unter normalen Umständen wird das Transaktionsprotokoll für die Aufzeichnung 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 Schreibworkloads mehr verarbeiten und wird praktisch eine schreibgeschützte 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. Das führt zu einem konstanten Wachstum des Transaktionsprotokolls und schließlich zu einem vollen Transaktionsprotokoll. Es muss sichergestellt werden, dass der Protokollleseauftrag vorhanden 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 zum Beheben von Abfragetimeouts besteht darin, die Einstellung für Abfragetimeouts für den Auftrag des Protokolllese-Agents 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. Beenden Sie es zuerst, und öffnen Sie dann ihre Eigenschaften. Suchen Sie step 2 und bearbeiten Sie sie. 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 markiert die einzige verfügbare Entschärfung alle Transaktionen, die als verarbeitet repliziert werden sollen, 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.

Hinweis

Nach der Durchführung der Entschärfung müssen Sie die Replikation erneut initialisieren, was bedeutet, dass das Replizieren des gesamten Datasets erneut erfolgt. Dies ist die Größe des Datenvorgangs und kann je nach Datenmenge, die repliziert werden soll, lange ausgeführt werden.

Um die Entschärfung durchzuführen, müssen Sie zuerst den Protokolllese-Agent für den Vertriebspartner 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:

Zugehöriger Inhalt