Erstellen von Aufgaben für die laufende Replikation mit AWS DMS

Sie können eine AWS DMS-Aufgabe erstellen, die fortlaufenden Ä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 Prozess wird als fortlaufende Replikation oder Change Data Capture (CDC) bezeichnet. AWS DMS verwendet diesen Prozess beim Replizieren von laufenden Änderungen aus einem Quelldatenspeicher. 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. Mit einer Full-Load-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 fortlaufende Änderungen aus der Quelldatenbank zu lesen, verwendet AWS DMS zum Lesen von Änderungen aus den Transaktionsprotokollen der Quell-Engine jeweils für eine Engine spezifische API-Aktionen. Nachfolgend finden Sie einige Beispiele dafür, wie AWS DMS dabei vorgeht:

• Für Oracle nutzt AWS DMS entweder die Oracle LogMiner-API oder die binäre Leser-API (bfile-API), um fortlaufende Änderungen zu lesen. AWS DMS liest fortlaufende Änderungen aus den Online- oder Archiv-Redo-Protokollen basierend auf der Systemänderungsnummer (SCN).

• Für Microsoft SQL Server verwendet AWS DMS MS Replication oder MS-CDC, um Informationen in das SQL Server-Transaktionsprotokoll zu schreiben. Anschließend wird die Funktion fn_dblog() oder fn_dump_dblog() in SQL Server zum Lesen der Änderungen im Transaktionsprotokoll basierend auf der Log-Sequenznummer (LSN) verwendet.

• Für MySQL liest AWS DMS Änderungen aus den zeilenbasierten Binärprotokollen und migriert diese Änderungen in die Zieldatenbank.

• Für PostgreSQL richtet AWS DMS logische Replikations-Slots ein und verwendet das test_decoding-Plugin, um Änderungen aus der Quelldatenbank zu lesen und in die Zieldatenbank 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 fortlaufende AWS DMS-Replikationsaufgabe (reine Change Data Capture-Aufgabe) von mehreren Punkten aus starten. Diese umfassen u. a. folgende:

• Ab einer benutzerdefinierten CDC-Startzeit – Sie können AWS DMS über die AWS Management Console oder die AWS CLI einen Zeitstempel für den Zeitpunkt angeben, an dem die Replikation beginnen soll. AWS DMS startet dann eine fortlaufende Replikationsaufgabe ab dieser benutzerdefinierten CDC-Startzeit. AWS DMS wandelt den angegebenen Zeitstempel (in UTC) in einen nativen Startpunkt um, wie z. B. eine LSN für SQL Server oder eine SCN für Oracle. AWS DMS verwendet Engine-spezifische Methoden, um zu ermitteln, wo genau die Migrationsaufgabe basierend auf dem Änderungs-Stream der Quell-Engine 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 manchen Fällen kann dieser Ansatz besser geeignet sein, da ein Zeitstempel mehrere native Punkte im Transaktionsprotokoll angeben kann. AWS DMS unterstützt diese Funktion für die folgenden Quellendpunkte:

  • SQL Server

  • PostgreSQL

  • Oracle

  • MySQL

  • MariaDB

Wenn die Aufgabe erstellt wird, markiert AWS DMS den CDC-Startpunkt und dieser 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() oder fn_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.

Zur Ermittlung des Prüfpunkts, der als Ihr nativer Startpunkt verwendet werden soll, verwenden Sie Ihre Datenbankansicht pg_replication_slots oder die Übersichtsdetails Ihrer übergeordneten Aufgabe aus der AWS Management Console.

So finden Sie die Übersichtsdetails für Ihre übergeordnete Aufgabe auf der Konsole

1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die AWS DMS-Konsole unter https://console.aws.amazon.com/dms/v2/.

   Wenn Sie als IAM-Benutzer angemeldet sind, müssen Sie über die entsprechenden Berechtigungen für den Zugriff auf AWS DMS verfügen. Weitere Informationen zu den erforderlichen Berechtigungen finden Sie unter Erforderliche IAM-Berechtigungen zur Verwendung von AWS DMS.

2. Wählen Sie im Navigationsbereich die Option Database migration tasks (Datenbankmigrationsaufgaben) aus.

3. 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.

