Welche bewährten Methoden sind bei der Migration einer RDS-MySQL-Quelldatenbank zu einer RDS-MySQL-Zieldatenbank mit AWS DMS zu beachten?

Kurzbeschreibung

Mit AWS DMS können Sie Daten von einem Quelldatenspeicher zu einem Zieldatenspeicher migrieren. Diese beiden Datenspeicher werden als Endpunkte bezeichnet. Sie können zwischen Quell- und Zielendpunkten migrieren, die dieselbe Datenbank-Engine verwenden, z. B. von einer MySQL-Datenbank zu einer anderen MySQL-Datenbank.

Obwohl AWS DMS die Zielschemaobjekte erstellt, werden nur die Mindesobjekte erstellt, die für eine effektive Migration der Daten aus der Quelle erforderlich sind. AWS DMS erstellt also Tabellen, Primärschlüssel und in einigen Fällen eindeutige Indizes, aber es werden keine Objekte wie Sekundärindizes, Einschränkungen für Nicht-Primärschlüssel und Datenstandardwerte erstellt. Weitere Informationen dazu, was AWS DMS migriert, finden Sie unter Allgemeine Ansicht von AWS DMS.

Erstellen Sie die Tabellen in der Zieldatenbank vor der Migration

Um die Standarddatendefinitionen beizubehalten, erstellen Sie die Tabellen in der Zieldatenbank vor der Migration. Verwenden Sie je nach Art der Migration, die Sie durchführen, einen der folgenden Ansätze:

• Verwenden Sie für homogene Migrationen wie MySQL zu MySQL die nativen Datenbank-Engine-Dienstprogramme wie mysqldump, um die Tabellendefinitionen zu exportieren. Importieren Sie dann diese Tabellendefinitionen ohne die Daten in das Ziel. Nachdem die Tabellendefinitionen erstellt wurden, verwenden Sie die AWS-DMS-Aufgabe mit dem Zieltabellenvorbereitungsmodus auf TRUNCATE_BEFORE_LOAD, um die Daten zu laden.
• Verwenden Sie für Migrationen zwischen verschiedenen Datenbank-Engines das AWS Schema Conversion Tool (AWS SCT). Sie können diese Methode auch für homogene Datenbanken verwenden. Der AWS SCT stellt eine Verbindung zu Ihren Quell- und Zieldatenbanken her und konvertiert dann das vorhandene Datenbankschema von einer Datenbank-Engine in eine andere. Sie können AWS SCT verwenden, um Tabellen in der Zieldatenbank mit intakten Standarddatendefinitionen vorab zu erstellen. Verwenden Sie dann die AWS-DMS-Aufgabe, wobei der Vorbereitungsmodus der Zieltabelle auf TRUNCATE_BEFORE_LOAD gesetzt ist, um die Daten zu laden. Weitere Informationen finden Sie unter Konvertieren von Schemas mit AWS SCT.

Auflösung

Befolgen Sie die bewährten Methoden für die Migration von MySQL zu MySQL AWS DMS

Verwenden Sie diese bewährte Methoden, wenn Sie Daten aus einer MySQL-Quelldatenbank in eine MySQL-Zieldatenbank migrieren.

