Verwenden einer PostgreSQL-Datenbank als AWS DMS-Quelle - AWS Database Migration Service
Arbeiten mit selbstverwalteten PostgreSQL-DatenbankenArbeiten mit von AWS verwalteten PostgreSQL-DatenbankenVerwenden der logischen Replikation zur Aktivierung von CDC während der MigrationVerwenden von nativen CDC-Startpunkten zum Einrichten einer CDC-LastMigrationen von PostgreSQL auf PostgreSQLEntfernen von Artefakten von einer PostgreSQL-QuelleErweiterte Konfigurationseinstellungen für PostgreSQL als QuelleVerwenden der MapBooleanAsBoolean PostgreSQL-EndpunkteinstellungEndpunkt- und ECA-EinstellungenEinschränkungen für PostgreSQL als QuelleQuelldatentypen für PostgreSQL

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.

Verwenden einer PostgreSQL-Datenbank als AWS DMS-Quelle

Sie können Daten von einer oder vielen PostgreSQL-Datenbanken mithilfe von AWS DMS migrieren. Mit einer PostgreSQL-Datenbank als Quelle können Sie Daten zu einer anderen PostgreSQL-Datenbank oder einer der anderen unterstützten Datenbanken migrieren.

Informationen zu den Versionen von PostgreSQL, die AWS DMS als Quelle unterstützt, finden Sie unter Quellen für AWS DMS.

AWS DMS unterstützt PostgreSQL für diese Datenbanktypen:

  • Lokale Datenbanken

  • Datenbanken auf einer Amazon-EC2-Instance

  • Datenbanken auf einer DB-Instance von Amazon RDS

  • Datenbanken auf einer DB-Instance basierend auf der Amazon-Aurora-PostgreSQL-kompatiblen Edition

  • Datenbanken auf einer DB-Instance basierend auf der Amazon-Aurora-PostgreSQL-kompatiblen Serverless-Edition

Anmerkung

DMS unterstützt Amazon Aurora PostgreSQL – Serverless V1 nur als Quelle für Volllastaufgaben. Sie können jedoch Amazon Aurora PostgreSQL – Serverless V2 als Quelle für Volllast-, Volllast-und-CDC- und reine CDC-Aufgaben verwenden.

PostgreSQL-Quellversion

Zu verwendende AWS DMS-Version

9.x, 10.x, 11.x, 12.x

Verwenden Sie eine beliebige verfügbare AWS DMS-Version.

13.x

Verwenden Sie AWS DMS Version 3.4.3 und höher.

14.x

Verwenden Sie AWS DMS Version 3.4.7 und höher.

15.x

Verwenden Sie AWS DMS Version 3.5.1 und höher.

Sie können Secure Sockets Layer (SSL) verwenden, um Verbindungen zwischen Ihrem PostgreSQL-Endpunkt und der Replikations-Instance zu verschlüsseln. Weitere Informationen zur Verwendung von SSL mit einem PostgreSQL-Endpunkt finden Sie unter Verwenden von SSL mit AWS Database Migration Service.

Eine zusätzliche Sicherheitsanforderung bei Verwendung von PostgreSQL als Quelle besteht darin, dass das angegebene Benutzerkonto ein registrierter Benutzer in der PostgreSQL-Datenbank sein muss.

Führen Sie die folgenden Schritte aus, um eine PostgreSQL-Datenbank als AWS DMS-Quellendpunkt zu konfigurieren:

Arbeiten mit selbstverwalteten PostgreSQL-Datenbanken als Quelle in AWS DMS

Mit einer selbstverwalteten PostgreSQL-Datenbank als Quelle können Sie Daten zu einer anderen PostgreSQL-Datenbank oder einer der anderen von AWS DMS unterstützten Datenbanken migrieren. Bei der Datenbankquelle kann es sich um eine On-Premises-Datenbank oder eine selbstverwaltete Engine handeln, die auf einer Amazon-EC2-Instance ausgeführt wird. Sie können eine DB-Instance sowohl für Volllast- als auch für CDC-Aufgaben verwenden.

Voraussetzungen für die Verwendung einer selbstverwalteten PostgreSQL-Datenbank als AWS DMS-Quelle

Führen Sie vor der Migration von Daten aus einer selbstverwalteten PostgreSQL-Quelldatenbank die folgenden Schritte aus:

  • Stellen Sie sicher, dass Sie eine PostgreSQL-Datenbank der Version 9.4.x oder höher verwenden.

  • Erteilen Sie für Volllast-und-CDC- oder reine CDC-Aufgaben Superuser-Berechtigungen für das Benutzerkonto, das für die PostgreSQL-Quelldatenbank angegeben ist. Das Benutzerkonto erfordert Superuser-Berechtigungen, um auf replikationsspezifische Funktionen in der Quelle zugreifen zu können. Für reine Volllastaufgaben erfordert das Benutzerkonto SELECT-Berechtigungen für Tabellen, um diese migrieren zu können.

  • Fügen Sie der pg_hba.conf-Konfigurationsdatei die IP-Adresse des AWS DMS-Replikationsservers hinzu, und aktivieren Sie Replikations- und Socketverbindungen. Ein Beispiel folgt.

    
            # Replication Instance
            host all all 12.3.4.56/00 md5
            # Allow replication connections from localhost, by a user with the
            # replication privilege.
            host replication dms 12.3.4.56/00 md5

    Die Konfigurationsdatei pg_hba.conf von PostgreSQL steuert die Clientauthentifizierung. (HBA steht für hostbasierte Authentifizierung) Die Datei wird üblicherweise im Datenverzeichnis des Datenbankclusters gespeichert.

  • Wenn Sie eine Datenbank als Quelle für die logische Replikation mit AWS DMS konfigurieren, informieren Sie sich unter Aktivieren von CDC mit einer selbstverwalteten PostgreSQL-Datenbank als AWS DMS-Quelle.

Anmerkung

Einige AWS DMS-Transaktionen sind für einige Zeit im Leerlauf, bevor die DMS-Engine sie erneut nutzt. Über den Parameter idle_in_transaction_session_timeout in PostgreSQL-Versionen 9.6 und höher können Sie für Transaktionen im Leerlauf ein Timeout und Fehlschlagen veranlassen. Beenden Sie Transaktionen im Leerlauf nicht, wenn Sie AWS DMS verwenden.

Aktivieren von CDC mit einer selbstverwalteten PostgreSQL-Datenbank als AWS DMS-Quelle

AWS DMS unterstützt die Erfassung von Datenänderungen (CDC) mithilfe logischer Replikation. Legen Sie die folgenden Parameter und Werte in der Konfigurationsdatei postgresql.conf fest, um die logische Replikation einer selbstverwalteten PostgreSQL-Quelldatenbank zu aktivieren:

  • Set wal_level = logical.

  • Legen Sie für max_replication_slots einen Wert größer als 1 fest.

    Legen Sie den Wert max_replication_slots gemäß der Anzahl der Aufgaben fest, die Sie ausführen möchten. Wenn Sie beispielsweise fünf Aufgaben ausführen möchten, legen Sie mindestens fünf Slots fest.. Slots werden automatisch geöffnet, sobald eine Aufgabe gestartet wird und bleiben geöffnet, selbst wenn die Aufgabe nicht mehr ausgeführt wird. Löschen Sie offene Slots unbedingt manuell. Beachten Sie, dass DMS beim Löschen der Aufgabe automatisch Replikations-Slots löscht, sofern DMS den Slot erstellt hat.

  • Legen Sie für max_wal_senders einen Wert größer als 1 fest.

    Der Parameter max_wal_senders legt die Anzahl der Aufgaben fest, die gleichzeitig ausgeführt werden können.

  • Der Parameter wal_sender_timeout beendet Replikationsverbindungen, die länger als die angegebene Anzahl von Millisekunden inaktiv sind. Der Standardwert für eine On-Premises-PostgreSQL-Datenbank beträgt 60 000 Millisekunden (60 Sekunden). Wenn Sie den Wert auf 0 (Null) festlegen, wird der Timeout-Mechanismus deaktiviert. Dies ist eine gültige Einstellung für DMS.

    Wenn Sie den Wert wal_sender_timeout auf einen anderen Wert als Null festlegen, benötigt eine DMS-Aufgabe mit CDC mindestens 10 000 Millisekunden (10 Sekunden) und schlägt fehl, wenn der Wert unter 10 000 liegt. Halten Sie den Wert unter 5 Minuten, um eine Verzögerung während eines Multi-AZ-Failovers einer DMS-Replikations-Instance zu vermeiden.

