Transaktionsreplikation

Gilt für:SQL ServerAzure SQL-DatenbankAzure SQL Managed Instance

In diesem Artikel wird die Transaktionsreplikation für SQL Server eingeführt. Eine Transaktionsreplikation beginnt in der Regel mit einer Momentaufnahme des Veröffentlichungsdatenbankobjekts und der entsprechenden Daten. Sobald die erste Momentaufnahme erstellt wurde, werden nachfolgende Datenänderungen und Schemamodifikationen, die beim Publisher vorgenommen werden, in der Regel an den Subscriber übermittelt, sobald sie auftreten (fast in Echtzeit). Die Datenänderungen werden auf dem Abonnenten in derselben Reihenfolge und mit denselben Transaktionsgrenzen angewendet, in der sie auf dem Verleger stattgefunden haben. Auf diese Weise wird die Transaktionskonsistenz innerhalb einer Veröffentlichung sichergestellt.

Überblick

Die Transaktionsreplikation wird typischerweise in Server-zu-Server-Umgebungen verwendet und ist in jedem der folgenden Fälle geeignet:

  • Sie möchten, dass inkrementelle Änderungen an Abonnenten weitergegeben werden, sobald sie auftreten.

  • Die Anwendung benötigt eine niedrige Latenzzeit zwischen dem Zeitpunkt, zu dem Änderungen auf dem Verleger vorgenommen werden, und dem Zeitpunkt, zu dem die Änderungen auf dem Abonnenten eintreffen.

  • Die Anwendung erfordert Zugriff auf Zwischenzustände von Daten. Wenn eine Zeile sich z. B. fünfmal ändert, kann die Anwendung bei Verwendung der Transaktionsreplikation auf jede Änderung reagieren (indem sie z. B. einen Trigger auslöst) und nicht nur auf das endgültige Ergebnis aller Zeilenänderungen.

  • Der Publisher weist ein sehr hohes Aufkommen an Einfüge-, Aktualisierungs- und Löschvorgängen auf.

  • Der Herausgeber oder Abonnent ist eine Nicht-SQL-Server-Datenbank, wie z. B. eine Oracle-Datenbank.

Standardmäßig sollten Abonnenten von Transaktionspublikationen mit nur-Lesezugriff behandelt werden, da Änderungen nicht an den Publisher weitergegeben werden. Die Transaktionsreplikation bietet jedoch auch Optionen, die Aktualisierungen beim Abonnenten zulassen.

Hinweis

Azure SQL Managed Instance kann als Herausgeber, Distributor und Abonnent für die Momentaufnahmen- und die Transaktionsreplikation fungieren. Datenbanken in Azure SQL-Datenbank können nur Pushabonnenten für die Momentaufnahme- und Transaktionsreplikation sein. Weitere Informationen finden Sie unter „Transaktionsreplikation mit Azure SQL-Datenbank und Azure SQL Managed Instance“.

Konfigurieren der TLS 1.3-Verschlüsselung

SQL Server 2025 (17.x) führt die TDS 8.0-Unterstützung für die Transaktionsreplikation ein, die Folgendes umfasst:

  • Konfigurieren von Replikations-Agents für die Verwendung der TLS 1.3-Verschlüsselung zwischen Instanzen von SQL Server 2025 (17.x) und zwischen SQL Server 2025 (17.x) und azure SQL Managed Instance.
  • Standardverschlüsselung für die Kommunikation zwischen Instanzen von verknüpften Servern in einer SQL Server 2025 (17.x)-Replikationstopologie. Verknüpfte Server in SQL Server 2025 (17.x) verwenden den OLE DB v19-Treiber, der standardmäßig auf Verschlüsselung festgelegt Encrypt=Mandatory ist.

Funktionsweise der Transaktionsreplikation

Die Transaktionsreplikation wird durch den SQL Server Snapshot-Agent, den Log Reader-Agent und den Distribution-Agent implementiert. Der Snapshot-Agent erstellt Snapshotdateien, die das Schema und die Daten veröffentlichter Tabellen und Datenbankobjekte enthalten, speichert die Dateien im Snapshotordner und erfasst Synchronisierungsaufträge in der Verteilungsdatenbank beim Verteiler.