• Deaktivieren Sie Backups und datenbankspezifische Protokolle (wie Bin, Allgemein und Audit) in der Zieldatenbank während der Migration. Bei Bedarf können Sie sie erneut aktivieren, um Probleme zu beheben.
• Deaktivieren Sie während der Migration Trigger, andere Cron-Jobs und Ereignisplaner in der Zieldatenbank.
• Vermeiden Sie die Verwendung von Multi-AZ in der Amazon-RDS-Zieldatenbank, wenn Sie die AWS-DMS-Migration durchführen.
• Vermeiden Sie es, bei der Migration anderen externen Clientdatenverkehr auf die Zieldatenbank anzuwenden.
• Stellen Sie Ihre AWS DMS-Replikationsinstance, Quell- und Zieldatenbanken mit der erforderlichen CPU, dem Arbeitsspeicher, dem erforderlichen Speicher und den IOPS bereit, um Ressourcenkonflikte während der Migration zu vermeiden.
• Konfigurieren Sie die Quelldatenbank mit den Voraussetzungen für die Verwendung von AWS DMS Change Data Capture (CDC), bevor Sie mit der Migration beginnen.
• Verwenden Sie optimierte LOB-Einstellungen wie begrenztes LOB und Inline-LOB für die Migration.
• Wenn die Quelldatenbank viele Tabellen mit hoher Workload enthält, teilen Sie die Tabellen auf mehrere Aufgaben auf. Teilen Sie die Tabellen basierend auf ihrer Größe in der Quelldatenbank, dem Muster des Anwendungsdatenverkehrs und dem Vorhandensein von LOB-Spalten auf. Wenn die Tabelle viele LOB-Spalten (TEXT oder JSON) mit hohem Schreibdatenverkehr auf der Quelle enthält, erstellen Sie eine separate Aufgabe für die Tabelle. Die Transaktionskonsistenz wird innerhalb einer Aufgabe gewahrt, daher ist es wichtig, dass Tabellen in separaten Aufgaben nicht an gemeinsamen Transaktionen beteiligt sind.
• Verwenden Sie den parallelen Mechanismus für vollständiges Laden für umfangreiche Quelltabellen, um die Migrationszeit zu reduzieren. Weitere Informationen finden Sie unter Verwenden des parallelen Ladens für ausgewählte Tabellen, Ansichten und Sammlungen.
• Deaktivieren Sie Fremdschlüsseleinschränkungen in der Zieltabelle während der Migration für vollständiges Laden.
• Fügen Sie der Zieldatenbank einen sekundären Index hinzu, bevor Sie die CDC-Phase der Replikation starten.
• Der primäre Amazon-RDS-Benutzer verfügt nicht über die Berechtigung zum Löschen und Wiedererstellen für die Standard-Schematabellen. Vermeiden Sie daher die Migration von Standarddatenbank- oder Schematabellen aus der Quelle mithilfe von AWS DMS.
• In der Dokumentation zum Migrieren von Daten von MySQL zu MySQL mit AWS DMS finden Sie Informationen dazu, welche Datentypen von AWS DMS erfolgreich migriert werden können.
• Testen Sie Ihren Workload mit der standardmäßigen transaktionalen CDC-Apply, bevor Sie die Batch-Apply-CDC-Methode verwenden. Weitere Informationen finden Sie unter Wie kann ich die DMS-Batch-Anwendungsfunktion verwenden, um die Leistung der CDC-Replikation zu verbessern?
• Testen Sie die Migration mit denselben Produktionsdaten in einer anderen QA/DEV-Datenbankumgebung, bevor Sie die Produktionsmigration starten. Stellen Sie sicher, dass Sie bei der Produktionsmigration dieselbe AWS-DMS-Konfiguration verwenden.

Weitere Informationen finden Sie unter Verbessern der Leistung einer AWS-DMS-Migration.

Verwenden Sie die empfohlenen Konfigurationen und Methoden für Ihre Quell- und Zieldatenbanken

1. Erstellen Sie die Tabellen-DDL für die MySQL/PostgreSQL-Zieldatenbanken manuell vorab. Erstellen Sie dann eine AWS DMS-Aufgabe mit dem Zielvorbereitungsmodus auf DO_DOTHING„ /“TRUNCATE, um nur die Daten zu migrieren.

Führen Sie diesen Befehl aus, um einen Dump ohne Daten aus der MySQL-Quelldatenbank zu erstellen:

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

Mit diesem Befehl wird die DDL-Struktur ohne Daten aus der Quelle ausgegeben.

Führen Sie anschließend diesen Befehl aus, um die DDL-Struktur auf dem Ziel wiederherzustellen:

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

Sie können AWS DMS auch erlauben, die Tabellen auf dem Ziel mithilfe des Zielvorbereitungsmodus DROP AND CREATE zu erstellen. Fahren Sie dann mit Schritt 3 fort, um die Tabelle zu ändern und fehlende Objekte wie sekundäre Indizes hinzuzufügen, bevor Sie die Aufgabe für die CDC-Phase fortsetzen.

