SQLLogische Postgre-Replikation mit Aurora verwenden - Amazon Aurora

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.

SQLLogische Postgre-Replikation mit Aurora verwenden

Durch die Verwendung SQL der logischen Replikationsfunktion von Postgre mit Ihrem Aurora SQL Postgre-DB-Cluster können Sie einzelne Tabellen statt der gesamten Datenbank-Instance replizieren und synchronisieren. Für die logische Replikation wird ein Veröffentlichungs- und Abonnementmodell verwendet, um Änderungen aus einer Quelle an einen oder mehrere Empfänger zu replizieren. Es funktioniert mithilfe von Änderungsdatensätzen aus dem SQL Postgre-Write-Ahead-Log (). WAL Die Quelle oder der Herausgeber sendet WAL Daten für die angegebenen Tabellen an einen oder mehrere Empfänger (Abonnenten), wodurch die Änderungen repliziert werden und die Tabelle eines Abonnenten mit der Tabelle des Herausgebers synchronisiert wird. Die Änderungen des Herausgebers werden anhand einer Veröffentlichung identifiziert. Abonnenten erhalten die Änderungen, indem sie ein Abonnement erstellen, das die Verbindung mit der Datenbank des Herausgebers und den entsprechenden Veröffentlichungen definiert. Ein Replikationsslot ist der Mechanismus, der in diesem Schema verwendet wird, um den Fortschritt eines Abonnements zu verfolgen.

Für Aurora SQL Postgre-DB-Cluster werden die WAL Datensätze im Aurora-Speicher gespeichert. Der Aurora SQL Postgre-DB-Cluster, der in einem logischen Replikationsszenario als Herausgeber fungiert, liest die WAL Daten aus dem Aurora-Speicher, dekodiert sie und sendet sie an den Abonnenten, sodass die Änderungen auf die Tabelle auf dieser Instance angewendet werden können. Der Herausgeber verwendet einen logischen Decoder, um die Daten für die Verwendung durch Abonnenten zu dekodieren. Standardmäßig verwenden Aurora SQL Postgre-DB-Cluster beim Senden von Daten das native SQL pgoutput Postgre-Plugin. Es sind auch andere logische Decoder verfügbar. Aurora Postgre unterstützt beispielsweise SQL auch das wal2json Plugin, das WAL Daten konvertiert JSON in.

Ab Aurora Postgre SQL Version 14.5, 13.8, 12.12 und 11.17 SQL erweitert Aurora Postgre den SQL logischen Postgre-Replikationsprozess um einen Write-Through-Cache, um die Leistung zu verbessern. Die WAL Transaktionsprotokolle werden lokal in einem Puffer zwischengespeichert, um die Menge an Festplatten-E/A zu reduzieren, d. h. das Lesen aus dem Aurora-Speicher während der logischen Dekodierung. Der Write-Through-Cache wird standardmäßig verwendet, wenn Sie die logische Replikation für Ihren Aurora Postgre-DB-Cluster verwenden. SQL Aurora bietet mehrere Funktionen, mit denen Sie den Cache verwalten können. Weitere Informationen finden Sie unter Verwaltung des Write-Through-Cache für die SQL logische Replikation von Aurora Postgre.

Die logische Replikation wird von allen derzeit verfügbaren Aurora SQL Postgre-Versionen unterstützt. Weitere Informationen finden Sie in den Versionshinweisen für Aurora Postgre SQL von Amazon Aurora SQL Postgre.

Die logische Replikation wird von Babelfish for Aurora Postgre SQL ab den folgenden Versionen unterstützt:

  • 15.7 und höhere Versionen

  • 16.3 und höhere Versionen

Anmerkung

Zusätzlich zur systemeigenen SQL logischen Replikationsfunktion von Postgre, die in Postgre SQL 10 eingeführt wurde, unterstützt Aurora Postgre SQL auch die Erweiterung. pglogical Weitere Informationen finden Sie unter Verwenden von pglogical, um Daten zwischen Instances zu synchronisieren.

Weitere Informationen zur SQL logischen Postgre-Replikation finden Sie in der Postgre-Dokumentation unter Konzepte der logischen Replikation und der logischen Dekodierung. SQL

In den folgenden Themen finden Sie Informationen zur Einrichtung der logischen Replikation zwischen Ihren Aurora SQL Postgre-DB-Clustern.

Logische Replikation für Ihren Aurora SQL Postgre-DB-Cluster einrichten