Der Protokolllese-Agent überwacht das Transaktionsprotokoll jeder für die Transaktionsreplikation konfigurierten Datenbank und kopiert die für die Replikation markierten Transaktionen aus dem Transaktionsprotokoll in die Verteilungsdatenbank, die als zuverlässige Warteschlange zum Speichern und Weiterleiten fungiert. Der Verteilungs-Agent kopiert die Dateien der anfänglichen Momentaufnahme aus dem Snapshotordner sowie die in den Tabellen der Verteilungsdatenbank gespeicherten Transaktionen an die Abonnenten.

Am Publisher vorgenommene inkrementelle Änderungen werden gemäß dem Zeitplan des Distribution-Agents an die Subscriber weitergeleitet, wobei dieser zur Minimierung der Latenz kontinuierlich oder in geplanten Intervallen ausgeführt werden kann. Da Änderungen an den Daten beim Verleger vorgenommen werden müssen (wenn die Transaktionsreplikation ohne Optionen für sofortige oder in Warteschlangen ausgeführte Aktualisierungen verwendet wird), werden Aktualisierungskonflikte vermieden. Letztlich erreichen alle Abonnenten dieselben Werte wie der Verleger. Wenn bei der Transaktionsreplikation die Optionen für sofortige Aktualisierung oder Aktualisierung in der Warteschlange verwendet werden, können Aktualisierungen am Abonnenten vorgenommen werden, und bei der Aktualisierung in der Warteschlange können Konflikte auftreten.

Die folgende Abbildung zeigt die wichtigsten Komponenten der Transaktionsreplikation.

Komponenten und Datenfluss der Transaktionsreplikation

Anfangsdataset

Bevor ein neuer Abonnent einer Transaktionsreplikation inkrementelle Änderungen von einem Verleger erhalten kann, muss der Abonnent Tabellen mit demselben Schema und denselben Daten wie die Tabellen auf dem Verleger enthalten. Das Anfangsdataset ist in der Regel eine Momentaufnahme, die vom Momentaufnahme-Agent erstellt und vom Verteilungs-Agent verteilt und angewendet wird. Das erste Dataset kann auch über ein Backup oder andere Mittel wie SQL Server Integration Services bereitgestellt werden.

Wenn Snapshots an Abonnenten verteilt und bei ihnen angewendet werden, sind nur diejenigen Abonnenten betroffen, die auf initiale Snapshots warten. Andere Abonnenten für diese Veröffentlichung (diejenigen, die bereits initialisiert wurden) sind nicht betroffen.

Gleichzeitige Momentaufnahmeverarbeitung

Bei der Momentaufnahmegenerierung werden für die Dauer der Momentaufnahmegenerierung freigegebene Sperren auf allen Tabellen platziert, die als Teil der Replikation veröffentlicht werden. So kann verhindert werden, dass Updates in den veröffentlichten Tabellen ausgeführt werden. Bei gleichzeitiger Momentaufnahmeverarbeitung, der Standard bei der Transaktionsreplikation, werden die Freigabesperren während der gesamten Momentaufnahmegenerierung nicht beibehalten, sodass Benutzer unterbrechungsfrei arbeiten können, während die Replikation erste Snapshotdateien erstellt.

Momentaufnahme-Agent

Die Prozeduren, mit denen der Snapshot-Agent die erste Momentaufnahme in der Transaktionsreplikation implementiert, sind die gleichen Verfahren, die in der Snapshotreplikation verwendet werden (mit Ausnahme der zuvor beschriebenen Darstellung in Bezug auf die gleichzeitige Momentaufnahmeverarbeitung).

Nach dem Generieren der Momentaufnahmedateien können Sie sie mithilfe von Microsoft Windows-Explorer im Momentaufnahmeordner anzeigen.

Ändern von Daten und der Protokolllese-Agent

Der Protokolllese-Agent wird auf dem Verteiler ausgeführt. In der Regel wird er fortlaufend ausgeführt, Sie können jedoch auch einen Zeitplan für die Ausführung festlegen. Bei der Ausführung liest der Protokolllese-Agent zuerst das Publikationstransaktionsprotokoll (dasselbe Datenbankprotokoll, das für die Nachverfolgung und Wiederherstellung von Transaktionen während regulärer SQL Server-Datenbank-Engine Vorgänge verwendet wird) und identifiziert alle INSERT, UPDATEund DELETE Anweisungen oder andere Änderungen an den Daten in Transaktionen, die für die Replikation markiert wurden. Danach kopiert der Agent diese Transaktionen chargenweise in die Verteilungsdatenbank beim Verteiler. Der Protokolllese-Agent verwendet die intern gespeicherte Prozedur sp_replcmds zum Abrufen des nächsten Satzes von Befehlen aus dem Protokoll, die für die Replikation markiert wurden. Die Verteilungsdatenbank wird dann zur Warteschlange zum Speichern und Weiterleiten, von der aus Änderungen an die Abonnenten gesendet werden. Nur Transaktionen, für die ein Commit ausgeführt wurde, werden an die Verteilungsdatenbank gesendet.