Hinweis: Standardmäßig erstellt AWS DMS die Tabelle auf dem Ziel nur mit dem Primärschlüssel oder dem eindeutigen Schlüssel. Es migriert keine anderen Objekte in die MySQL-Zieldatenbank.

2. Während des vollständigen Ladevorgangs identifiziert AWS DMS die relationalen Fremdschlüsseltabellen nicht. Die Daten werden nach dem Zufallsprinzip geladen, sodass das Laden der Tabelle fehlschlagen kann, wenn in der Zieldatenbank eine Fremdschlüsselprüfung aktiviert ist. Verwenden Sie dieses zusätzliche Verbindungsattribut (ECA) auf dem MySQL-Zielendpunkt, um Fremdschlüsselprüfungen für diese AWS DMS-Sitzung zu deaktivieren.

initstmt=SET FOREIGN_KEY_CHECKS=0;

Weitere Informationen finden Sie unter Zusätzliche Verbindungsattribute bei Verwendung einer MySQL-kompatiblen Datenbank als Ziel für AWS DMS.

3. Legen Sie in den JSON-Einstellungen Stoptask vor dem Anwenden der zwischengespeicherten Änderungen auf true fest und beenden Sie die Aufgabe, nachdem die zwischengespeicherten Änderungen angewendet wurden, auf true.

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

Nachdem das vollständige Laden abgeschlossen ist und bevor zwischengespeicherte Änderungen angewendet werden, wird die Aufgabe beendet. Erstellen Sie während der Beendigung der Aufgabe Primärschlüsselindizes und Sekundärindizes auf dem Ziel.

Setzen Sie als Nächstes die Aufgabe fort, da die Aufgabe erneut angehalten wird, nachdem sie zwischengespeicherte Änderungen angewendet hat. Überprüfen Sie dann die migrierten Daten mithilfe der AWS-DMS-Validierungsausgabe oder der manuellen Überprüfung, bevor Sie die Aufgabe für die CDC-Replikationsphase erneut fortsetzen. Wenn Sie diesen Schritt ausführen, können Sie alle Probleme identifizieren und beheben, bevor Sie die CDC-Replikation fortsetzen.

4.    Passen Sie in den Einstellungen für vollständiges Laden der Aufgabe die Einstellung commitRate an, um die Datenextraktionsrate aus der Quelle zu beschleunigen. Der Standardwert ist 10000. Passen Sie diese Einstellung daher an, wenn Sie eine große Datenmenge aus der Quelltabelle migrieren.

CommitRate=50000

Hinweis: Wenn Sie commitRate auf einen höheren Wert ändern, kann dies die Leistung beeinträchtigen. Stellen Sie daher sicher, dass Sie die Replikationsinstance überwachen und über genügend Speicher verfügen.

5.    Fügen Sie diese ECA auf dem Zielendpunkt hinzu, um die maximale Größe (in KB) aller CSV-Datei anzugeben, die zum Übertragen von Daten an das Ziel-MySQL verwendet wird. Der Standardwert ist 32.768 KB (32 MB), und gültige Werte liegen zwischen 1–1.048.576 KB (bis zu 1,1 GB).

maxFileSize=250000;

Hinweis: Wenn Sie eine Zielinstance wie MySQL, Aurora oder MariaDB für vollständiges Laden verwenden, verwenden Sie diese Option, damit AWS DMS im Hintergrund eine CSV-Datei erstellen kann, um die Daten in die Zielinstanz zu laden. Verwenden Sie einen Wert zwischen 32 MB und 1 GB. Überlegen Sie aber auch, wie viel Ihre Zielinstance verarbeiten kann. Wenn Sie mehrere Aufgaben haben, die 1 GB CSV-Datei laden, kann dies zu einem Overhead für Ihre Zielinstance führen. Stellen Sie sicher, dass Sie eine Instance mit hoher Rechenleistung am Ziel haben.