Einige Parameter sind statisch und können nur beim Serverstart festgelegt werden. Änderungen an ihren Einträgen in der Konfigurationsdatei (für eine selbstverwaltete Datenbank) oder der DB-Parametergruppe (für eine Datenbank von RDS für PostgreSQL) werden ignoriert, bis der Server neu gestartet wird. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation.

Weitere Informationen zum Aktivieren von CDC finden Sie unter Aktivieren der Erfassung von Datenänderungen (CDC) mithilfe logischer Replikation.

Arbeiten mit von AWS verwalteten PostgreSQL-Datenbanken als DMS-Quelle

Sie können eine von AWS verwaltete PostgreSQL-DB-Instance als Quelle für AWS DMS verwenden. Sie können sowohl Volllast- als auch CDC-Aufgaben mit einer von AWS verwalteten PostgreSQL-Quelle ausführen.

Voraussetzungen für die Verwendung einer von AWS verwalteten PostgreSQL-Datenbank als DMS-Quelle

Führen Sie vor der Migration von Daten aus einer von AWS verwalteten PostgreSQL-Quelldatenbank die folgenden Schritte aus:

  • Wir empfehlen, ein AWS-Benutzerkonto mit den erforderlichen Mindestberechtigungen für die PostgreSQL-DB-Instance als Benutzerkonto für den PostgreSQL-Quellendpunkt für AWS DMS zu verwenden. Von der Verwendung des Hauptkontos wird abgeraten. Das Konto muss über die Rolle rds_superuser und die Rolle rds_replication verfügen. Die Rolle rds_replication erteilt Berechtigungen zur Verwaltung von logischen Slots und zum Streamen von Daten mithilfe von logischen Slots.

    Erstellen Sie vom Hauptbenutzerkonto aus mehrere Objekte für das verwendete Konto. Informationen dazu, wie Sie diese erstellen, finden Sie unter Migrieren einer Datenbank von Amazon RDS für PostgreSQL ohne Verwendung des Hauptbenutzerkontos.

  • Wenn sich Ihre Quelldatenbank in einer Virtual Private Cloud (VPC) befindet, wählen Sie die VPC-Sicherheitsgruppe aus, die Zugriff auf die DB-Instance bietet, in der sich die Datenbank befindet. Dies ist erforderlich, damit die DMS-Replikations-Instance eine Verbindung mit der Quell-DB-Instance herstellen kann. Wenn sich die Datenbank und die DMS-Replikations-Instance in derselben VPC befinden, fügen Sie die entsprechende Sicherheitsgruppe ihren eigenen Regeln für eingehenden Datenverkehr hinzu.

Anmerkung

Einige AWS DMS-Transaktionen sind für einige Zeit im Leerlauf, bevor die DMS-Engine sie erneut nutzt. Über den Parameter idle_in_transaction_session_timeout in PostgreSQL-Versionen 9.6 und höher können Sie für Transaktionen im Leerlauf ein Timeout und Fehlschlagen veranlassen. Beenden Sie Transaktionen im Leerlauf nicht, wenn Sie AWS DMS verwenden.

Aktivieren von CDC mit einer von AWS verwalteten PostgreSQL-DB-Instance mit AWS DMS

AWS DMS unterstützt CDC für Amazon-RDS-PostgreSQL-Datenbanken, wenn die DB-Instance so konfiguriert ist, dass sie logische Replikation verwendet. Die folgende Tabelle enthält eine Zusammenfassung der Kompatibilität der einzelnen von AWS verwalteten PostgreSQL-Versionen mit logischer Replikation.

Sie können keine RDS-PostgreSQL-Lesereplikate für CDC (laufende Replikation) verwenden.

PostgreSQL-Version

Unterstützung für Volllastaufgaben mit AWS DMS

Unterstützung für CDC mit AWS DMS

Aurora PostgreSQL Version 2.1 mit Kompatibilität mit PostgreSQL 10.5 (oder niedriger)

Ja

Nein

Aurora PostgreSQL Version 2.2 mit Kompatibilität mit PostgreSQL 10.6 (oder höher)

Ja

Ja

RDS für PostgreSQL mit Kompatibilität mit PostgreSQL 10.21 (oder höher)

Ja

Ja
So aktivieren Sie die logische Replikation für eine RDS PostgreSQL DB-Instance

  1. Verwenden Sie das AWS-Hauptbenutzerkonto für die PostgreSQL-DB-Instance als Benutzerkonto für den PostgreSQL-Quellendpunkt. Das Masterbenutzerkonto hat die erforderlichen Rollen für die CDC-Einrichtung.

    Wenn Sie ein anderes als das Hauptbenutzerkonto verwenden, müssen Sie vom Hauptbenutzerkonto aus mehrere Objekte für das verwendete Konto erstellen. Weitere Informationen finden Sie unter Migrieren einer Datenbank von Amazon RDS für PostgreSQL ohne Verwendung des Hauptbenutzerkontos.

  2. Legen Sie den Parameter rds.logical_replication in der DB-CLUSTER-Parametergruppe auf 1 fest. Für das Wirksamwerden dieses statischen Parameters ist ein Neustart der DB-Instance erforderlich. Im Rahmen der Anwendung dieses Parameters legt AWS DMS die Parameter wal_level, max_wal_senders, max_replication_slots und max_connections fest. Diese Parameteränderungen können die WAL-Erzeugung (Write Ahead Log) erhöhen. Setzen Sie rds.logical_replication also nur, wenn Sie logische Replikationsslots verwenden.

  3. Der Parameter wal_sender_timeout beendet Replikationsverbindungen, die länger als die angegebene Anzahl von Millisekunden inaktiv sind. Der Standardwert für eine von AWS verwaltete PostgreSQL-Datenbank beträgt 30 000 Millisekunden (30 Sekunden). Wenn Sie den Wert auf 0 (Null) festlegen, wird der Timeout-Mechanismus deaktiviert. Dies ist eine gültige Einstellung für DMS.

    Wenn Sie den Wert wal_sender_timeout auf einen anderen Wert als Null festlegen, benötigt eine DMS-Aufgabe mit CDC mindestens 10 000 Millisekunden (10 Sekunden) und schlägt fehl, wenn der Wert zwischen 0 und 10 000 liegt. Halten Sie den Wert unter 5 Minuten, um eine Verzögerung während eines Multi-AZ-Failovers einer DMS-Replikations-Instance zu vermeiden.

  4. Stellen Sie sicher, dass der Wert des Parameters max_worker_processes in Ihrer DB-Cluster-Parametergruppe gleich oder höher als die kombinierten Gesamtwerte von max_logical_replication_workers, autovacuum_max_workers und max_parallel_workers ist. Eine hohe Anzahl von Hintergrund-Worker-Prozessen kann sich auf die Anwendungs-Workloads auf kleinen Instances auswirken. Überwachen Sie daher die Leistung Ihrer Datenbank, wenn Sie für max_worker_processes einen höheren Wert als den Standardwert festlegen.

Migrieren einer Datenbank von Amazon RDS für PostgreSQL ohne Verwendung des Hauptbenutzerkontos

In Einzelfällen können Sie das Hauptbenutzerkonto für die DB-Instance von Amazon RDS PostgreSQL, die Sie als Quelle verwenden, nicht verwenden. In diesen Fällen erstellen Sie mehrere Objekte, um Data Definition Language (DDL)-Ereignisse zu erfassen. Sie erstellen diese Objekte in dem Konto, das nicht das Masterkonto ist, und dann erstellen Sie einen Auslöser im Masterbenutzerkonto.

Anmerkung

Wenn Sie die Endpunkteinstellung captureDDLs am Quellendpunkt auf false festlegen, müssen Sie folgende Tabelle/folgenden Auslöser in der Quelldatenbank nicht erstellen.

Gehen Sie wie folgt vor, um diese Objekte zu erstellen.

So erstellen Sie Objekte

  1. Wählen Sie das Schema aus, in dem die Objekte erstellt werden sollen. Das Standardschema ist public. Stellen Sie sicher, dass das Schema vorhanden ist und dass das OtherThanMaster-Konto darauf zugreifen kann.

  2. Melden Sie sich mit dem anderen Benutzerkonto (nicht dem Hauptkonto) (hier das Konto OtherThanMaster) bei der PostgreSQL-DB-Instance an.

  3. Erstellen Sie die Tabelle awsdms_ddl_audit, indem Sie den folgenden Befehl ausführen. Ersetzen Sie dabei objects_schema im folgenden Code durch den Namen des zu verwendenden Schemas.

    
