Relationale DB-Migration zu S3 Data Lake über AWS DMS, Teil I

Der AWS Database Migration Service ist ein Cloud-Service, der relationale Datenbanken, NoSQL-Datenbanken, Data Warehouses und alle anderen Arten von Datenspeichern effizient und sicher in die AWS-Cloud oder zwischen Cloud- und On-Premises-Setups migriert. DMS unterstützt mehrere Arten von Quell- und Zieldatenbanken wie Oracle, MS SQL Server, MySQL, Postgres SQL, Amazon Aurora, AWS RDS, Redshift und S3 usw.

Beobachtungen während der Datenmigration

Wir haben an der Gestaltung und Erstellung eines AWS S3 Data Lakes und eines Data Warehouses in AWS Redshift mit den Datenquellen von On-Premises für Oracle, MS SQL Server, MySQL, Postgres SQL und MongoDB für relationale Datenbanken gearbeitet. Wir haben AWS DMS für den initialen Voll-Load und den täglichen inkrementellen Datentransfer von diesen Quellen in AWS S3 verwendet.

Mit dieser Reihe von Beiträgen möchte ich die verschiedenen Herausforderungen erläutern, die während der tatsächlichen Datenmigration mit unterschiedlichen relationalen Datenbanken aufgetreten sind.

1. Änderungsdatum nicht ordnungsgemäß an der Quelle befüllt

AWS DMS wird für den Voll-Load und die Erfassung von Änderungsdaten aus Quelldatenbanken verwendet. AWS DMS erfasst geänderte Datensätze basierend auf den Transaktionsprotokollen, aber eine ordnungsgemäß aktualisierte Änderungsdatum-Spalte kann helfen, die Deduplicationslogik anzuwenden und den zuletzt geänderten Datensatz für eine bestimmte Zeile im Ziel in S3 zu extrahieren.

Falls modifizierte Daten für eine Tabelle nicht verfügbar sind oder nicht ordnungsgemäß aktualisiert werden, bietet AWS DMS die Option von Transformationsregeln, um eine neue Spalte hinzuzufügen, während Daten aus der Quelldatenbank extrahiert werden. Hier hilft der AR_H_CHANGE_SEQ Header dabei, eine neue Spalte mit einem Wert als eindeutiger inkrementierender Nummer aus der Quelldatenbank hinzuzufügen, die aus einem Zeitstempel und einer automatisch inkrementierenden Nummer besteht.

Das folgende Codebeispiel fügt eine neue Spalte als DMS_CHANGE_SEQ im Ziel hinzu, die eine eindeutige inkrementierende Nummer aus der Quelle enthält. Dies ist eine 35-stellige eindeutige Nummer mit den ersten 16 Ziffern für den Zeitstempel und den nächsten 19 Ziffern für die Datensatz-ID-Nummer, die durch die Datenbank inkrementiert wird. 

{

    "rule-type": "transformation",

    "rule-id": "2",

    "rule-name": "2",

    "rule-target": "column",

    "object-locator": {

        "schema-name": "%",

        "table-name": "%"

    },

    "rule-action": "add-column",

    "value": "DMS_CHANGE_SEQ",

    "expression": "$AR_H_CHANGE_SEQ",

    "data-type": {

        "type": "string",

        "length": 100

    }

}

2. Aktivieren von Ergänzendem Logging für Oracle als Quelle

Für Oracle als Quelldatenbank, um laufende Änderungen zu erfassen, benötigt AWS DMS minimal ergänzendes Logging, das auf der Quelldatenbank aktiviert sein muss. Dadurch werden zusätzliche Informationen und Spalten in den Redo-Logs enthalten sein, um die Änderungen an der Quelle zu identifizieren.

Ergänzendes Logging kann für Primärschlüssel, eindeutige Schlüssel, Spaltenmengen oder alle Spalten aktiviert werden. Ergänzendes Logging für alle Spalten erfasst alle Spalten für die Tabellen in der Quelldatenbank und hilft dabei, die vollständigen Datensätze in der Ziel-AWS S3-Ebene zu überschreiben.

