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

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.

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.

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.

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:

Es gibt zwei Arten von fortlaufenden Replikationsaufgaben:

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:

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:

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:

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:

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.

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.

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:

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:

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"
  },

. . .
}

Einschränkungen der bidirektionalen Replikation

Die bidirektionale Replikation für AWS DMS hat die folgenden Einschränkungen: