Welche bewährten Methoden sollten bei der Migration von PostgreSQL-Datenbanken zu einer RDS-Zieldatenbank für PostgreSQL mit AWS DMS verwendet werden?

Kurzbeschreibung

Wenn Sie homogene Datenbanken mit AWS DMS migrieren, kopieren Sie die Ausgangsdaten mit den nativen Tools Ihrer Engine, wie pg_dump. Führen Sie dann pg_restore auf dem Ziel aus. Sie können auch die logische Replikation und den Befehl COPY verwenden. Weitere Informationen finden Sie unter Bewährte Methoden für die Migration von PostgreSQL-Datenbanken in Amazon RDS und Amazon Aurora.

Um von einer RDS for PostgreSQL-Datenbank zu einer anderen RDS for PostgreSQL-Datenbank zu migrieren, erstellen Sie einen Snapshot, und stellen Sie den Snapshot dann als Ziel wieder her. Weitere Informationen finden Sie unter Migrieren eines Snapshots einer RDS for PostgreSQL-DB-Instance zu einem Aurora PostgreSQL DB-Cluster.

Beachten Sie, dass die Migration all Ihrer Daten aus einer Quelldatenbank zu einer Zieldatenbank mithilfe von AWS-DMS-Volllast sehr lange dauern kann. Es kann zu Verzögerungen kommen, die auf folgende Faktoren zurückzuführen sind:

• Bandwidth
• Quellkapazität zum Push großer Datenmengen
• Kapazität der Replikations-Engine zum Speichern, Verarbeiten und Weiterleiten von Massenlasten
• Zielkapazität zur Nutzung von Daten aus der Quelle

Im Vergleich dazu enthält die Änderungsreplikation nur Änderungen von der Quelle zum Ziel, sodass Workloads wie diese sehr gering sein können.

Aktuelle Log-Sequenznummer (LSN) erstellen und ermitteln

Bevor Sie ein Backup erstellen, müssen Sie einen Marker erhalten, der Ihre AWS-DMS-Aufgabe anweist, von wo aus Sie mit der Migration von Änderungen beginnen sollen.

Führen Sie diese Abfragen in der PostgreSQL-Quelldatenbank aus, um das aktuelle LSN zu erstellen und zu ermitteln.

Erstellen Sie den Replikationssteckplatz:

SELECT * FROM
pg_create_logical_replication_slot('replication_slot_name','tset_decoding')

Holen Sie sich das aktuelle LSN:

SELECT restart_LSN  FROM pg_replication_slots WHERE slot_name = 'replication_slot_name';

Der Befehl Restart_LSN teilt der AWS DMS-Aufgabe mit, wo die Migration von Änderungen von der Quelle zum Ziel beginnen soll.

Auflösung

Verwenden Sie diese bewährten Methoden für die Migration von Daten von PostgreSQL zu PostgreSQL mithilfe von AWS-DMS-Aufgaben.

Verwenden Sie bei Volllast keine Fremdschlüssel und Trigger

Wenn Volllast ausgeführt wird, stellen Sie sicher, dass Fremdschlüssel und Trigger nicht für die Migration enthalten sind. AWS DMS migriert Tabellen in alphabetischer Reihenfolge, weiß aber nicht, welche Tabellen übergeordnete Tabellen und welche untergeordnete Tabellen sind. Daher könnte AWS DMS zunächst versuchen, untergeordnete Tabellen zu migrieren. AWS DMS verhindert dann die Migration der Tabellen aufgrund einer Fremdschlüsselverletzung. Unterdrücken Sie also entweder Fremdschlüssel oder schließen Sie sie während der Migration nicht auf dem Ziel ein.

Trigger dürfen während der Migration niemals auf einem Ziel vorhanden sein, da sie mehrere Prozesse ausführen, die Daten auf dem Ziel beschädigen könnten. Fügen Sie bei Cut-Over alle Trigger hinzu.

Aktivieren Sie den vollständigen LOB-Modus bei der Migration von JSON-Daten

Wenn Sie LOB in Form von JSON migrieren, aktivieren Sie den vollständigen LOB-Modus, damit das JSON-Format nicht abgeschnitten wird. Wenn Sie den Modus „Eingeschränkter LOB“ verwenden, kann es zu einer Datenkürzung kommen. Anschließend stellt AWS DMS sicher, dass die Tabelle fehlschlägt, weil die JSON im falschen Format vorliegt.

Stellen Sie sicher, dass das Primärschlüsselfeld kein TEXT-Datentyp ist

Stellen Sie sicher, dass das Primärschlüsselfeld nicht TEXT ist, insbesondere wenn der vollständige LOB-Modus aktiviert ist. Möglicherweise treten DUPLIKATE von NULLs auf, da AWS DMS den TEXT-Datentyp als LOB behandelt. Während der Volllast versucht AWS DMS, den Primärschlüssel auf NULL zu setzen, und meldet dann ein Duplikat, da es viele Textspalten mit demselben Wert gibt. Der Fehler wird niemals als „NULL nicht erlaubt für Primärschlüssel“ behandelt, sondern als Duplikate. Dieses Problem kann schwierig zu finden und zu lösen sein. Vergewissern Sie sich daher immer, dass Ihr Primärschlüsselfeld nicht TEXT ist, um das Problem zu vermeiden.