Für das Einrichten der logischen Replikation sind rds_superuser-Berechtigungen erforderlich. Ihr Aurora SQL Postgre-DB-Cluster muss für die Verwendung einer benutzerdefinierten DB-Cluster-Parametergruppe konfiguriert sein, damit Sie die erforderlichen Parameter wie im folgenden Verfahren beschrieben festlegen können. Weitere Informationen finden Sie unter DB-Cluster-Parametergruppen für Amazon Aurora Aurora-DB-Cluster.

So richten Sie die SQL logische Postgre-Replikation für einen Aurora Postgre-DB-Cluster ein SQL
  1. Melden Sie sich bei der an AWS Management Console und öffnen Sie die RDS Amazon-Konsole unter https://console.aws.amazon.com/rds/.

  2. Wählen Sie im Navigationsbereich Ihren Aurora SQL Postgre-DB-Cluster aus.

  3. Öffnen Sie die Registerkarte Configuration (Konfiguration). Suchen Sie in den Instance-Details den Link Parametergruppe mit der DB-Cluster-Parametergruppe als Typ.

  4. Wählen Sie den Link, um die benutzerdefinierten Parameter zu öffnen, die mit Ihrem Aurora SQL Postgre-DB-Cluster verknüpft sind.

  5. Geben Sie in das Suchfeld Parameters (Parameter) rds ein, um den rds.logical_replication-Parameter zu finden. Der Standardwert für diesen Parameter ist 0, was bedeutet, dass er standardmäßig deaktiviert ist.

  6. Wählen Sie Edit parameters (Parameter bearbeiten) aus, um auf die Eigenschaftswerte zuzugreifen. Wählen Sie dann 1 aus der Auswahl aus, um die Funktion zu aktivieren. Abhängig von Ihrer erwarteten Auslastung müssen Sie möglicherweise auch die Einstellungen für die folgenden Parameter ändern. In vielen Fällen sind die Standardwerte jedoch ausreichend.

    • max_replication_slots: Legen Sie diesen Parameter auf einen Wert fest, der mindestens der geplanten Gesamtzahl der Veröffentlichungen und Abonnements der logischen Replikation entspricht. Wenn Sie verwenden AWS DMS, sollte dieser Parameter mindestens Ihren geplanten Change-Data-Capture-Aufgaben aus dem Cluster sowie Veröffentlichungen und Abonnements für logische Replikation entsprechen.

    • max_wal_sendersund max_logical_replication_workers — Stellen Sie diese Parameter auf einen Wert ein, der mindestens der Anzahl der logischen Replikationsslots entspricht, die Sie aktiv sein möchten, oder der Anzahl der aktiven AWS DMS Aufgaben für die Datenänderungserfassung. Wenn Sie einen logischen Replikationsslot inaktiv lassen, wird die Bereinigung durch Entfernen überholter Tupel aus Tabellen verhindert. Wir empfehlen daher, Replikationsslots zu überwachen und inaktive Slots nach Bedarf zu entfernen.

    • max_worker_processes: Legen Sie diesen Parameter auf einen Wert fest, der mindestens der Summe der Werte max_logical_replication_workers, autovacuum_max_workers und max_parallel_workers entspricht. Bei kleinen DB-Instance-Klassen können sich Hintergrund-Workerprozesse auf Anwendungs-Workloads auswirken. Überwachen Sie daher die Leistung Ihrer Datenbank, wenn Sie max_worker_processes höher als den Standardwert festlegen. (Der Standardwert ist das Ergebnis vonGREATEST(${DBInstanceVCPU*2},8}, was bedeutet, dass dieser Wert standardmäßig entweder 8 oder das Doppelte der DB-Instance-Klasse CPU entspricht, je nachdem, welcher Wert größer ist).

    Anmerkung

    Sie können die Parameterwerte in einer benutzerdefinierten DB-Parametergruppe ändern. Die Parameterwerte in einer Standard-DB-Parametergruppe können nicht geändert werden.

  7. Wählen Sie Änderungen speichern.

  8. Starten Sie die Writer-Instance Ihres Aurora SQL Postgre-DB-Clusters neu, damit Ihre Änderungen wirksam werden. Wählen Sie in der RDS Amazon-Konsole die primäre DB-Instance des Clusters aus und klicken Sie im Aktionsmenü auf Reboot.

  9. Wenn die Instance verfügbar ist, können Sie wie folgt überprüfen, ob die logische Replikation aktiviert ist.

    1. Wird verwendetpsql, um eine Verbindung zur Writer-Instance Ihres Aurora SQL Postgre-DB-Clusters herzustellen.

      psql --host=your-db-cluster-instance-1.aws-region.rds.amazonaws.com --port=5432 --username=postgres --password --dbname=labdb
    2. Stellen Sie mithilfe des folgenden Befehls sicher, dass die logische Replikation aktiviert wurde.

      labdb=> SHOW rds.logical_replication; rds.logical_replication ------------------------- on (1 row)
    3. Überprüfen Sie, dass wal_level auf logical festgelegt ist.

      labdb=> SHOW wal_level; wal_level ----------- logical (1 row)