CREATE TABLE objects_schema.awsdms_ddl_audit
(
  c_key    bigserial primary key,
  c_time   timestamp,    -- Informational
  c_user   varchar(64),  -- Informational: current_user
  c_txn    varchar(16),  -- Informational: current transaction
  c_tag    varchar(24),  -- Either 'CREATE TABLE' or 'ALTER TABLE' or 'DROP TABLE'
  c_oid    integer,      -- For future use - TG_OBJECTID
  c_name   varchar(64),  -- For future use - TG_OBJECTNAME
  c_schema varchar(64),  -- For future use - TG_SCHEMANAME. For now - holds current_schema
  c_ddlqry  text         -- The DDL query associated with the current DDL event
);

  4. Erstellen Sie die Funktion awsdms_intercept_ddl, indem Sie den folgenden Befehl ausführen und dabei objects_schema im folgenden Code durch den Namen des zu verwendenden Schemas ersetzen.

    
CREATE OR REPLACE FUNCTION objects_schema.awsdms_intercept_ddl()
  RETURNS event_trigger
LANGUAGE plpgsql
SECURITY DEFINER
  AS $$
  declare _qry text;
BEGIN
  if (tg_tag='CREATE TABLE' or tg_tag='ALTER TABLE' or tg_tag='DROP TABLE' or tg_tag = 'CREATE TABLE AS') then
         SELECT current_query() into _qry;
         insert into objects_schema.awsdms_ddl_audit
         values
         (
         default,current_timestamp,current_user,cast(TXID_CURRENT()as varchar(16)),tg_tag,0,'',current_schema,_qry
         );
         delete from objects_schema.awsdms_ddl_audit;
end if;
END;
$$;

  5. Melden Sie sich vom OtherThanMaster-Konto ab und melden Sie sich mit einem Konto an, dem die rds_superuser-Rolle zugewiesen ist.

  6. Erstellen Sie den Ereignisauslöser awsdms_intercept_ddl, indem Sie den folgenden Befehl ausführen.

    
CREATE EVENT TRIGGER awsdms_intercept_ddl ON ddl_command_end 
EXECUTE PROCEDURE objects_schema.awsdms_intercept_ddl();

  7. Stellen Sie sicher, dass alle Benutzer und Rollen, die auf diese Ereignisse zugreifen, über die erforderlichen DDL-Berechtigungen verfügen. Beispielsweise:

    grant all on public.awsdms_ddl_audit to public;
grant all on public.awsdms_ddl_audit_c_key_seq to public;

Wenn Sie das vorangegangene Verfahren ausgeführt haben, können Sie den AWS DMS-Quellendpunkt mithilfe des OtherThanMaster-Kontos erstellen.

Anmerkung

Diese Ereignisse werden durch die Anweisungen CREATE TABLE, ALTER TABLE und DROP TABLE ausgelöst.

Aktivieren der Erfassung von Datenänderungen (CDC) mithilfe logischer Replikation

Sie können das native PostgreSQL-Feature zur logischen Replikation verwenden, um CDC während einer Datenbankmigration für PostgreSQL-Quellen zu aktivieren. Sie können dieses Feature mit einer selbstverwalteten PostgreSQL- und einer DB-Instance von Amazon RDS für PostgreSQL verwenden. Dieser Ansatz reduziert Ausfallzeiten und stellt sicher, dass die Zieldatenbank mit der PostgreSQL-Quelldatenbank synchronisiert ist.

AWS DMS unterstützt CDC für PostgreSQL-Tabellen mit Primärschlüsseln. Wenn eine Tabelle keinen Primärschlüssel aufweist, enthalten die Write-Ahead (WAL)-Protokolle kein Vorher-Image der Datenbankzeile. In diesem Fall kann DMS die Tabelle nicht aktualisieren. Sie können dann zusätzliche Konfigurationseinstellungen verwenden und die Tabellenreplikatidentität als Problemumgehung verwenden. Bei diesem Ansatz können jedoch zusätzliche Protokolle generiert werden. Es wird empfohlen, die Tabellenreplikatidentität erst nach sorgfältigen Tests als Problemumgehung zu verwenden. Weitere Informationen finden Sie unter Zusätzliche Konfigurationseinstellungen bei Verwendung einer PostgreSQL-Datenbank als DMS-Quelle.

Anmerkung

REPLICA IDENTITY FULL wird mit einem Plug-in für logische Dekodierung unterstützt, aber nicht mit dem Plug-in pglogical. Weitere Informationen finden Sie in der Dokumentation zu pglogical.

AWS DMS verwendet bei Volllast-und-CDC- sowie reinen CDC-Aufgaben logische Replikations-Slots, um WAL-Protokolle für die Replikation beizubehalten, bis die Protokolle dekodiert werden. Beim Neustart (nicht bei der Fortsetzung) einer Volllast-und-CDC- oder einer reinen CDC-Aufgabe wird der Replikations-Slot neu erstellt.

Anmerkung

Für die logische Dekodierung verwendet DMS entweder das Plugin test_decoding oder pglogical. Wenn das Plug-in pglogical in einer PostgreSQL-Quelldatenbank verfügbar ist, erstellt DMS einen Replikations-Slot mithilfe von pglogical, andernfalls wird das Plug-in test_decoding verwendet. Weitere Informationen zum Plug-in test_decoding finden Sie in der Dokumentation zu PostgreSQL.

Wenn der Datenbankparameter max_slot_wal_keep_size auf einen anderen Wert als den Standardwert festgelegt ist und die restart_lsn eines Replikations-Slots um mehr als diese Größe hinter der aktuellen LSN zurückbleibt, schlägt die DMS-Aufgabe aufgrund des Entfernens der erforderlichen WAL-Dateien fehl.

Konfigurieren des Plug-ins pglogical

Das als PostgreSQL-Erweiterung implementierte Plug-in pglogical ist ein logisches Replikationssystem und Modell für die selektive Datenreplikation. In der folgenden Tabelle sind die PostgreSQL-Quelldatenbankversionen aufgeführt, die das Plug-in pglogical unterstützen.

PostgreSQL-Quelle

Unterstützung für pglogical

Selbstverwaltetes PostgreSQL 9.4 oder höher

Ja

Amazon RDS PostgreSQL 9.5 oder niedriger

Nein

Amazon RDS PostgreSQL 9.6 oder höher

Ja

Aurora PostgreSQL 1.x bis 2.5.x

Nein

Aurora PostgreSQL 2.6.x oder höher

Ja

Aurora PostgreSQL 3.3.x oder höher

Ja

Bevor Sie pglogical für die Verwendung mit AWS DMS konfigurieren, aktivieren Sie zunächst die logische Replikation für die Erfassung von Datenänderungen (CDC) in Ihrer PostgreSQL-Quelldatenbank.

Nachdem die logische Replikation in Ihrer PostgreSQL-Quelldatenbank aktiviert wurde, führen Sie die folgenden Schritte aus, um pglogical für die Verwendung mit DMS zu konfigurieren.

So verwenden Sie das Plug-in pglogical für die logische Replikation in einer PostgreSQL-Quelldatenbank mit AWS DMS

  1. Erstellen Sie eine pglogical-Erweiterung für Ihre PostgreSQL-Quelldatenbank:

    1. Legen Sie den richtigen Parameter fest:

      • Legen Sie für selbstverwaltete PostgreSQL-Datenbanken den Datenbankparameter shared_preload_libraries= 'pglogical' fest.

      • Legen Sie für PostgreSQL-Datenbanken in Amazon RDS und Datenbanken der Amazon-Aurora-PostgreSQL-kompatiblen Edition den Parameter shared_preload_libraries in derselben RDS-Parametergruppe auf pglogical fest.

    2. Starten Sie Ihre PostgreSQL-Quelldatenbank neu.

    3. Führen Sie in der PostgreSQL-Datenbank den Befehl create extension pglogical; aus.

  2. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob pglogical erfolgreich installiert wurde:

    select * FROM pg_catalog.pg_extension

Sie können jetzt eine AWS DMS-Aufgabe erstellen, die die Erfassung von Datenänderungen für Ihren PostgreSQL-Quelldatenbank-Endpunkt durchführt.

Anmerkung

Wenn Sie pglogical in Ihrer PostgreSQL-Quelldatenbank nicht aktivieren, verwendet AWS DMS standardmäßig das Plug-in test_decoding. Wenn pglogical für die logische Dekodierung aktiviert ist, verwendet AWS DMS standardmäßig pglogical. Sie können jedoch das zusätzliche Verbindungsattribut PluginName festlegen, um stattdessen das Plug-in test_decoding zu verwenden.