6.    Verwenden Sie die eingeschränkten LOB- oder Inline-LOB-Einstellungen für eine bessere Leistung.

Eingeschränkter LOB-Modus: Wenn Sie den Modus „Eingeschränkter LOB“ verwenden, geben Sie die maximale Größe der LOB-Spaltendaten an. Auf diese Weise kann AWS DMS Ressourcen vorab zuweisen und dann LOB in großen Mengen anwenden. Wenn die Größe der LOB-Spalten die Größe überschreitet, die Sie in der Aufgabe angegeben haben, schneidet AWS DMS die Daten ab. AWS DMS sendet dann Warnungen an die AWS-DMS-Protokolldatei. Die Verwendung des Modus „Eingeschränkter LOB“ verbessert die Leistung. Bevor Sie die Aufgabe ausführen, müssen Sie jedoch die maximale LOB-Größe der Daten in der Quelle ermitteln. Geben Sie dann den Parameter Max. LOB-Größe an. Es ist eine bewährte Methode, sicherzustellen, dass der Replikationsinstance genügend Arbeitsspeicher zugewiesen ist, um die Aufgabe zu bewältigen.

Inline-LOB-Modus: Wenn Sie den Inline-LOB-Modus verwenden, können Sie LOBs migrieren, ohne Daten zu kürzen oder die Aufgabenleistung zu verlangsamen, indem Sie sowohl kleine als auch große LOBs replizieren. Geben Sie zunächst einen Wert für den Parameter InlineLobMaxSize an, der nur verfügbar ist, wenn der Modus Full LOB auf „true“ gesetzt ist. Die AWS-DMS-Aufgabe überträgt die kleinen LOBs inline, was effizienter ist. Anschließend migriert AWS DMS LOBs, die größer als die angegebene Größe sind, im vollständigen LOB-Modus, indem eine Suche aus der Quelltabelle durchgeführt wird. Beachten Sie jedoch, dass der Inline-LOB-Modus nur während der Phase für vollständiges Laden funktioniert.

Hinweis: Sie müssen InlineLobMaxSize festlegen, wenn Sie die Aufgabeneinstellungen für Ihre Aufgabe angeben.

Führen Sie diese Abfragen aus, um die LOB-Größe zu überprüfen, und füllen Sie dann die Max. LOB-Größe auf.

Listen Sie die Tabellen auf, die LOB-Spalten haben:

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

Überprüfen Sie die Größe der LOB-Spalte:

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

Überprüfen Sie die Größe der LOB-Spalten für alle Tabellen, und füllen Sie dann die maximale Größe in Max. LOB-Größe (K) auf.

Die Verwendung der Option Max. LOB-Größe (K) mit einem Wert größer als 63 KB wirkt sich auf die Leistung eines vollständigen Ladevorgangs aus, die für die Ausführung im eingeschränkten LOB-Modus konfiguriert ist. Während einem vollständigen Ladevorgang weist AWS DMS Speicher zu, indem der Wert für die maximale LOB-Größe (k) mit der Commit-Rate multipliziert wird. Dann wird das Produkt mit der Anzahl der LOB-Säulen multipliziert.

Wenn AWS DMS diesen Speicher nicht vorab zuweisen kann, verbraucht AWS-DMS-SWAP-Speicher. Dies wirkt sich auf die Leistung eines vollständigen Ladevorgangs aus. Wenn Sie also bei der Verwendung des eingeschränkten LOB-Modus Leistungsprobleme haben, verringern Sie die Commit-Rate, bis Sie ein akzeptables Leistungsniveau erreicht haben. Oder erwägen Sie, den Inline-LOB-Modus für unterstützte Endpunkte zu verwenden, nachdem Sie zuerst die LOB-Verteilung für die Tabelle überprüft haben.

Weitere Informationen finden Sie unter Festlegen der LOB-Unterstützung für Quelldatenbanken in einer AWS-DMS-Aufgabe.

---

Relevante Informationen

Migrieren Sie mit AWS DMS von MySQL zu Amazon RDS

Schrittweise Komplettlösungen für die Datenbankmigration**