Ein Beispiel für die Verwendung logischer Replikation, um eine Datenbanktabelle mit Änderungen aus einem Aurora SQL Postgre-DB-Quellcluster zu synchronisieren, finden Sie unterBeispiel: Verwendung der logischen Replikation mit Aurora SQL Postgre-DB-Clustern.

Deaktivieren der logischen Replikation

Nachdem Sie Ihre Replikationsaufgaben abgeschlossen haben, sollten Sie den Replikationsprozess beenden, Replikationsslots löschen und die logische Replikation deaktivieren. Bevor Sie Slots löschen, vergewissern Sie sich, dass diese nicht mehr benötigt werden. Aktive Replikationsslots können nicht gelöscht werden.

So deaktivieren Sie die logische Replikation
  1. Löschen Sie alle Replikations-Slots.

    Um alle Replikationsslots zu löschen, stellen Sie eine Verbindung zum Herausgeber her und führen Sie den folgenden SQL Befehl aus.

    SELECT pg_drop_replication_slot(slot_name) FROM pg_replication_slots WHERE slot_name IN (SELECT slot_name FROM pg_replication_slots);

    Die Replikationsslots dürfen nicht aktiv sein, wenn Sie diesen Befehl ausführen.

  2. Ändern Sie die dem Herausgeber zugeordnete benutzerdefinierte DB-Cluster-Parametergruppe, wie in Logische Replikation für Ihren Aurora SQL Postgre-DB-Cluster einrichten beschrieben. Legen Sie den rds.logical_replication-Parameter jedoch auf 0 fest.

    Weitere Informationen zu benutzerdefinierten DB-Parametergruppen finden Sie unter Ändern von Parametern in einer DB-Cluster-Parametergruppe in Amazon Aurora.

  3. Starten Sie den SQL Publisher-Aurora-Postgre-DB-Cluster neu, damit die Änderung des rds.logical_replication Parameters wirksam wird.

Verwaltung des Write-Through-Cache für die SQL logische Replikation von Aurora Postgre

Standardmäßig verwenden Aurora SQL Postgre-Versionen 14.5, 13.8, 12.12 und 11.17 und höher einen Write-Through-Cache, um die Leistung für die logische Replikation zu verbessern. Ohne den Write-Through-Cache SQL verwendet Aurora Postgre die Aurora-Speicherschicht bei der Implementierung des systemeigenen logischen SQL Postgre-Replikationsprozesses. Dazu werden WAL Daten in den Speicher geschrieben und dann aus dem Speicher zurückgelesen, um sie zu dekodieren und an ihre Ziele (Abonnenten) zu senden (zu replizieren). Dies kann zu Engpässen bei der logischen Replikation für Aurora Postgre-DB-Cluster führen. SQL

Der Write-Through-Cache reduziert die Notwendigkeit, die Aurora-Speicherschicht zu verwenden. Anstatt immer aus der Aurora-Speicherschicht zu schreiben und zu lesen, SQL verwendet Aurora Postgre einen Puffer, um den logischen WAL Stream zwischenzuspeichern, sodass er während des Replikationsprozesses verwendet werden kann, anstatt immer von der Festplatte abgerufen zu werden. Dieser Puffer ist der SQL native Postgre-Cache, der für die logische Replikation verwendet wird und in den Aurora SQL Postgre-DB-Clusterparametern als identifiziert wird. rds.logical_wal_cache Standardmäßig verwendet dieser Cache 1/32 der Puffer-Cache-Einstellung (shared_buffers) des Aurora SQL Postgre-DB-Clusters, aber nicht weniger als 64 kB und nicht mehr als die Größe eines WAL Segments, typischerweise 16 MB.