Verwenden von nativen CDC-Startpunkten zum Einrichten einer CDC-Last einer PostgreSQL-Quelle

Legen Sie zum Aktivieren von nativen CDC-Startpunkten mit PostgreSQL als Quelle das zusätzliche Verbindungsattribut slotName auf den Namen eines vorhandenen logischen Replikations-Slots fest, wenn Sie den Endpunkt erstellen. Dieser logische Replikations-Slot enthält laufende Änderungen ab dem Zeitpunkt der Erstellung des Endpunkts und unterstützt somit die Replikation ab einem früheren Zeitpunkt.

PostgreSQL schreibt die Datenbankänderungen in WAL-Dateien, die nur verworfen werden, nachdem ein AWS DMS erfolgreich Änderungen aus dem logischen Replikations-Slot gelesen hat. Durch die Verwendung von logischen Replikations-Slots können protokollierte Änderungen vor dem Löschen geschützt werden, bevor sie vom Replikationsmodul verwendet werden.

Je nach Änderungsrate und Verbrauch können Änderungen in einem logischen Replikations-Slot jedoch zu einer erhöhten Festplattennutzung führen. Es wird empfohlen, Speicherplatznutzungsalarme in der PostgreSQL-Quell-Instance festzulegen, wenn Sie logische Replikations-Slots verwenden. Weitere Informationen zur Einstellung des zusätzlichen Verbindungsattributs slotName finden Sie unter Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) bei Verwendung von PostgreSQL als DMS-Quelle.

Im folgenden Verfahren wird dieser Ansatz näher erläutert.

So verwenden Sie einen systemeigenen CDC-Startpunkt zum Einrichten einer CDC-Last eines PostgreSQL-Quellendpunkts:

  1. Identifizieren Sie den logischen Replikations-Slot, der von einer früheren Replikationsaufgabe (einer übergeordneten Aufgabe) verwendet wird, die Sie als Startpunkt verwenden möchten. Fragen Sie dann die pg_replication_slots-Ansicht der Quelldatenbank ab, um sicherzustellen, dass dieser Slot über keine aktiven Verbindungen verfügt. Wenn dies doch der Fall ist, lösen Sie sie auf und beenden Sie sie, bevor Sie fortfahren.

    Für die folgenden Schritte gehen Sie davon aus, dass Ihr logischer Replikations-Slot abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef ist.

  2. Erstellen Sie einen neuen Quellendpunkt, der die folgenden zusätzlichen Verbindungsattributeinstellungen enthält.

    slotName=abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef;

  3. Erstellen Sie eine neue reine CDC-Aufgabe mithilfe der Konsole, der AWS CLI oder der AWS DMS-API. Wenn Sie die CLI verwenden, können Sie beispielsweise den folgenden Befehl create-replication-task ausführen. 

    aws dms create-replication-task --replication-task-identifier postgresql-slot-name-test 
--source-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ABCD1EFGHIJK2LMNOPQRST3UV4 
--target-endpoint-arn arn:aws:dms:us-west-2:012345678901:endpoint:ZYX9WVUTSRQONM8LKJIHGF7ED6 
--replication-instance-arn arn:aws:dms:us-west-2:012345678901:rep:AAAAAAAAAAA5BB4CCC3DDDD2EE 
--migration-type cdc --table-mappings "file://mappings.json" --cdc-start-position "4AF/B00000D0" 
--replication-task-settings "file://task-pg.json"

    Im vorhergehenden Befehl werden die folgenden Optionen festgelegt:

    • Die Option source-endpoint-arn ist auf den neuen Wert festgelegt, den Sie in Schritt 2 erstellt haben.

    • Die Option replication-instance-arn ist auf den gleichen Wert wie für die übergeordnete Aufgabe aus Schritt 1 festgelegt.

    • Die Optionen table-mappings und replication-task-settings sind auf die gleichen Werte wie für die übergeordnete Aufgabe aus Schritt 1 festgelegt.

    • Die Option cdc-start-position ist auf einen Startpositionswert festgelegt. Um diese Startposition zu finden, fragen Sie entweder die pg_replication_slots-Ansicht Ihrer Quelldatenbank ab oder sehen Sie sich die Konsolendetails für die übergeordnete Aufgabe in Schritt 1 an. Weitere Informationen finden Sie unter Bestimmen eines nativen CDC-Startpunkts.

    Führen Sie die folgenden Schritte aus, um den benutzerdefinierten CDC-Startmodus zu aktivieren, wenn Sie eine neue reine CDC-Aufgabe mithilfe der AWS DMS-Konsole erstellen:

    • Wählen Sie im Abschnitt Aufgabeneinstellungen für CDC-Startmodus für Quelltransaktionen die Option Benutzerdefinierten CDC-Startmodus aktivieren aus.

    • Wählen Sie für Benutzerdefinierter CDC-Startpunkt für Quelltransaktionen die Option Protokollsequenznummer angeben aus. Geben Sie die Systemänderungsnummer an oder wählen Sie Wiederherstellungsprüfpunkt angeben aus und geben Sie einen Wiederherstellungsprüfpunkt an.

    Wenn diese CDC-Aufgabe ausgeführt wird und der angegebene logische Replikations-Slot nicht vorhanden ist, löst AWS DMS einen Fehler aus. Außerdem wird ein Fehler ausgelöst, wenn die Aufgabe nicht mit einer gültigen Einstellung für cdc-start-position erstellt wurde.

Wenn Sie native CDC-Startpunkte mit dem Plug-in pglogical verwenden und einen neuen Replikations-Slot verwenden möchten, führen Sie die folgenden Einrichtungsschritte durch, bevor Sie eine CDC-Aufgabe erstellen.

So verwenden Sie einen neuen Replikations-Slot, der nicht zuvor als Teil einer anderen DMS-Aufgabe erstellt wurde

  1. Erstellen Sie einen Replikations-Slot wie im Folgenden dargestellt:

    SELECT * FROM pg_create_logical_replication_slot('replication_slot_name', 'pglogical');

  2. Nachdem die Datenbank den Replikations-Slot erstellt hat, rufen Sie die Werte restart_lsn und confirmed_flush_lsn für den Slot ab und notieren Sie sich diese:

    select * from pg_replication_slots where slot_name like 'replication_slot_name';

    Beachten Sie, dass die native CDC-Startposition für eine CDC-Aufgabe, die nach dem Replikations-Slot erstellt wurde, nicht älter sein darf als der Wert confirmed_flush_lsn.

    Informationen zu den Werten restart_lsn und confirmed_flush_lsn finden Sie unter pg_replication_slots

  3. Erstellen Sie einen pglogical-Knoten.

    SELECT pglogical.create_node(node_name := 'node_name', dsn := 'your_dsn_name');

  4. Erstellen Sie mit der Funktion pglogical.create_replication_set zwei Replikationssätze. Der erste Replikationssatz verfolgt Aktualisierungen und Löschungen für Tabellen mit Primärschlüsseln nach. Der zweite Replikationssatz verfolgt nur Einfügungen nach und hat den gleichen Namen wie der erste Replikationssatz mit dem zusätzlichen Präfix „i“.

    SELECT pglogical.create_replication_set('replication_slot_name', false, true, true, false);
SELECT pglogical.create_replication_set('ireplication_slot_name', true, false, false, true);

  5. Fügen Sie dem Replikationssatz eine Tabelle hinzu.

    SELECT pglogical.replication_set_add_table('replication_slot_name', 'schemaname.tablename', true);
SELECT pglogical.replication_set_add_table('ireplication_slot_name', 'schemaname.tablename', true);

  6. Legen Sie das zusätzliche Verbindungsattribut (Extra Connection Attribute, ECA) wie folgt fest, wenn Sie Ihren Quellendpunkt erstellen.

    PluginName=PGLOGICAL;slotName=slot_name;

Sie können jetzt mithilfe des neuen Replikations-Slots eine reine CDC-Aufgabe mit einem nativen PostgreSQL-Startpunkt erstellen. Weitere Informationen zum Plug-in pglogical finden Sie in der Dokumentation zu pglogical 3.7.

Migrieren von PostgreSQL auf PostgreSQL mit AWS DMS

Wenn Sie von einer anderen Datenbank-Engine als PostgreSQL auf eine PostgreSQL-Datenbank migrieren, eignet sich AWS DMS fast immer als Migrationstool. Wenn Sie jedoch aus einer PostgreSQL-Datenbank auf eine PostgreSQL-Datenbank migrieren, können native PostgreSQL-Tools effektiver sein.