Nachdem der gesamte Transaktionsstapel erfolgreich in die Verteilungsdatenbank geschrieben wurde, wird er festgeschrieben. Nachdem jede Befehlscharge an den Distributor committet wurde, ruft der Protokolllese-Agent sp_repldone auf, um zu markieren, bis zu welcher Stelle die Replikation zuletzt abgeschlossen wurde. Schließlich markiert der Agent die Zeilen im Transaktionsprotokoll, die gelöscht werden können. Zeilen, die noch auf die Replikation warten, werden nicht gelöscht.

Transaktionsbefehle werden in der Verteilungsdatenbank gespeichert, bis sie an alle Abonnenten weitergegeben werden oder bis der maximale Aufbewahrungszeitraum für Verteilung erreicht wurde. Abonnenten erhalten Transaktionen in der gleichen Reihenfolge, in der sie auf den Verleger angewendet wurden.

Verteilungs-Agent

Der Verteilungs-Agent wird für Pushabonnements auf dem Verteiler und für Pullabonnements auf dem Abonnenten ausgeführt. Der Agent verschiebt Transaktionen aus der Verteilungsdatenbank auf den Abonnenten. Wenn ein Abonnement für die Überprüfung markiert ist, überprüft der Verteilungs-Agent auch, ob die Daten auf dem Verleger und dem Abonnenten übereinstimmen.

Veröffentlichungstypen

Die Transaktionsreplikation stellt vier Veröffentlichungstypen bereit:

Veröffentlichungstyp Beschreibung
Standardmäßige Transaktionsveröffentlichung Geeignet für Topologien, in denen alle Daten beim Abonnenten nur gelesen werden können (Transaktionsreplikation erzwingt diese Einschränkung nicht beim Abonnenten).

Diese Transaktionsveröffentlichungen werden standardmäßig bei der Verwendung von Transact-SQL oder Replikationsverwaltungsobjekten (RMO) erstellt. Wenn Sie den Assistenten für neue Publikationen verwenden, werden die Publikationen erstellt, indem Sie auf der Seite "Publikationstyp" die Transaktionspublikation auswählen.

Weitere Informationen zum Erstellen von Veröffentlichungen finden Sie unter Veröffentlichen von Daten und Datenbankobjekten.
Transaktionale Publikation mit aktualisierbaren Abonnements Dieser Veröffentlichungstyp weist die folgenden Merkmale auf:

– Jeder Standort verfügt über identische Daten mit jeweils einem Publisher und einem Subscriber.
– Zeilen können beim Abonnenten aktualisiert werden.
– Diese Topologie eignet sich für Serverumgebungen am besten, die Hochverfügbarkeit und Leseskalierbarkeit erfordern.

Weitere Informationen finden Sie unter Aktualisierbare Abonnements.
Peer-zu-Peer-Topologie Dieser Veröffentlichungstyp weist die folgenden Merkmale auf:
– Jeder Speicherort verfügt über identische Daten und wird gleichzeitig als Verleger und Abonnent genutzt.
– Die gleiche Zeile kann jeweils nur an einer Stelle gleichzeitig geändert werden.
– Die Konflikterkennung wird unterstützt.
– Diese Topologie eignet sich am besten für Serverumgebungen, die Hochverfügbarkeit und Leseskalierbarkeit erfordern.

Weitere Informationen finden Sie unter Peer-to-Peer Transactional Replication.
Bidirektionale Transaktionsreplikation Dieser Veröffentlichungstyp weist die folgenden Merkmale auf:
Die bidirektionale Replikation ähnelt der Peer-to-Peer-Replikation, bietet jedoch keine Konfliktlösung. Darüber hinaus ist die bidirektionale Replikation auf zwei Server beschränkt.

Weitere Informationen finden Sie unter Bidirektionale Transaktionsreplikation.