Wenn Sie logische Replikation mit Ihrem Aurora SQL Postgre-DB-Cluster verwenden (für die Versionen, die den Write-Through-Cache unterstützen), können Sie die Cache-Trefferquote überwachen, um zu sehen, wie gut sie für Ihren Anwendungsfall funktioniert. Stellen Sie dazu mithilfe der Aurora-Funktion eine Verbindung zur Schreibinstanz Ihres Aurora SQL Postgre-DB-Clusters her psql und verwenden Sie sie dannaurora_stat_logical_wal_cache, wie im folgenden Beispiel gezeigt.

SELECT * FROM aurora_stat_logical_wal_cache();

Die Funktion gibt beispielsweise die folgende Ausgabe zurück.

name | active_pid | cache_hit | cache_miss | blks_read | hit_rate | last_reset_timestamp -----------+------------+-----------+------------+-----------+----------+-------------- test_slot1 | 79183 | 24 | 0 | 24 | 100.00% | 2022-08-05 17:39... test_slot2 | | 1 | 0 | 1 | 100.00% | 2022-08-05 17:34... (2 rows)

Die last_reset_timestamp-Werte wurden aus Gründen der Lesbarkeit gekürzt. Weitere Informationen zu dieser Funktion finden Sie unter aurora_stat_logical_wal_cache.

Aurora Postgre SQL bietet die folgenden zwei Funktionen zur Überwachung des Write-Through-Cache.

Wenn Sie feststellen, dass die automatisch angepasste WAL Cachegröße für Ihre Workloads nicht ausreicht, können Sie den Wert von rds.logical_wal_cache manuell ändern, indem Sie den Parameter in Ihrer benutzerdefinierten DB-Cluster-Parametergruppe ändern. Beachten Sie, dass jeder positive Wert unter 32 kB als 32 kB behandelt wird. Weitere Informationen dazu finden Sie unter Write Ahead Log in der Postgre-Dokumentation. wal_buffers SQL

Verwaltung logischer Steckplätze für Aurora Postgre SQL

Streaming-Aktivitäten werden in der pg_replication_origin_status-Ansicht erfasst. Wenn Sie den Inhalt dieser Ansicht anzeigen möchten, können Sie die pg_show_replication_origin_status()-Funktion verwenden, wie im Folgenden gezeigt:

SELECT * FROM pg_show_replication_origin_status();

Mit der folgenden SQL Abfrage können Sie eine Liste Ihrer logischen Steckplätze abrufen.

SELECT * FROM pg_replication_slots;

Zum Löschen eines logischen Slots können Sie den pg_drop_replication_slot mit dem Namen des Slots verwenden, wie im folgenden Befehl gezeigt.

SELECT pg_drop_replication_slot('test_slot');

Beispiel: Verwendung der logischen Replikation mit Aurora SQL Postgre-DB-Clustern

Das folgende Verfahren zeigt Ihnen, wie Sie die logische Replikation zwischen zwei Aurora SQL Postgre-DB-Clustern starten. Sowohl der Herausgeber als auch der Abonnent müssen für die logische Replikation konfiguriert sein, wie unter Logische Replikation für Ihren Aurora SQL Postgre-DB-Cluster einrichten beschrieben.

Der Aurora SQL Postgre-DB-Cluster, der der designierte Herausgeber ist, muss auch den Zugriff auf den Replikationssteckplatz ermöglichen. Ändern Sie dazu die Sicherheitsgruppe, die der virtuellen öffentlichen Cloud (VPC) des Aurora SQL Postgre-DB-Clusters zugeordnet ist, die auf dem VPC Amazon-Service basiert. Erlauben Sie eingehenden Zugriff, indem Sie die Sicherheitsgruppe, die mit der des Abonnenten verknüpft istVPC, zur Sicherheitsgruppe des Herausgebers hinzufügen. Weitere Informationen finden Sie unter Steuern des Datenverkehrs zu Ressourcen mithilfe von Sicherheitsgruppen im VPCAmazon-Benutzerhandbuch.

Wenn diese vorbereitenden Schritte abgeschlossen sind, können Sie SQL CREATE PUBLICATION Postgre-Befehle für den Herausgeber und CREATE SUBSCRIPTION den Abonnenten verwenden, wie im folgenden Verfahren beschrieben.

Um den logischen Replikationsprozess zwischen zwei Aurora SQL Postgre-DB-Clustern zu starten

