Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Erstellen von Aufgaben für die laufende Replikation mit AWS DMS
Sie können eine AWS DMS Aufgabe erstellen, die laufende Änderungen aus dem Quelldatenspeicher erfasst. Diese Erfassung kann erfolgen, während Sie Ihre Daten migrieren. Sie können auch eine Aufgabe erstellen, die laufende Änderungen erfasst, nachdem Sie Ihre erste (Full-Load) Migration auf einen unterstützten Zieldatenspeicher abgeschlossen haben. Dieser Vorgang wird als fortlaufende Replikation oder Change Data Capture (CDC) bezeichnet. AWS DMS verwendet diesen Prozess, wenn laufende Änderungen aus einem Quelldatenspeicher repliziert werden. Bei diesem Prozess werden Änderungen an den Datenbankprotokollen mithilfe der Datenbank-Engine der nativen API erfasst.
Anmerkung
Sie können Ansichten nur mithilfe von Full-Load-Aufgaben migrieren. Wenn es sich bei Ihrer Aufgabe entweder um eine reine CDC-Aufgabe oder eine Full-Load-Aufgabe handelt, die CDC nach ihrem Abschluss startet, enthält die Migration nur Tabellen aus der Quelle. Mithilfe einer full-load-only Aufgabe können Sie Ansichten oder eine Kombination aus Tabellen und Ansichten migrieren. Weitere Informationen finden Sie unter Festlegen der Tabellenauswahl- und Transformationsregeln mit JSON.
Jede Quell-Engine verfügt über spezifische Konfigurationsanforderungen für die Bereitstellung dieses Änderungsstroms für ein bestimmtes Benutzerkonto. Die meisten Engines erfordern eine zusätzliche Konfiguration, damit der Erfassungsprozess die Änderungsdaten sinnvoll und ohne Datenverlust verwerten kann. Zum Beispiel erfordert Oracle eine zusätzliche Protokollierung und MySQL eine binäre Protokollierung auf Zeilenebene.
Um laufende Änderungen aus der Quelldatenbank zu lesen, AWS DMS verwendet Engine-spezifische API-Aktionen, um Änderungen aus den Transaktionsprotokollen der Quell-Engine zu lesen. Im Folgenden finden Sie einige Beispiele dafür, wie AWS DMS das funktioniert:
-
AWS DMS Verwendet für Oracle entweder die LogMiner Oracle-API oder die Binary-Reader-API (bfile-API), um laufende Änderungen zu lesen. AWS DMS liest laufende Änderungen anhand der System Change Number (SCN) aus den Online- oder Archiv-Redo-Logs.
-
AWS DMS Verwendet für Microsoft SQL Server MS-Replikation oder MS-CDC, um Informationen in das SQL Server-Transaktionsprotokoll zu schreiben. Anschließend wird die Funktion
fn_dblog()
oderfn_dump_dblog()
in SQL Server zum Lesen der Änderungen im Transaktionsprotokoll basierend auf der Log-Sequenznummer (LSN) verwendet. -
AWS DMS Liest für MySQL Änderungen aus den zeilenbasierten Binärprotokollen (Binlogs) und migriert diese Änderungen auf das Ziel.
-
Für PostgreSQL richtet es logische AWS DMS Replikationsslots ein und verwendet das test_decoding-Plugin, um Änderungen aus der Quelle zu lesen und sie zum Ziel zu migrieren.
-
Für Amazon RDS als Quelle sollten Sie sicherstellen, dass zur Einrichtung von CDC Sicherungen aktiviert sind. Wir empfehlen außerdem, sicherzustellen, dass die Quelldatenbank so konfiguriert ist, dass Änderungsprotokolle ausreichend lange beibehalten werden – in der Regel sind 24 Stunden genug. Spezifische Einstellungen für die einzelnen Endpunkte finden Sie in den folgenden Themen:
Amazon RDS für Oracle: Konfiguration einer AWS-verwalteten Oracle-Quelle für AWS DMS.
Amazon RDS für MySQL und Aurora MySQL: Verwendung einer AWS-verwalteten MySQL-kompatiblen Datenbank als Quelle für AWS DMS.
Amazon RDS für SQL Server: Einrichten der laufenden Replikation auf einer SQL-Server-DB-Instance in der Cloud.
Amazon RDS für PostgreSQL und Aurora PostgreSQL: PostgreSQL behält automatisch das erforderliche WAL bei.
Es gibt zwei Arten von fortlaufenden Replikationsaufgaben:
-
Vollständiger Ladevorgang plus CDC – Die Aufgabe migriert vorhandene Daten und aktualisiert dann die Zieldatenbank basierend auf den Änderungen an der Quelldatenbank.
-
Nur CDC – Die Aufgabe migriert laufende Änderungen, nachdem Sie Daten in Ihrer Zieldatenbank vorliegen haben.
Durchführen der Replikation von einem CDC-Startpunkt aus
Sie können eine AWS DMS laufende Replikationsaufgabe (nur Erfassung von Änderungsdaten) von mehreren Punkten aus starten. Diese umfassen u. a. folgende:
-
Ab einer benutzerdefinierten CDC-Startzeit — Sie können das AWS Management Console oder verwenden, AWS CLI um einen Zeitstempel anzugeben AWS DMS , an dem die Replikation beginnen soll. AWS DMS startet dann ab dieser benutzerdefinierten CDC-Startzeit eine laufende Replikationsaufgabe. AWS DMS konvertiert den angegebenen Zeitstempel (in UTC) in einen systemeigenen Startpunkt, z. B. eine LSN für SQL Server oder eine SCN für Oracle. AWS DMS verwendet Engine-spezifische Methoden, um anhand des Change-Streams der Quell-Engine zu bestimmen, wo die Migrationsaufgabe gestartet werden soll.
Anmerkung
Nur wenn für das Verbindungsattribut
StartFromContext
der erforderliche Zeitstempel festgelegt wird, bietet Db2 als Quelle eine benutzerdefinierte CDC-Startzeit.PostgreSQL als Quelle unterstützt die benutzerdefinierte CDC-Startzeit nicht. Der Grund hierfür ist, dass die PostgreSQL-Datenbank-Engine keine Möglichkeit hat, einen Zeitstempel zu einem LSN oder SCN zuzuordnen, wie es Oracle und SQL Server tun.
-
Ab einem nativen CDC-Startpunkt – Sie können auch ab einem nativen Punkt im Transaktionsprotokoll der Quell-Engine starten. In einigen Fällen bevorzugen Sie möglicherweise diesen Ansatz, da ein Zeitstempel auf mehrere systemeigene Punkte im Transaktionslog hinweisen kann. AWS DMS unterstützt diese Funktion für die folgenden Quellendpunkte:
-
SQL Server
-
PostgreSQL
-
Oracle
-
MySQL
-
MariaDB
-
Wenn die Aufgabe erstellt wird, AWS DMS markiert sie den CDC-Startpunkt, und er kann nicht geändert werden. Erstellen Sie eine neue Aufgabe, wenn Sie einen anderen CDC-Startpunkt verwenden möchten.
Bestimmen eines nativen CDC-Startpunkts
Ein nativer CDC-Startpunkt ist ein Punkt im Datenbank-Engine-Protokoll, der einen Zeitpunkt festlegt, ab dem Sie mit der CDC beginnen können. Nehmen wir beispielsweise an, dass bereits ein Massendaten-Dump auf das Ziel angewendet wurde. Sie können den nativen Startpunkt für die fortlaufende reine Replikationsaufgabe suchen. Wählen Sie den Startpunkt für die reine Replikationsaufgabe sorgfältig aus, um Dateninkonsistenzen zu vermeiden. DMS erfasst Transaktionen, die nach dem ausgewählten CDC-Startpunkt gestartet wurden.
Nachstehend finden Sie Beispiele dafür, wie Sie den nativen CDC-Startpunkt über unterstützte Quell-Engines finden:
- SQL Server
-
Bei SQL Server besteht eine Log-Sequenznummer (LSN) aus drei Teilen:
-
Virtual Log File (VLF)-Sequenznummer
-
Anfangsversatz eines Protokollblocks
-
Slot-Nummer
Die LSN lautet z. B.:
00000014:00000061:0001
Mit der Funktion
fn_dblog()
oderfn_dump_dblog()
in SQL Server können Sie den Startpunkt einer SQL Server-Migrationsaufgabe basierend auf den Sicherungseinstellungen Ihres Transaktionsprotokolls anfordern.Um den nativen CDC-Startpunkt mit SQL Server zu verwenden, erstellen Sie eine Veröffentlichung in einer beliebigen Tabelle, die an der fortlaufenden Replikation teilnimmt. AWS DMS erstellt die Veröffentlichung automatisch, wenn Sie CDC ohne Verwendung eines nativen CDC-Startpunkts verwenden.
-
- PostgreSQL
-
Sie können einen CDC-Wiederherstellungsprüfpunkt für Ihre PostgreSQL-Quelldatenbank verwenden. Dieser Prüfpunktwert wird an verschiedenen Punkten generiert, während eine laufende Replikationsaufgabe für Ihre Quelldatenbank (die übergeordnete Aufgabe) ausgeführt wird. Weitere Informationen zu Prüfpunkten im Allgemeinen finden Sie unter Verwendung eines Kontrollpunkts als CDC-Startpunkt.
Um den Checkpoint zu identifizieren, der als Ihr systemeigener Startpunkt verwendet werden soll, verwenden Sie Ihre
pg_replication_slots
Datenbankansicht oder die Übersichtsdetails Ihrer übergeordneten Aufgabe aus der AWS Management ConsoleSo finden Sie die Übersichtsdetails für Ihre übergeordnete Aufgabe auf der Konsole
-
Melden Sie sich bei https://console.aws.amazon.com/dms/v2/
an AWS Management Console und öffnen Sie die AWS DMS Konsole. Wenn Sie als IAM-Benutzer angemeldet sind, müssen Sie über die entsprechenden Zugriffsberechtigungen für AWS DMS verfügen. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Erforderliche IAM-Berechtigungen zur Verwendung von AWS DMS.
-
Wählen Sie im Navigationsbereich die Option Database migration tasks (Datenbankmigrationsaufgaben) aus.
-
Wählen Sie Ihre übergeordnete Aufgabe aus der Liste auf der Seite Database migration tasks (Datenbankmigrationsaufgaben) aus. Dadurch wird die Seite der übergeordneten Aufgaben geöffnet, auf der die Übersichtsdetails angezeigt werden.
-
Suchen Sie unter Change Data Capture (CDC), Change Data Capture (CDC) start position (CDC-Startposition) und Change Data Capture (CDC) Recovery Checkpoint (CDC-Wiederherstellungsprüfpunkt) nach dem Prüfpunktwert.
Der Wert ähnelt dem folgenden:
checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0
Hier ist es die Komponente
4AF/B00000D0
, die Sie benötigen, um diesen nativen CDC-Startpunkt anzugeben. Setzen Sie beim Erstellen der CDC-Aufgabe den DMS-API-ParameterCdcStartPosition
auf diesen Wert, um die Replikation an diesem Startpunkt für Ihre PostgreSQL-Quelle zu beginnen. Informationen zur Verwendung der, um diese CDC-Aufgabe AWS CLI zu erstellen, finden Sie unter. CDC mit einer AWS-verwalteten PostgreSQL-DB-Instance aktivieren mit AWS DMS
-
- Oracle
-
Eine System Change Number (SCN) ist ein logischer, interner Zeitstempel, der von Oracle-Datenbanken verwendet wird. SCNs ordnet Ereignisse, die innerhalb der Datenbank auftreten. Dies ist erforderlich, um die ACID-Eigenschaften einer Transaktion zu erfüllen. Oracle-Datenbanken SCNs kennzeichnen den Speicherort, an dem alle Änderungen auf die Festplatte geschrieben wurden, sodass bei einer Wiederherstellungsaktion keine bereits geschriebenen Änderungen übernommen werden. Oracle verwendet auch SCNs , um den Punkt zu markieren, an dem für einen Datensatz keine Wiederherstellung mehr möglich ist, sodass die Wiederherstellung beendet werden kann.
Führen Sie den folgenden Befehl aus, um die aktuelle SCN in einer Oracle-Datenbank zu erhalten.
SELECT CURRENT_SCN FROM V$DATABASE
Wenn Sie die SCN oder den Zeitstempel verwenden, um eine CDC-Aufgabe zu starten, verpassen Sie die Ergebnisse aller offenen Transaktionen und können diese Ergebnisse nicht migrieren. Offene Transaktionen sind Transaktionen, die vor der Startposition der Aufgabe gestartet und nach der Startposition der Aufgabe festgeschrieben wurden. Sie können die SCN und den Zeitstempel identifizieren, um eine CDC-Aufgabe an einem Punkt zu starten, der alle offenen Transaktionen umfasst. Weitere Informationen finden Sie unter Transaktionen
in der Oracle-Dokumentation. AWS DMS Unterstützt ab Version 3.5.1 offene Transaktionen für eine reine CDC-Aufgabe mithilfe der openTransactionWindow
Endpunkteinstellung, wenn Sie SCN oder Timestamp verwenden, um die Aufgabe zu starten.Wenn Sie
openTransactionWindow
diese Einstellung verwenden, müssen Sie das Zeitfenster in Minuten angeben, in dem die offenen Transaktionen bearbeitet werden sollen. AWS DMS verschiebt die Erfassungsposition und findet die neue Position, an der die Datenerfassung gestartet werden soll. AWS DMS verwendet die neue Startposition für das Scannen aller offenen Transaktionen aus den erforderlichen Oracle-Redo- oder archivierten Redo-Logs. - MySQL
-
Vor der Veröffentlichung von MySQL Version 5.6.3 bestand die Log-Sequenznummer (LSN) für MySQL aus einer 4-Byte-Ganzzahl ohne Vorzeichen. In MySQL Version 5.6.3 wurde die LSN mit der Erhöhung des Redo-Log-Dateigrößenlimits von 4 GB auf 512 GB zu einer 8-Byte-Ganzzahl ohne Vorzeichen. Die Erhöhung berücksichtigt, dass weitere Byte zum Speichern zusätzlicher Größeninformationen erforderlich waren. Anwendungen, die auf MySQL 5.6.3 oder höher basieren und LSN-Werte nutzen, sollten zum Speichern und Vergleichen von LSN-Werten 64-Bit- anstelle von 32-Bit-Variablen verwenden. Weitere Informationen zu MySQL LSNs finden Sie in der MySQL-Dokumentation
. Führen Sie den folgenden Befehl aus, um die aktuelle LSN in einer MySQL-Datenbank zu erhalten.
mysql> show master status;
Die Abfrage gibt einen Binärprotokoll-Dateinamen, die Position und einige andere Werte zurück. Der native CDC-Startpunkt ist eine Kombination aus dem Namen der Binärprotokolldatei und der Position, z. B.
mysql-bin-changelog.000024:373
. In diesem Beispielmysql-bin-changelog.000024
ist dies der Name der Binlogs-Datei und373
die Position, an der mit der Erfassung von Änderungen begonnen AWS DMS werden muss.
Verwendung eines Kontrollpunkts als CDC-Startpunkt
Bei einer laufenden Replikationsaufgabe werden Änderungen migriert und AWS DMS von Zeit zu Zeit spezifische Checkpoint-Informationen AWS DMS zwischengespeichert. Der Prüfpunkt, den AWS DMS erstellt, enthält Informationen, sodass die Replikations-Engine den Wiederherstellungspunkt für den Änderungsstream kennt. Sie können den Prüfpunkt verwenden, um in der Zeitleiste der Änderungen zurückzugehen und eine fehlgeschlagene Migrationsaufgabe wiederherzustellen. Mit einem Prüfpunkt können Sie auch eine weitere laufende Replikationsaufgabe für ein anderes Ziel zu einem bestimmten Zeitpunkt starten.
Zum Abrufen der Prüfpunktinformationen gibt es drei Möglichkeiten:
-
Führen Sie die API-Operation
DescribeReplicationTasks
aus und sehen Sie sich die Ergebnisse an. Sie können die Informationen nach Aufgabe filtern und nach dem Prüfpunkt suchen. Sie können den letzten Kontrollpunkt abrufen, wenn sich die Aufgabe im angehaltenen oder fehlgeschlagenen Zustand befindet. Diese Informationen gehen verloren, wenn die Aufgabe gelöscht wird. -
Zeigen Sie die Metadatentabelle mit dem Namen
awsdms_txn_state
auf der Ziel-Instance an. Sie können die Tabelle abfragen, um Prüfpunktinformationen abzurufen. Zum Erstellen der Metadatentabelle legen Sie denTaskRecoveryTableEnabled
-Parameter aufYes
fest, wenn Sie eine Aufgabe erstellen. Diese Einstellung bewirkt AWS DMS , dass Checkpoint-Informationen kontinuierlich in die Ziel-Metadatentabelle geschrieben werden. Diese Informationen gehen verloren, wenn eine Aufgabe gelöscht wird.Das folgende Beispiel zeigt einen Prüfpunkt in der Metadaten-Tabelle:
checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121
-
Wählen Sie im Navigationsbereich Datenbankmigrationsaufgaben und anschließend Ihre übergeordnete Aufgabe aus der Liste aus, die auf der Seite „Datenbankmigrationsaufgaben“ angezeigt wird. Die Seite der übergeordneten Aufgabe wird mit Übersichtsdetails geöffnet. Suchen Sie unter Change Data Capture (CDC), Change Data Capture (CDC) start position (CDC-Startposition) und Change Data Capture (CDC) Recovery Checkpoint (CDC-Wiederherstellungsprüfpunkt) nach dem Prüfpunktwert. Der Prüfpunktwert ähnelt dem folgenden:
checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0
Anhalten einer Aufgabe an einem Commit- oder Server-Zeitpunkt
Mit der Einführung systemeigener CDC-Startpunkte AWS DMS kann eine Aufgabe auch an den folgenden Punkten gestoppt werden:
-
Commit-Zeitpunkt in der Quelle
-
Server-Zeitpunkt auf der Replikations-Instance
Sie können eine Aufgabe ändern und eine Uhrzeit zum Anhalten in koordinierter Weltzeit (UTC) wie erforderlich festlegen. Die Aufgabe wird basierend auf dem Commit- oder Server-Zeitpunkt, den Sie festgelegt haben, automatisch gestoppt. Wenn Sie zum Zeitpunkt der Aufgabenerstellung wissen, wann die Migrationsaufgabe enden soll, können Sie im Rahmen der Erstellung auch den betreffenden Zeitpunkt zum Stoppen festlegen.
Anmerkung
Beim ersten Start einer neuen AWS DMS serverlosen Replikation kann es bis zu 40 Minuten dauern, bis alle Ressourcen initialisiert sind. Beachten Sie, dass die Option server_time
erst verfügbar ist, wenn die Ressourceninitialisierung abgeschlossen ist.
Durchführen der bidirektionalen Replikation
Sie können AWS DMS Aufgaben verwenden, um eine bidirektionale Replikation zwischen zwei Systemen durchzuführen. Bei der bidirektionalen Replikation replizieren Sie Daten aus derselben Tabelle (oder einem Satz von Tabellen) zwischen zwei Systemen in beide Richtungen.
Beispielsweise können Sie eine Tabelle MITARBEITER von Datenbank A nach Datenbank B kopieren und Änderungen an der Tabelle von Datenbank A nach Datenbank B replizieren. Sie können auch Änderungen an der Tabelle MITARBEITER von Datenbank B zurück nach A replizieren. Sie führen also eine bidirektionale Replikation durch.
Anmerkung
AWS DMS Die bidirektionale Replikation ist nicht als vollständige Multimaster-Lösung einschließlich eines Primärknotens, Konfliktlösung usw. vorgesehen.
Verwenden Sie die bidirektionale Replikation für Situationen, in denen Daten auf verschiedenen Knoten operativ getrennt sind. Anders ausgedrückt: Angenommen, Sie lassen ein Datenelement von einer Anwendung ändern, die auf Knoten A ausgeführt wird, und Knoten A führt eine bidirektionale Replikation mit Knoten B durch. Dieses Datenelement auf Knoten A wird niemals von einer Anwendung geändert, die auf Knoten B ausgeführt wird.
AWS DMS unterstützt die bidirektionale Replikation auf diesen Datenbank-Engines:
-
Oracle
-
SQL Server
-
MySQL
-
PostgreSQL
-
Amazon Aurora MySQL-Compatible Edition
-
Aurora PostgreSQL-Compatible Edition
Erstellen von bidirektionalen Replikationsaufgaben
Um die AWS DMS bidirektionale Replikation zu aktivieren, konfigurieren Sie Quell- und Zielendpunkte für beide Datenbanken (A und B). Konfigurieren Sie z. B. einen Quell-Endpunkt für Datenbank A, einen Quell-Endpunkt für Datenbank B, einen Ziel-Endpunkt für Datenbank A und einen Ziel-Endpunkt für Datenbank B.
Erstellen Sie dann zwei Aufgaben: eine Aufgabe für Quelle A zum Verschieben von Daten nach Ziel B und eine weitere Aufgabe für Quelle B zum Verschieben von Daten nach Ziel A. Stellen Sie außerdem sicher, dass jede Aufgabe mit einer Loopback-Verhinderung konfiguriert ist. Auf diese Weise wird verhindert, dass identische Änderungen an den Zielen beider Aufgaben vorgenommen werden und somit die Daten für mindestens eine der beiden Aufgaben fehlerhaft werden. Weitere Informationen finden Sie unter Verhindern eines Loopbacks.
Die einfachste Methode ist, mit identischen Datensätzen sowohl in Datenbank A als auch in Datenbank B zu beginnen. Erstellen Sie dann zwei Nur-CDC-Aufgaben, eine Aufgabe, um Daten von A nach B zu replizieren, und eine weitere Aufgabe, um Daten von B nach A zu replizieren.
Gehen Sie wie folgt vor AWS DMS , um einen neuen Datensatz (Datenbank) auf Knoten B von Knoten A aus zu instanziieren:
-
Verwenden Sie eine Aufgabe zum vollständigen Laden und eine CDC-Aufgabe, um Daten von Datenbank A nach B zu verschieben. Stellen Sie sicher, dass während dieser Zeit keine Anwendungen Daten in Datenbank B ändern.
-
Wenn das vollständige Laden abgeschlossen ist und bevor Anwendungen Daten in Datenbank B ändern dürfen, notieren Sie die Uhrzeit oder die CDC-Startposition von Datenbank B. Anweisungen finden Sie unter Durchführen der Replikation von einem CDC-Startpunkt aus.
-
Erstellen Sie eine Nur-CDC-Aufgabe, bei der die Daten von Datenbank B zurück nach A unter Verwendung dieser Startzeit oder CDC-Startposition verschoben werden.
Anmerkung
Nur eine Aufgabe in einem bidirektionalen Paar kann eine Aufgabe für vollständiges Laden und CDC sein.
Verhindern eines Loopbacks
Um zu verdeutlichen, dass Loopback verhindert wird, nehmen wir an, dass T1 in einer Aufgabe Änderungsprotokolle aus der Quelldatenbank A AWS DMS liest und die Änderungen auf die Zieldatenbank B anwendet.
Als Nächstes liest eine zweite Aufgabe, T2, Änderungsprotokolle aus der Quelldatenbank B und wendet diese wieder auf die Zieldatenbank A an. Bevor T2 dies tut, muss DMS sicherstellen, dass dieselben Änderungen, die von der Quelldatenbank A in der Zieldatenbank B vorgenommen wurden, nicht auch in der Quelldatenbank A vorgenommen werden. Anders ausgedrückt: DMS muss sicherstellen, dass diese Änderungen nicht auf die Zieldatenbank A zurückreflektiert (zurückgeschleift) werden. Andernfalls können die Daten in Datenbank A beschädigt werden.
Um ein Loopback (eine Schleifenschaltung) von Änderungen zu verhindern, fügen Sie die folgenden Aufgabeneinstellungen zu jeder bidirektionalen Replikationsaufgabe hinzu. Dadurch wird sichergestellt, dass eine Loopback-Datenbeschädigung nicht in beide Richtungen auftritt.
{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention":
Boolean
, "SourceSchema":String
, "TargetSchema":String
}, . . . }
Über die Aufgabeneinstellungen von LoopbackPreventionSettings
wird festgestellt, ob eine Transaktion neu ist oder ein Echo von der Aufgabe für die entgegengesetzte Replikation. Wenn das AWS DMS
eine Transaktion auf eine Zieldatenbank anwendet, aktualisiert es eine DMS-Tabelle (awsdms_loopback_prevention
) mit einem Hinweis auf die Änderung. Bevor jede Transaktion auf ein Ziel angewendet wird, ignoriert das DMS jede Transaktion, die einen Verweis auf diese awsdms_loopback_prevention
-Tabelle enthält. Daher wendet es die Änderung nicht an.
Nehmen Sie diese Aufgabeneinstellungen bei jeder Replikationsaufgabe in ein bidirektionales Paar auf. Diese Einstellungen aktivieren die Loopback-Verhinderung. Sie geben auch das Schema für jede Quell- und Zieldatenbank in der Aufgabe an, die die awsdms_loopback_prevention
-Tabelle für jeden Endpunkt enthält.
Damit jede Aufgabe ein solches Echo identifizieren und ausschalten kann, setzen Sie EnableLoopbackPrevention
auf true
. Um an der Quelle ein Schema anzugeben, das awsdms_loopback_prevention
enthält, setzen Sie SourceSchema
auf den Namen für dieses Schema in der Quelldatenbank. Um am Ziel ein Schema anzugeben, das dieselbe Tabelle enthält, setzen Sie TargetSchema
auf den Namen für dieses Schema in der Zieldatenbank.
Im folgenden Beispiel werden die SourceSchema
- und TargetSchema
-Einstellungen für eine Replikationsaufgabe T1 und ihre Aufgabe T2 für die entgegengesetzte Replikation mit entgegengesetzten Einstellungen angegeben.
Die Einstellungen für die Aufgabe T1 sind wie folgt.
{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "LOOP-DATA", "TargetSchema": "loop-data" }, . . . }
Die Einstellungen für die Aufgabe T2 für die entgegengesetzte Replikation sind wie folgt.
{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "loop-data", "TargetSchema": "LOOP-DATA" }, . . . }
Anmerkung
Wenn Sie die verwenden AWS CLI, verwenden Sie nur die modify-replication-task
Befehle create-replication-task
oder, um Ihre bidirektionalen LoopbackPreventionSettings
Replikationsaufgaben zu konfigurieren.
Einschränkungen der bidirektionalen Replikation
Die bidirektionale Replikation für AWS DMS hat die folgenden Einschränkungen:
-
Die Loopback-Prävention verfolgt nur DML-Anweisungen (Data Manipulation Language). AWS DMS unterstützt nicht die Verhinderung von Loopback in Data Definition Language (DDL). Konfigurieren Sie dazu eine der Aufgaben in einem bidirektionalen Paar, um DDL-Anweisungen herauszufiltern.
-
Aufgaben, bei denen die Loopback-Verhinderung verwendet wird, unterstützen nicht die Übergabe von Änderungen in Stapeln. Um eine Aufgabe mit Loopback-Verhinderung zu konfigurieren, stellen Sie sicher, dass
BatchApplyEnabled
auffalse
gesetzt ist. -
Die bidirektionale DMS-Replikation umfasst keine Konflikterkennung oder -lösung. Um Dateninkonsistenzen zu erkennen, verwenden Sie die Datenvalidierung für beide Aufgaben.