Die ergänzende Protokollierung aller Spalten wird die Größe der Redo-Logs erhöhen, da alle Spalten der Tabelle in den Logs protokolliert werden. Es ist erforderlich, die Umgebung für Redo- und Archiv-Logs entsprechend zu konfigurieren, um zusätzliche Informationen zu berücksichtigen.

3. Netzwerkbandbreite zwischen Quell- und Ziel-Datenbanken

Der initiale vollständige Datenabgleich von On-Premise-Quellen für Oracle, MS SQL Server usw. funktionierte gut, ebenso wie die Erfassung von geänderten Daten, meistens. 

In der Regel gab es tagsüber eine moderate Anzahl von Transaktionen in einem gegebenen Monat, abgesehen von den End-of-Business-Day-Prozessen, täglichen Vorgängen nach Mitternacht und Monatsendaktivitäten. Wir haben festgestellt, dass DMS-Migrationstasks während dieser Zeit nicht synchron waren oder fehlschlugen.

Wir haben die Metriken der Quell-, Ziel- und Replikationsinstanz in den Logs überprüft und folgende Beobachtungen gemacht:

• CDCLatencySource – die Zeitspanne in Sekunden zwischen dem letzten erfassten Ereignis am Quellenendpunkt und dem aktuellen Systemzeitstempel der AWS DMS-Instanz.
• CDCIncomingchanges – die Gesamtanzahl von Änderungsereignissen zu einem bestimmten Zeitpunkt, die darauf warten, auf das Ziel angewendet zu werden. Dies erhöht sich von null auf Tausende während der Abgleichaktivitäten am frühen Morgen.
• CDCLatencySource – die Lücke, in Sekunden, zwischen dem letzten Ereignis, das vom Quellenendpunkt erfasst wurde, und dem aktuellen Systemzeitstempel der AWS DMS-Instanz. Diese steigt von null auf einige tausend bis zu 10-12K Sekunden während täglicher nächtlicher Abgleichaktivitäten an. Dieser Wert lag während Monatsendaktivitäten bei bis zu 40K. 

Bei weiterer Protokollanalyse und Überprüfung anderer Metriken stellten wir fest, dass:

AWS DMS-Metriken NetworkReceiveThroughput dienen dazu, den eingehenden Datenverkehr auf der DMS-Replikationsinstanz für Datenbank des Kunden und DMS-Datenverkehr zu verstehen. Diese Metriken helfen dabei, eventuelle netzwerkbezogene Probleme zwischen der Quelldatenbank und der DMS-Replikationsinstanz zu verstehen.

Es wurde festgestellt, dass die Netzwerkempfangsdatenrate bis zu 30 MB/s bzw. 250 Mb/s betrug, aufgrund der VPN-Verbindung zwischen der Quelle und AWS, die auch für andere Anwendungen genutzt wurde.

Die abschließende Schlussfolgerung zu diesem Problem ist, dass die Konnektivität zwischen Quell- und Ziel-Datenbanken für eine erfolgreiche Datenmigration entscheidend ist. Sie sollten sicherstellen, dass ausreichende Bandbreite zwischen lokal gehosteten oder anderen Cloud-Quelldatenbanken und der AWS-Umgebung eingerichtet ist, bevor die tatsächliche Datenmigration erfolgt.

1. Ein VPN-Tunnel wie AWS Site-to-Site VPN oder Oracle Cloud Infrastructure (OCI) Site-to-Site VPN (Oracle AWS) kann eine Datenrate von bis zu 1,25 GBit/s bereitstellen. Dies wäre ausreichend für die Migration kleiner Tabellen oder Tabellen mit geringem DML-Datenverkehr.
2. Für große Datenumzüge mit vielen Transaktionen pro Sekunde auf den Tabellen sollten Sie AWS Direct Connect in Betracht ziehen. Es bietet die Möglichkeit, eine dedizierte private Verbindung mit 1 Gbps, 10 Gbps usw. unterstützter Bandbreite zu erstellen.

Schlussfolgerung

Dies ist Teil I der mehrteiligen Serie für die Migration relationaler Datenbanken unter Verwendung von AWS DMS und den implementierten Lösungen für ihre Herausforderungen. Die meisten in dieser Serie erwähnten Herausforderungen können während des Datenbankmigrationsprozesses auftreten, und auf diese Lösungen kann zurückgegriffen werden.