Bei diesen Schritten wird davon ausgegangen, dass Ihre Aurora SQL Postgre-DB-Cluster über eine Writer-Instance mit einer Datenbank verfügen, in der Sie die Beispieltabellen erstellen können.

  1. Auf dem Publisher Aurora SQL Postgre-DB-Cluster

    1. Erstellen Sie eine Tabelle mit der folgenden SQL Anweisung.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
    2. Fügen Sie mithilfe der folgenden SQL Anweisung Daten in die Herausgeberdatenbank ein.

      INSERT INTO LogicalReplicationTest VALUES (generate_series(1,10000));
    3. Stellen Sie mithilfe der folgenden SQL Anweisung sicher, dass Daten in der Tabelle vorhanden sind.

      SELECT count(*) FROM LogicalReplicationTest;
    4. Erstellen Sie eine Veröffentlichung für diese Tabelle, indem Sie die CREATE PUBLICATION-Anweisung wie folgt verwenden.

      CREATE PUBLICATION testpub FOR TABLE LogicalReplicationTest;
  2. Auf dem Aurora SQL Postgre-DB-Cluster für Abonnenten

    1. Erstellen Sie wie folgt dieselbe LogicalReplicationTest-Tabelle auf dem Abonnenten, die Sie auf dem Herausgeber erstellt haben.

      CREATE TABLE LogicalReplicationTest (a int PRIMARY KEY);
    2. Stellen Sie sicher, dass diese Tabelle leer ist.

      SELECT count(*) FROM LogicalReplicationTest;
    3. Erstellen Sie ein Abonnement, um die Änderungen vom Herausgeber zu erhalten. Sie müssen die folgenden Informationen über den Publisher Aurora SQL Postgre-DB-Cluster verwenden.

      • host — Die SQL Writer-DB-Instance des Publishers Aurora Postgre-DB-Clusters.

      • port – Der Port, den die Writer-DB-Instance überwacht. Die Standardeinstellung für Postgre SQL ist 5432.

      • dbname – Der Name der Datenbank.

      CREATE SUBSCRIPTION testsub CONNECTION 'host=publisher-cluster-writer-endpoint port=5432 dbname=db-name user=user password=password' PUBLICATION testpub;
      Anmerkung

      Geben Sie aus Sicherheitsgründen ein anderes Passwort als hier angegeben an.

      Nachdem das Abonnement erstellt wurde, wird für den Herausgeber ein Slot für die logische Replikation erstellt.

    4. Um für dieses Beispiel zu überprüfen, ob die ursprünglichen Daten auf dem Abonnenten repliziert wurden, verwenden Sie die folgende SQL Anweisung in der Abonnentendatenbank.

      SELECT count(*) FROM LogicalReplicationTest;

Alle weiteren Änderungen am Herausgeber werden beim Abonnenten repliziert.

Durch die logische Replikation wird die Leistung beeinträchtigt. Es wird empfohlen, die logische Replikation zu deaktivieren, nachdem Ihre Replikationsaufgaben abgeschlossen sind.

Beispiel: Logische Replikation mit Aurora Postgre SQL und AWS Database Migration Service

Sie können das AWS Database Migration Service (AWS DMS) verwenden, um eine Datenbank oder einen Teil einer Datenbank zu replizieren. Wird verwendet AWS DMS , um Ihre Daten von einer Aurora SQL Postgre-Datenbank in eine andere Open Source- oder kommerzielle Datenbank zu migrieren. Weitere Informationen dazu AWS DMS finden Sie im AWS Database Migration Service Benutzerhandbuch.

Das folgende Beispiel zeigt, wie die logische Replikation von einer Aurora SQL Postgre-Datenbank als Herausgeber eingerichtet und dann AWS DMS für die Migration verwendet wird. In diesem Beispiel werden der gleiche Herausgeber und Abonnent verwendet, die unter erstellt wurde Beispiel: Verwendung der logischen Replikation mit Aurora SQL Postgre-DB-Clustern.

Um die logische Replikation mit einzurichten AWS DMS, benötigen Sie Angaben zu Ihrem Herausgeber und Abonnenten von AmazonRDS. Insbesondere benötigen Sie Details zur Writer-DB-Instance des Herausgebers und zur DB-Instance des Abonnenten.

Fordern Sie die folgenden Informationen für die Writer-DB-Instance des Herausgebers an:

  • Die ID der virtuellen privaten Cloud (VPC)

  • Die Subnetzgruppe

  • Die Availability Zone (AZ)

  • Die VPC Sicherheitsgruppe

  • Die ID der DB-Instance

Fordern Sie die folgenden Informationen für die DB-Instance des Herausgebers an:

  • Die ID der DB-Instance

  • Die Quell-Engine