Verwenden nativer PostgreSQL-Tools zur Datenmigration

Unter den folgenden Bedingungen empfehlen wir die Verwendung von PostgreSQL-Datenbank-Migrationstools wie pg_dump:

  • Sie möchten eine homogene Migration durchführen, bei der die PostgreSQL-Ausgangsdatenbank auf eine PostgreSQL-Zieldatenbank migriert werden soll.

  • Sie möchten eine komplette Datenbank migrieren.

  • Die nativen Tools erlauben Ihnen, Ihre Daten mit einer minimalen Ausfallzeit zu migrieren.

Das Dienstprogramm pg_dump verwendet den Befehl COPY, um ein Schema sowie eine Daten-Dumpdatei einer PostgreSQL-Datenbank zu erstellen. Das durch pg_dump erzeugte Dump-Skript lädt Daten in eine Datenbank mit dem gleichen Namen und erstellt die Tabellen, Indizes und Fremdschlüssel neu. Verwenden Sie den Befehl pg_restore und den Parameter -d, um die Daten in einer Datenbank mit einem anderen Namen wiederherzustellen.

Wenn Sie Daten aus einer PostgreSQL-Quelldatenbank, die auf EC2 ausgeführt wird, auf ein Ziel in Amazon RDS für PostgreSQL migrieren, können Sie das Plug-in pglogical verwenden.

Weitere Informationen zum Importieren einer PostgreSQL-Datenbank in Amazon RDS für PostgreSQL oder die Amazon-Aurora-PostgreSQL-kompatible Edition finden Sie unter https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/PostgreSQL.Procedural.Importing.html.

Migration von Daten von PostgreSQL auf PostgreSQL mit DMS

AWS DMS kann Daten beispielsweise von einer On-Premises-PostgreSQL-Quelldatenbank auf eine Ziel-Instance in Amazon RDS für PostgreSQL oder Aurora PostgreSQL migirieren. Kern- oder grundlegende PostgreSQL-Datentypen werden meist erfolgreich migriert.

Anmerkung

Wenn Sie partitionierte Tabellen aus einer PostgreSQL-Quelle in ein PostgreSQL-Ziel replizieren, müssen Sie die übergeordnete Tabelle nicht als Teil der Auswahlkriterien in der DMS-Aufgabe angeben. Wenn Sie die übergeordnete Tabelle angeben, werden Daten in untergeordneten Tabellen auf dem Ziel dupliziert, was möglicherweise eine PK-Verletzung verursacht. Wenn in den Auswahlkriterien für die Tabellenzuordnung nur untergeordnete Tabellen ausgewählt werden, wird die übergeordnete Tabelle automatisch aufgefüllt.

Datentypen, die zwar in der Quelldatenbank, nicht aber in der Zieldatenbank unterstützt werden, werden möglicherweise nicht erfolgreich migriert. AWS DMS streamt einige Datentypen als Zeichenfolgen, wenn der Datentyp unbekannt ist. Bei einigen Datentypen, wie z. B. XML und JSON, können kleine Dateien erfolgreich migriert werden, bei großen Dokumenten schlägt die Migration jedoch fehl.

Beachten Sie bei der Datentypmigration Folgendes:

  • In Einzelfällen gibt der PostgreSQL-Datentyp NUMERIC(p,s) keine Präzision und Skalierung an. Für DMS-Versionen 3.4.2 und früher verwendet DMS standardmäßig eine Präzision von 28 und eine Skalierung von 6, NUMERIC(28,6). Beispielsweise wird der Wert 0,611111104488373 von der Quelle in 0,611111 auf dem PostgreSQL-Ziel konvertiert.

  • Eine Tabelle mit einem ARRAY-Datentyp muss über einen Primärschlüssel verfügen. Eine Tabelle mit einem ARRAY-Datentyp ohne Primärschlüssel wird während Volllastvorgängen angehalten.

Die folgende Tabelle enthält PostgreSQL-Quelldatentypen sowie Erläuterungen dazu, ob diese erfolgreich migriert werden können:

Datentyp Wird erfolgreich migriert Wird teilweise migriert Wird nicht migriert Kommentare
INTEGER X
SMALLINT X
BIGINT X
NUMERIC/DECIMAL(p,s) X Wobei 0 < p < 39 und 0 < s
NUMERIC/DECIMAL X Wobei p > 38 oder p=s=0
REAL X
DOUBLE X
SMALLSERIAL X
SERIAL X
BIGSERIAL X
MONEY X
CHAR X Ohne angegebene Genauigkeit
CHAR(n) X
VARCHAR X Ohne angegebene Genauigkeit
VARCHAR (n) X
TEXT X
BYTEA X
TIMESTAMP (ZEITSTEMPEL) X Positive und negative Unendlichkeitswerte werden auf „9999-12-31 23:59:59“ bzw. „4713-01-01 00:00:00 BC“ gekürzt.
TIMESTAMP WITH TIME ZONE X
DATUM X
TIME X
TIME WITH TIME ZONE X
INTERVAL X
BOOLEAN X
ENUM X
CIDR X
INET X
MACADDR X
TSVECTOR X
TSQUERY X
XML X
POINT X PostGIS Spatial Data-Typ
LINE X
LSEG X
BOX X
PATH X
POLYGON X PostGIS Spatial Data-Typ
CIRCLE X
JSON X
ARRAY X Primärschlüssel erforderlich
COMPOSITE X
RANGE X
LINESTRING X PostGIS Spatial Data-Typ
MULTIPOINT X PostGIS Spatial Data-Typ
MULTILINESTRING X PostGIS Spatial Data-Typ
MULTIPOLYGON X PostGIS Spatial Data-Typ
GEOMETRYCOLLECTION X PostGIS Spatial Data-Typ

Migrieren räumlicher PostGIS-Datentypen

Räumliche Daten identifizieren die Geometrieinformationen eines Objekts oder einer Position im Raum. Objektrelationale PostgreSQL-Datenbanken unterstützen räumliche PostGIS-Datentypen.

Stellen Sie vor der Migration räumlicher PostgreSQL-Datenobjekte sicher, dass das Plug-in PostGIS auf globaler Ebene aktiviert ist. Dadurch wird sichergestellt, dass AWS DMS die genauen Quellspalten der räumlichen Daten für die PostgreSQL-Ziel-DB-Instance erstellt.

Bei homogenen Migrationen von PostgreSQL zu PostgreSQL unterstützt AWS DMS die Migration von geometrischen und geographischen (geodätischen Koordinaten) PostGIS-Datenobjekttypen und -subtypen wie den folgenden:

  • POINT

  • LINESTRING

  • POLYGON

  • MULTIPOINT

  • MULTILINESTRING

  • MULTIPOLYGON

  • GEOMETRYCOLLECTION

Entfernen von AWS DMS-Artefakten aus einer PostgreSQL-Quelldatenbank

Um DDL-Ereignisse zu erfassen, erstellt AWS DMS in der PostgreSQL-Datenbank verschiedene Artefakte, wenn eine Migrationsaufgabe gestartet wird. Wenn die Aufgabe abgeschlossen ist, können Sie diese Artefakte entfernen.

Entfernen Sie die Artefakte, indem Sie die folgenden Anweisungen ausgeben (in der Reihenfolge, in der sie angezeigt werden), wobei {AmazonRDSMigration} das Schema ist, in dem die Artefakte erstellt wurden. Ein Schema sollte nur mit äußerster Vorsicht gelöscht werden. Löschen Sie nie ein Schema, das in Betrieb ist, besonders kein öffentliches.

drop event trigger awsdms_intercept_ddl;

Der Ereignisauslöser gehört nicht zu einem bestimmten Schema.

drop function {AmazonRDSMigration}.awsdms_intercept_ddl()
drop table {AmazonRDSMigration}.awsdms_ddl_audit
drop schema {AmazonRDSMigration}

Zusätzliche Konfigurationseinstellungen bei Verwendung einer PostgreSQL-Datenbank als DMS-Quelle