AWS DMS erlauben, Zieltabellen zu erstellen

Wenn Volllast stattfindet, erlauben Sie AWS DMS, Tabellen auf dem Ziel zu erstellen. Wenn AWS DMS Tabellen erstellt, werden auch die übereinstimmenden Felder ohne DEFAULT-Werte für die Spalten erstellt. Standardwerte für Spalten können zu unerwartetem Verhalten in AWS DMS führen. SERIELL lässt beispielsweise die AWS DMS-Migration fehlschlagen, weil dieses Feld automatisch einen Wert erstellen möchte. Werfen Sie einen Blick auf folgendes Beispiel:

CREATE TABLE COMPANY (
   ID SERIAL PRIMARY KEY,
   NAME TEXT      NOT NULL);

Wenn das Ziel wie in diesem Beispiel strukturiert ist, möchten PostgreSQL-Interna den Wert der ID-Spalte generieren. Die Quelle enthält aber auch einen Wert für INSERT, der ein Problem verursacht. Stellen Sie also sicher, dass DEFAULTS während der Migration nicht Teil des Ziels sind.

Definieren Sie Partitionen als Quelltabellen bei Zuordnungen von Aufgabentabellen

Stellen Sie beim Migrieren partitionierter Tabellen sicher, dass Sie Partitionen als Quelltabellen in Zuordnungen von Aufgabentabellen definieren, nicht als übergeordnete Tabellen. Dies liegt daran, dass WAL-Protokolle partitionierte Tabelleninformationen enthalten. Übergeordnete Tabellen dürfen nur während der Volllast verwendet werden. Verwenden Sie daher keine übergeordneten Tabellen für die CDC-Phase. Wenn Sie während der CDC übergeordnete Tabellen definieren, können doppelte Fehler auftreten, die sich auf die Migration auswirken.

Wenn Sie die Zieltabellen zuordnen, stellen Sie außerdem sicher, dass alle Partitionen dem übergeordneten Element neu zugeordnet sind. Dies bedeutet, dass das übergeordnete Element verwendet wird, um automatisch auf seine Partitionen zu verteilen.

Definieren Sie alle Facetten auf der Quelle, wenn Sie PGLOGICAL verwenden

Wenn Sie PGLOGICAL für die Migration verwenden, stellen Sie sicher, dass Sie alle Facetten definieren, die für die Quelle erforderlich sind. Wenn Sie einen Bereich überspringen, werden Sie ein unerwartetes Verhalten feststellen. Probleme, die dadurch auftreten, sind sehr schwer zu beheben. Überprüfen Sie daher, ob Sie diese Bereiche definiert haben, bevor Sie mit der Migration mit PGLOGICAL beginnen.

Definieren Sie für Amazon RDS die folgenden Elemente:

Parametergruppe:

shared_preload_libraries = pglocical

Datenbankebene:

create extension pglogical;

Definieren Sie für „Lokal“ die folgenden Elemente:

postgresql.conf:

shared_preload_libraries = pglogical

Datenbankebene:

create extension pglogical;

Stellen Sie sicher, dass alle PG-Plugins, die auf der Quelle definiert sind, auf dem Ziel definiert sind

Stellen Sie sicher, dass alle PG-Plugins, die Sie in der Quelle definieren, auch auf dem Ziel definiert sind. Dies trägt zur Kompatibilität und reibungslosen Verarbeitung der Daten bei.

Stellen Sie sicher, dass Aufgaben nicht im Status Stopp/Fehler bleiben

Wenn Aufgaben im Status Stopp oder Fehler lange dauern, füllt sich der Speicher im Replikationssteckplatz.

Manuell erstellte Replikationssteckplätze aus der Quelle löschen

Wenn Sie Replikationssteckplätze manuell erstellt haben, löschen Sie sie nach Abschluss der Migration aus der Quelle. Wenn die Replikationssteckplätze auf der Quelle verbleiben, häufen sie sich an Größe an und der Speicher füllt sich.

Migrieren Sie Tabellen mit einem Primärschlüssel/eindeutigen Index

Es ist eine bewährte Methode, sicherzustellen, dass die Tabellen, die Sie migrieren, einen Primärschlüssel/eindeutigen Index haben. Wenn eine Tabelle keinen Primärschlüssel hat, werden die Anweisungen UPDATE und DELETE möglicherweise nicht auf die Tabelle angewendet, da sie nicht in WAL-Protokollen angemeldet sind. Verwenden Sie für Tabellen ohne Primärschlüssel REPLICATE IDENTITY FULL. Beachten Sie jedoch, dass dadurch viele Informationen in den Protokollen generiert werden.

---

Relevante Informationen

Verwenden einer PostgreSQL-Datenbank als AWS-DMS-Quelle

Ziele für die Datenmigration