Zur Verwendung AWS DMS für die logische Replikation mit Aurora Postgre SQL
  1. Bereiten Sie die Herausgeberdatenbank für die Arbeit vor. AWS DMS

    Zu diesem Zweck müssen Sie bei Postgre-Datenbanken der SQL Version 10.x und höher AWS DMS Wrapper-Funktionen auf die Publisher-Datenbank anwenden. Einzelheiten zu diesen und späteren Schritten finden Sie in den Anweisungen unter Verwenden von Postgre SQL Version 10.x und höher als Quelle im Benutzerhandbuch. AWS DMSAWS Database Migration Service

  2. Melden Sie sich bei der an AWS Management Console und öffnen Sie die AWS DMS Konsole unter. https://console.aws.amazon.com/dms/v2 Wählen Sie oben rechts dieselbe AWS Region aus, in der sich der Herausgeber und der Abonnent befinden.

  3. Erstellen Sie eine AWS DMS Replikationsinstanz.

    Wählen Sie Werte, die mit denen für die Writer-DB-Instance des Herausgebers identisch sind. Dazu gehören die folgenden Einstellungen:

    • Wählen Sie für VPCdasselbe aus VPC wie für die Writer-DB-Instance.

    • Wählen Sie für Replikations-Subnetzgruppe eine Subnetzgruppe mit denselben Werten wie die Writer-DB-Instance aus. Erstellen Sie bei Bedarf eine Neue.

    • Wählen Sie unter Availability zone (Availability Zone) dieselbe Zone wie für die Writer-DB-Instance aus.

    • Wählen Sie für VPCSecurity Group dieselbe Gruppe wie für die Writer-DB-Instance aus.

  4. Erstellen Sie einen AWS DMS Endpunkt für die Quelle.

    Geben Sie unter Verwendung der folgenden Einstellungen den Herausgeber als Quellendpunkt an:

    • Wählen Sie unter Endpoint type (Endpunkttyp) die Option Source endpoint (Quellendpunkt) aus.

    • Wählen Sie Select RDS DB Instance.

    • Wählen Sie zum RDSBeispiel die DB-ID der Writer-DB-Instance des Herausgebers aus.

    • Wählen Sie unter Source engine (Quellen-Engine) die Option postgres aus.

  5. Erstellen Sie einen AWS DMS Endpunkt für das Ziel.

    Geben Sie den Abonnenten unter Verwendung der folgenden Einstellungen als Zielendpunkt an:

    • Wählen Sie unter Endpoint type (Endpunkttyp) die Option Target endpoint (Zielendpunkt) aus.

    • Wählen Sie Select RDS DB Instance aus.

    • Wählen Sie zum RDSBeispiel die DB-ID der Abonnenten-DB-Instance aus.

    • Wählen Sie einen Wert für Source engine (Quell-Engine) aus. Wenn der Abonnent beispielsweise eine RDS SQL Postgre-Datenbank ist, wählen Sie Postgres. Wenn der Abonnent eine Aurora SQL Postgre-Datenbank ist, wählen Sie aurora-postgresql.

  6. Erstellen Sie eine Datenbankmigrationsaufgabe. AWS DMS

    Sie geben mit der Datenbankmigrationsaufgabe an, welche Datenbanktabelle migriert werden sollen, um Daten mithilfe des Zielschemas zuzuordnen und um neue Tabellen für die Zieldatenbank zu erstellen. Verwenden Sie zumindest die folgenden Einstellungen für Task configuration (Aufgabenkonfiguration):

    • Wählen Sie unter Replication instance (Replikations-Instance) die Replikations-Instance aus, die Sie in einem früheren Schritt erstellt haben.

    • Wählen Sie unter Source database endpoint (Quelldatenbank-Endpunkt) die Herausgeberquelle aus, die Sie in einem früheren Schritt erstellt haben.

    • Wählen Sie unter Target database endpoint (Zieldatenbank-Endpunkt) das Abonnentenziel aus, das Sie in einem früheren Schritt erstellt haben.

    Die übrigen Aufgabendetails sind von Ihrem Migrationsprojekt abhängig. Weitere Informationen zum Angeben aller Details für DMS Aufgaben finden Sie unter Arbeiten mit AWS DMS Aufgaben im AWS Database Migration Service Benutzerhandbuch.

Nachdem die Aufgabe AWS DMS erstellt wurde, beginnt sie mit der Migration der Daten vom Herausgeber zum Abonnenten.