Sie können zusätzliche Konfigurationseinstellungen für die Migration von Daten aus einer PostgreSQL-Datenbank auf zwei Weisen hinzufügen:

  • Sie können dem Attribut "Extra Connection" Werte hinzufügen, um DDL-Ereignisse zu erfassen und um das Schema anzugeben, in dem die betrieblichen DDL-Datenbankartefakte erstellt werden. Weitere Informationen finden Sie unter Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) bei Verwendung von PostgreSQL als DMS-Quelle.

  • Sie können Verbindungszeichenfolgenparameter außer Kraft setzen. Wählen Sie diese Option aus, um einen der folgenden Schritte auszuführen:

    • Interne AWS DMS-Parameter angeben. Solche Parameter sind selten erforderlich und werden daher nicht auf der Benutzeroberfläche angezeigt.

    • Geben Sie Pass-Through-Werte (passthru) für den spezifischen Datenbank-Client an. AWS DMS fügt Pass-Through-Parameter in die Verbindungszeichenfolge ein, die an den Datenbank-Client übergeben wird.

  • Mit dem Parameter REPLICA IDENTITY auf Tabellenebene in PostgreSQL-Versionen 9.4 und höher können Sie kontrollieren, welche Informationen in Write-Ahead-Protokollen (WALs) geschrieben werden. Dies gilt insbesondere für WALs, die Zeilen identifizieren, die aktualisiert oder gelöscht werden. REPLICA IDENTITY FULL zeichnet die alten Werte aller Spalten in der Zeile auf. Verwenden Sie REPLICA IDENTITY FULL sorgfältig für jede Tabelle, da FULL eine zusätzliche Anzahl an WAL generiert, die möglicherweise nicht erforderlich ist. Weitere Informationen finden Sie unter ALTER TABLE-REPLICA IDENTITY.

Verwenden der MapBooleanAsBoolean PostgreSQL-Endpunkteinstellung

Sie können PostgreSQL-Endpunkteinstellungen verwenden, um einen booleschen Wert aus Ihrer PostgreSQL-Quelle einem Amazon-Redshift-Ziel als booleschen Wert zuzuordnen. Standardmäßig wird ein BOOLEAN-Typ als varchar(5) migriert. Sie können MapBooleanAsBoolean angeben, damit PostgreSQL den booleschen Wert als booleschen Wert migriert, wie im folgenden Beispiel gezeigt.

--postgre-sql-settings '{"MapBooleanAsBoolean": true}'

Beachten Sie, dass Sie diese Einstellung sowohl am Quell- als auch am Zielendpunkt festlegen müssen, damit sie wirksam wird.

Da MySQL keinen BOOLEAN-Typ hat, sollten Sie bei der Migration von BOOLEAN-Daten nach MySQL eine Transformationsregel anstelle dieser Einstellung verwenden.

Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) bei Verwendung von PostgreSQL als DMS-Quelle

Sie können Endpunkteinstellungen und zusätzliche Verbindungsattribute (ECAs) verwenden, um Ihre PostgreSQL-Quelldatenbank zu konfigurieren. Sie geben Endpunkteinstellungen an, wenn Sie den Quellendpunkt mithilfe der AWS DMS Konsole oder mithilfe des Befehls create-endpoint in der AWS CLImit der --postgre-sql-settings '{"EndpointSetting": "value", ...}' JSON-Syntax erstellen.

Die folgende Tabelle zeigt die Endpunkteinstellungen und ECAs, die Sie mit PostgreSQL als Quelle verwenden können.

Attributname Beschreibung

CaptureDDLs

Um DDL-Ereignisse zu erfassen, erstellt AWS DMS in der PostgreSQL-Datenbank verschiedene Artefakte, wenn die Aufgabe gestartet wird. Sie können diese Artefakte zu einem späteren Zeitpunkt entfernen, wie im Abschnitt Entfernen von AWS DMS-Artefakten aus einer PostgreSQL-Quelldatenbank beschrieben.

Wenn dieser Wert auf false gesetzt wird, müssen Sie für die Quelldatenbank keine Tabellen oder Auslöser erstellen.

Gestreamte DDL-Ereignisse werden erfasst.

Standardwert: true

Zulässige Werte: true/false

Beispiel: --postgre-sql-settings '{"CaptureDDLs": true}'

ConsumeMonotonicEvents

Wird verwendet, um zu steuern, wie monolithische Transaktionen mit doppelten Protokollsequenznummern (Log Sequence Numbers, LSNs) repliziert werden. Wenn dieser Parameter auf false gesetzt ist, werden Ereignisse mit doppelten LSNs verarbeitet und auf dem Ziel repliziert. Wenn dieser Parameter auf true gesetzt ist, wird nur das erste Ereignis repliziert, während Ereignisse mit doppelten LSNs weder verarbeitet noch auf dem Ziel repliziert werden.

Standardwert: false

Zulässige Werte: false/true

Beispiel: --postgre-sql-settings '{"ConsumeMonotonicEvents": true}'

DdlArtifactsSchema

Legt das Schema fest, in dem die operativen DDL-Datenbankartefakte erstellt werden.

Standardwert: öffentlich

Zulässige Werte: String

Beispiel: --postgre-sql-settings '{"DdlArtifactsSchema": "xyzddlschema"}'

ExecuteTimeout

Stellt die Zeitbeschränkung der Client-Anweisung für die PostgreSQL-Instance in Sekunden ein. Der Standardwert liegt bei 60 Sekunden.

Beispiel: --postgre-sql-settings '{"ExecuteTimeout": 100}'

FailTasksOnLobTruncation

Mit der Einstellung true bewirkt dieser Wert, dass eine Aufgabe fehlschlägt, wenn die tatsächliche Größe einer LOB-Spalte größer als der angegebene LobMaxSize-Wert ist.

Wenn die Aufgabe auf den eingeschränkten LOB-Modus festgelegt ist und diese Option auf "true" festgelegt wurde, schlägt die Aufgabe fehl, anstatt LOB-Daten zu kürzen.

Standardwert: false

Zulässige Werte: Boolesch

Beispiel: --postgre-sql-settings '{"FailTasksOnLobTruncation": true}'

fetchCacheSize

Dieses zusätzliche Verbindungsattribut (ECA) legt die Anzahl der Zeilen fest, die der Cursor während des Volllastvorgangs abruft. Abhängig von den in der Replikations-Instance verfügbaren Ressourcen können Sie einen höheren oder niedrigeren Wert festlegen.

Standardwert: 10000

Zulässige Werte: Zahl

ECA-Beispiel: fetchCacheSize=10000;

HeartbeatFrequency

Stellt die WAL-Heartbeat-Frequenz ein (in Minuten).

Standardwert: 5

Zulässige Werte: Zahl

Beispiel: --postgre-sql-settings '{"HeartbeatFrequency": 1}'

HeartbeatSchema

Legt das Schema fest, in dem die Heartbeat-Artefakte erstellt werden.

Standardwert: public

Zulässige Werte: String

Beispiel: --postgre-sql-settings '{"HeartbeatSchema": "xyzheartbeatschema"}'

MapJsonbAsClob

Standardmäßig ordnet AWS DMS JSONB NCLOB zu. Sie können MapJsonbAsClob angeben, damit PostgreSQL den JSONB-Typ als CLOB migriert.

Beispiel: --postgre-sql-settings='{"MapJsonbAsClob": "true"}'

MapLongVarcharAs

Standardmäßig ordnet AWS DMS VARCHAR WSTRING zu. Sie können MapLongVarcharAs angeben, damit PostgreSQL den Typ VARCHAR(N) (wobei N größer als 16 387 ist) zu den folgenden Typen migriert:

  • WSTRING

  • CLOB

  • NCLOB

Beispiel: --postgre-sql-settings='{"MapLongVarcharAs": "CLOB"}'

MapUnboundedNumericAsString

Dieser Parameter behandelt Spalten mit unbegrenzten NUMERIC-Datentypen als STRING, um eine erfolgreiche Migration ohne Verlust der Präzision des numerischen Werts zu ermöglichen. Verwenden Sie diesen Parameter nur für die Replikation von einer PostgreSQL-Quelle zu einem PostgreSQL-Ziel oder für Datenbanken mit PostgreSQL-Kompatibilität.

Standardwert: false

Zulässige Werte: false/true

Beispiel: --postgre-sql-settings '{"MapUnboundedNumericAsString": true}'

Die Verwendung dieses Parameters kann zu einer gewissen Beeinträchtigung der Replikationsleistung führen, da eine Transformation von numerischen Werten in Zeichenfolgen und zurück in numerische Werte erfolgt. Dieser Parameter wird für DMS-Version 3.4.4 und höher unterstützt

Anmerkung

Verwenden Sie MapUnboundedNumericAsString nur in PostgreSQL-Quell- und -Zielendpunkten gemeinsam.

Bei Verwendung von MapUnboundedNumericAsString für PostgreSQL-Quellendpunkte wird die Präzision während CDC auf 28 beschränkt. Bei Verwendung von MapUnboundedNumericAsString für Zielendpunkte werden Daten mit einer Präzision von 28 und einer Skalierung von 6 migriert.