4. 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-Parameter CdcStartPosition auf diesen Wert, um die Replikation an diesem Startpunkt für Ihre PostgreSQL-Quelle zu beginnen. Weitere Informationen zum Verwenden der AWS CLI zum Erstellen dieser CDC-Aufgabe finden Sie unter Aktivieren von CDC mit einer von AWS verwalteten PostgreSQL-DB-Instance mit AWS DMS.

Oracle

Eine Systemänderungsnummer (SCN) ist ein logischer, interner Zeitstempel von Oracle-Datenbanken. SCNs dienen zur Anordnung von Ereignissen, die innerhalb der Datenbank auftreten. Dies ist erforderlich, um die ACID-Eigenschaften einer Transaktion zu erfüllen. Oracle-Datenbanken verwenden SCNs, um den Speicherort zu markieren, an dem alle Änderungen auf die Festplatte geschrieben wurden, sodass eine Wiederherstellungsaktion keine bereits geschriebenen Änderungen übernimmt. Oracle verwendet SCNs zudem zur Markierung des Punkts, an dem für einen Satz von Daten kein Redo vorhanden ist, sodass die Wiederherstellung enden 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. Ab Version 3.5.1 unterstützt AWS DMS offene Transaktionen für eine reine CDC-Aufgabe mithilfe der Endpunkteinstellung openTransactionWindow, wenn Sie die SCN oder den Zeitstempel zum Starten der Aufgabe verwenden.

Bei Verwendung der Einstellung openTransactionWindow müssen Sie das Zeitfenster in Minuten für die Bearbeitung offener Transaktionen angeben. AWS DMS verschiebt die Erfassungsposition und findet die neue Position, an der die Datenerfassung gestartet werden soll. AWS DMS verwendet die neue Startposition zum Scannen aller offenen Transaktionen aus den erforderlichen Oracle-Redo- oder archivierten Redo-Protokollen.

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 Beispiel ist mysql-bin-changelog.000024 der Binärprotokoll-Dateiname und 373 die Position, an der AWS DMS die Erfassung der Änderungen beginnen muss.

Verwendung eines Kontrollpunkts als CDC-Startpunkt

Eine fortlaufende Replikationsaufgabe migriert Änderungen und AWS DMS legt von Zeit zu Zeit AWS DMS-spezifische Prüfpunktangaben im Zwischenspeicher ab. 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 den TaskRecoveryTableEnabled-Parameter auf Yes fest, wenn Sie eine Aufgabe erstellen. Mit dieser Einstellung schreibt AWS DMS kontinuierlich Kontrollpunktangaben in die Ziel-Metadaten-Tabelle. 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 nativer CDC-Startpunkte hat AWS DMS auch die Möglichkeit, eine Aufgabe zu den folgenden Zeitpunkten anzuhalten:

• 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-Serverless-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

Die bidirektionale AWS DMS-Replikation ist nicht als vollständige Multi-Master-Lösung mit einem Primärknoten, Konfliktlösung usw. gedacht.

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 eine bidirektionale AWS DMS-Replikation zu ermöglichen, konfigurieren Sie Quell- und Ziel-Endpunkte 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.

Um AWS DMS zur Instanziierung eines neuen Datensatzes (Datenbank) auf Knoten B von Knoten A zu verwenden, gehen Sie wie folgt vor:

1. 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.

2. 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.

3. 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 das Verhindern eines Loopbacks anzuzeigen, nehmen wir an, dass AWS DMS in einer Aufgabe T1 Änderungsprotokolle aus der Quelldatenbank A 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 AWS CLI verwenden, verwenden Sie nur die Befehle create-replication-task oder modify-replication-task, um die LoopbackPreventionSettings in Ihren Aufgaben für die bidirektionale Replikation zu konfigurieren.

Einschränkungen der bidirektionalen Replikation

Die bidirektionale Replikation für AWS DMS weist folgende Einschränkungen auf:

• Die Loopback-Verhinderung verfolgt nur DML-Anweisungen (Data Manipulation Language). AWS DMS unterstützt die Verhinderung des DDL-Loopback (Data Definition Language) nicht. 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 auf false gesetzt ist.

• Die bidirektionale DMS-Replikation umfasst keine Konflikterkennung oder -lösung. Um Dateninkonsistenzen zu erkennen, verwenden Sie die Datenvalidierung für beide Aufgaben.