Verwenden Sie MapUnboundedNumericAsString nicht mit Nicht-PostgreSQL-Zielen.

PluginName

Gibt das Plugin an, das zum Erstellen eines Replikations-Slots verwendet werden soll.

Zulässige Werte: pglogical, test_decoding

Beispiel: --postgre-sql-settings '{"PluginName": "test_decoding"}'

SlotName

Legt den Namen eines zuvor erstellten logischen Replikations-Slots für eine CDC-Last der PostgreSQL-Quell-Instance fest.

Bei Verwendung mit dem AWS DMS-APICdcStartPosition-Anforderungsparameter ermöglicht dieses Attribut auch die Verwendung nativer CDC-Startpunkte. Das DMS überprüft, ob der angegebene logische Replikations-Slot vorhanden ist, bevor die Aufgabe für das CDC-Laden gestartet wird. Es wird auch überprüft, ob die Aufgabe mit einer gültigen Einstellung von CdcStartPosition erstellt wurde. Wenn der angegebene Slot nicht existiert oder die Aufgabe keine gültige CdcStartPosition-Einstellung besitzt, löst DMS einen Fehler aus.

Weitere Informationen zu den Einstellungen für den CdcStartPosition-Anforderungsparameter finden Sie unter Bestimmen eines nativen CDC-Startpunkts. Weitere Informationen über CdcStartPosition finden Sie in der Dokumentation zu den API-Operationen CreateReplicationTask, StartReplicationTask und ModifyReplicationTask in der API-Referenz zum AWS Database Migration Service.

Zulässige Werte: String

Beispiel: --postgre-sql-settings '{"SlotName": "abc1d2efghijk_34567890_z0yx98w7_6v54_32ut_1srq_1a2b34c5d67ef"}'

unboundedVarcharMaxSize

Dieses zusätzliche Verbindungsattribut (Extra Connection Attribute, ECA) definiert die maximale Größe einer Datenspalte, die als Typ VarChar ohne Angabe der maximalen Länge definiert ist. Der Standardwert ist 8 000 Byte. Der maximale Wert ist 10485760 Byte.

Einschränkungen bei Verwendung einer PostgreSQL-Datenbank als DMS-Quelle

Die folgenden Einschränkungen gelten bei der Verwendung von PostgreSQL als Quelle für AWS DMS:

  • AWS DMS funktioniert weder mit Amazon RDS für PostgreSQL 10.4 noch mit Amazon Aurora PostgreSQL 10.4 als Quelle oder Ziel.

  • Eine erfasste Tabelle muss über einen Primärschlüssel verfügen. Wenn eine Tabelle nicht über einen Primärschlüssel verfügt, ignoriert AWS DMS DELETE- und UPDATE-Vorgänge für Datensätze in dieser Tabelle. Informationen zur Problemumgehung finden Sie unter Aktivieren der Erfassung von Datenänderungen (CDC) mithilfe logischer Replikation.

    Hinweis: Wir raten von Migrationen ohne Primärschlüssel/eindeutigen Index ab. Andernfalls gelten zusätzliche Einschränkungen, z. B. KEINE Möglichkeit zur Stapelanwendung, vollständige LOB-Fähigkeit, Datenvalidierung und keine Möglichkeit, effizient auf das Redshift-Ziel zu replizieren.

  • AWS DMS ignoriert einen Versuch, ein Segment eines Primärschlüssels zu aktualisieren. In diesen Fällen identifiziert die Zieldatenbank die Aktualisierung als eine, die keine Zeilen aktualisiert hat. Da die Ergebnisse der Aktualisierung eines Primärschlüssels in PostgreSQL jedoch unvorhersehbar sind, werden keine Datensätze in die Ausnahmetabelle geschrieben.

  • AWS DMS unterstützt die Ausführungsoption Start Process Changes from Timestamp (Prozessänderungen von Zeitstempel starten) nicht.

  • AWS DMS repliziert keine Änderungen, die sich aus Partitions- oder Unterpartitionsoperationen (ADD, DROP oder TRUNCATE) ergeben.

  • Replikation mehrerer Tabellen mit demselben Namen, wobei sich jedoch jeder Name in Groß/Kleinschreibung unterscheidet (z. B. tabelle1, TABELLE1 und Tabelle1), kann unvorhersehbares Verhalten verursachen. Aufgrund dieses Problems unterstützt AWS DMS diese Art der Replikation nicht.

  • In den meisten Fällen unterstützt AWS DMS Änderungsverarbeitung von CREATE-, ALTER- und DROP DDL-Anweisungen für Tabellen. AWS DMS unterstützt diese Änderungsverarbeitung nicht, wenn die Tabellen in einer inneren Funktion oder einem Procedure-Body-Block oder in anderen verschachtelten Konstrukten gehalten werden.

    Die folgende Änderung wird beispielsweise nicht erfasst:

    CREATE OR REPLACE FUNCTION attu.create_distributors1() RETURNS void
LANGUAGE plpgsql
AS $$
BEGIN
create table attu.distributors1(did serial PRIMARY KEY,name
varchar(40) NOT NULL);
END;
$$;

  • Derzeit werden boolean-Datentypen in einer PostgreSQL-Quelle als bit-Datentyp mit inkonsistenten Werten zu einem SQL-Server-Ziel migriert. Erstellen Sie als Problemumgehung die Tabelle vorab mit einem VARCHAR(1)-Datentyp für die Spalte (oder lassen Sie AWS DMS die Tabelle erstellen). Dann lassen Sie die nachgeschaltete Verarbeitung ein „F“ als „False“ und ein „T“ als „True“ behandeln.

  • AWS DMS unterstützt die Änderungsverarbeitung von TRUNCATE-Operationen nicht.

  • Der OID LOB-Datentyp wird nicht auf das Ziel migriert.

  • AWS DMS unterstützt den PostGIS-Datentyp nur für homogene Migrationen.

  • Wenn es sich bei Ihrer Quelle um eine PostgreSQL-Datenbank handelt, die On-Premises oder auf einer Amazon-EC2-Instance ausgeführt wird, stellen Sie sicher, dass das Ausgabe-Plug-in test_decoding auf dem Quellendpunkt installiert ist. Sie finden dieses Plug-in im PostgreSQL-Paket contrib. Weitere Informationen zum Test-Decodier-Plugin finden Sie in der PostgreSQL-Dokumentation.

  • AWS DMS unterstützt keine Änderungsverarbeitung zum Festlegen und Aufheben von Spaltenstandardwerten (mit der Klausel ALTER COLUMN SET DEFAULT in ALTER TABLE-Anweisungen).

  • AWS DMS unterstützt keine Änderungsverarbeitung zum Festlegen von NULL-Zulässigkeit der Spalte (mit der Klausel ALTER COLUMN [SET|DROP] NOT NULL in ALTER TABLE-Anweisungen).

  • Wenn die logische Replikation aktiviert ist, beträgt die maximale Anzahl von Änderungen, die pro Transaktion im Arbeitsspeicher gespeichert werden, 4 MB. Danach werden die Änderungen auf den Datenträger übertragen. Daher nimmt der Wert für ReplicationSlotDiskUsage zu und restart_lsn schreitet erst voran, wenn die Transaktion abgeschlossen oder angehalten und das Rollback beendet ist. Da es sich um eine lange Transaktion handelt, kann das Rollback lange dauern. Vermeiden Sie daher lang laufende Transaktionen oder viele Untertransaktionen, wenn die logische Replikation aktiviert ist. Teilen Sie die Transaktion stattdessen in mehrere kleinere Transaktionen auf.

    In Aurora PostgreSQL Version 13 und höher können Sie den logical_decoding_work_mem Parameter so einstellen, dass gesteuert wird, wann DMS-Spills Daten auf die Festplatte ändern. Weitere Informationen finden Sie unter Überlaufdateien in Aurora PostgreSQL.

  • Eine Tabelle mit einem ARRAY-Datentyp muss über einen Primärschlüssel verfügen. Eine Tabelle mit einem ARRAY-Datentyp ohne Primärschlüssel wird während Volllastvorgängen angehalten.

  • AWS DMS unterstützt die Replikation partitionierter Tabellen nicht. Wenn eine partitionierte Tabelle erkannt wird, geschieht Folgendes:

    • Der Endpunkt meldet eine Liste von über- und untergeordneten Tabellen.

    • AWS DMS erstellt die Tabelle auf der Zieldatenbank als eine reguläre Tabelle mit den gleichen Eigenschaften wie die ausgewählten Tabellen.

    • Wenn die übergeordnete Tabelle in der Quelldatenbank denselben Primärschlüsselwert wie ihre untergeordneten Tabellen hat, wird ein "Duplikatschlüssel" generiert.

  • Um partitionierte Tabellen aus einer PostgreSQL-Quelle auf ein PostgreSQL-Ziel zu replizieren, müssen Sie zunächst die über- und untergeordneten Tabellen im Ziel manuell erstellen. Definieren Sie anschließend eine separate Aufgabe, um auf diese Tabellen zu replizieren. Legen Sie die Aufgabenkonfiguration in solchen Fällen auf Vor dem Laden kürzen fest.

  • Der PostgreSQL-Datentyp NUMERIC verfügt über keine feste Größe. Wenn Sie Daten mit dem Datentyp NUMERIC, jedoch ohne Präzision und Skalierung übertagen, verwendet DMS standardmäßig NUMERIC(28,6) (mit 28 als Genauigkeit und 6 als Skalierung). Beispielsweise wird der Wert 0,611111104488373 von der Quelle auf dem PostgreSQL-Ziel in 0,611111 konvertiert.

  • AWS DMS unterstützt Aurora PostgreSQL Serverless V1 nur als Quelle für Volllastaufgaben. AWS DMS unterstützt Aurora PostgreSQL Serverless V2 als Quelle für Volllast-, Volllast-und-CDC- und reine CDC-Aufgaben.

  • AWS DMS unterstützt nicht die Replikation einer Tabelle mit einem eindeutigen Index, der mit einer coalesce-Funktion erstellt wurde.

  • Bei Verwendung des LOB-Modus müssen die Quelltabelle und die entsprechende Zieltabelle einen identischen Primärschlüssel aufweisen. Wenn eine der Tabellen keinen Primärschlüssel aufweist, ist das Ergebnis der DELETE- und UPDATE-Datensatzoperationen nicht vorhersehbar.

  • Bei Verwendung des Features für paralleles Laden wird die Tabellensegmentierung nach Partitionen oder Unterpartitionen nicht unterstützt. Weitere Informationen zum parallelen Laden finden Sie unter Verwendung des parallelen Ladens für ausgewählte Tabellen und Ansichten.

  • AWS DMS unterstützt keine verzögerten Einschränkungen.

  • AWS DMS Version 3.4.7 unterstützt PostgreSQL 14.x als Quelle mit diesen Einschränkungen:

    • AWS DMS unterstützt keine Änderungsverarbeitung von zweiphasigen Commits.

    • AWS DMS unterstützt keine logische Replikation zum Streamen langer laufender Transaktionen.

  • AWS DMS unterstützt CDC für Amazon-RDS-Proxy nicht für PostgreSQL als Quelle.

  • Bei der Verwendung von Quellfiltern, die keine Primärschlüsselspalte enthalten, werden DELETE-Operationen nicht erfasst.

  • Wenn Ihre Quelldatenbank auch ein Ziel für ein anderes Replikationssystem eines Drittanbieters ist, werden DDL-Änderungen während CDC möglicherweise nicht migriert. Diese Situation kann das Auslösen des Ereignisauslösers awsdms_intercept_ddl verhindern. Ändern Sie diesen Auslöser in der Quelldatenbank wie folgt, um das Problem zu umgehen:

    alter event trigger awsdms_intercept_ddl enable always;

  • AWS DMS unterstützt CDC für Datenbank-Cluster von Amazon RDS Multi-AZ nicht für PostgreSQL als Quelle, da Datenbank-Cluster von RDS für PostgreSQL Multi-AZ keine logische Replikation unterstützen.

Quelldatentypen für PostgreSQL

In der folgenden Tabelle sind die PostgreSQL-Quelldatentypen, die bei Verwendung von AWS DMS unterstützt werden, sowie deren Standardzuweisung zu AWS DMS-Datentypen aufgeführt.

Weitere Informationen zum Anzeigen des Datentyps, der im Ziel zugewiesen ist, finden Sie im Abschnitt für den Zielendpunkt, den Sie verwenden.

Weitere Informationen zu AWS DMS-Datentypen finden Sie unter Datentypen für den AWS Database Migration Service.

PostgreSQL-Datentypen

DMS-Datentypen

INTEGER

INT4

SMALLINT

INT2

BIGINT

INT8

NUMERIC (p,s)

Wenn die Präzision 0 bis 38 ist, verwenden Sie NUMERIC.

Wenn die Präzision 39 oder größer ist, verwenden Sie STRING.

DECIMAL(P,S)

Wenn die Präzision 0 bis 38 ist, verwenden Sie NUMERIC.

Wenn die Präzision 39 oder größer ist, verwenden Sie STRING.

REAL

REAL4

DOUBLE

REAL8

SMALLSERIAL

INT2

SERIAL

INT4

BIGSERIAL

INT8

MONEY

NUMERIC(38,4)

Der Datentyp MONEY ist in SQL Server FLOAT zugeordnet.

CHAR

WSTRING (1)

CHAR(N)

WSTRING (n)

VARCHAR(N)

WSTRING (n)

TEXT

NCLOB

BYTEA

BLOB

TIMESTAMP (ZEITSTEMPEL)

DATETIME

TIMESTAMP WITH TIME ZONE

DATETIME

DATUM

DATUM

TIME

TIME

TIME WITH TIME ZONE

TIME

INTERVAL

STRING (128) – 1 JAHR, 2 MONATE, 3 TAGE, 4 STUNDEN, 5 MINUTEN, 6 SEKUNDEN

BOOLEAN

CHAR (5) "false" oder "true"

ENUM

STRING (64)

CIDR

STRING (50)

INET

STRING (50)

MACADDR

STRING (18)

BIT (n)

STRING (n)

BIT VARYING (n)

STRING (n)

UUID

STRING

TSVECTOR

CLOB

TSQUERY

CLOB

XML

CLOB

POINT

STRING (255) "(x,y)"

LINE

STRING (255) "(x,y,z)"

LSEG

STRING (255) "((x1,y1),(x2,y2))"

BOX

STRING (255) "((x1,y1),(x2,y2))"

PATH

CLOB "((x1,y1),(xn,yn))"

POLYGON

CLOB "((x1,y1),(xn,yn))"

CIRCLE

STRING (255) "(x,y),r"

JSON

NCLOB

JSONB

NCLOB

ARRAY

NCLOB

COMPOSITE

NCLOB

HSTORE

NCLOB

INT4RANGE

STRING (255)

INT8RANGE

STRING (255)

NUMRANGE

STRING (255)

STRRANGE

STRING (255)

Arbeiten mit LOB-Quelldatentypen für PostgreSQL

PostgreSQL-Spaltengrößen wirken sich auf die Konvertierung von PostgreSQL-LOB-Datentypen in AWS DMS-Datentypen aus. Um damit zu arbeiten, führen Sie für die folgenden AWS DMS-Datentypen folgende Schritte aus:

  • BLOB – Legen Sie bei der Aufgabenerstellung für LOB-Grenze begrenzen auf den Wert Maximale LOB-Größe (KB) fest.

  • CLOB – Die Replikation verarbeitet jedes Zeichen als UTF8-Zeichen. Suchen Sie daher nach der Länge des längsten Zeichentextes in der Spalte, hier als max_num_chars_text gezeigt. Nutzen Sie diese Länge, um den Wert für LOB-Größe begrenzen auf anzugeben. Wenn die Daten 4-Byte-Zeichen enthalten, multiplizieren Sie diese mit 2, um den Wert Limit LOB size to (LOB-Größe begrenzen auf) festzulegen, da dieser in Bytes angegeben wird. In diesem Fall ist Limit LOB size to (LOB-Größe begrenzen auf) gleich max_num_chars_text, multipliziert mit 2.

  • NCLOB – Die Replikation verarbeitet jedes Zeichen als Doppelbyte-Zeichen. Suchen Sie daher nach der Länge des längsten Zeichentextes in der Spalte (max_num_chars_text) und multiplizieren ihn mit 2. Auf diese Weise geben Sie den Wert für LOB-Größe begrenzen auf an. In diesem Fall ist Limit LOB size to (LOB-Größe begrenzen auf) gleich max_num_chars_text, multipliziert mit 2. Wenn die Daten 4-Byte-Zeichen enthalten, multiplizieren Sie diese erneut mit 2. In diesem Fall ist Limit LOB size to (LOB-Größe begrenzen auf) gleich max_num_chars_text, multipliziert mit 4.