PostgreSQL-Quelldatenbank für kontinuierliche Migrationen konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Ihre Quelldatenbankinstanzen für kontinuierliche homogene PostgreSQL-Migrationen zu AlloyDB for PostgreSQL-Clustern konfigurieren. Weitere Informationen zu unterstützten Quellversionen finden Sie unter Unterstützte Quell- und Zieldatenbanken. Wenn Sie Schnellstart-Migrationen verwenden möchten, folgen Sie der Anleitung unter Schnellstart-Migrationen verwenden. Schnellstartmigrationen bieten einen vereinfachten Migrationsablauf, der die pgnative-Replikation und eine spezielle Verbindung auf Basis von Private Service Connect-Schnittstellen verwendet. Weitere Informationen finden Sie in der Hauptdokumentation zu Database Migration Service unter Informationen zu Schnellstart-Migrationen.

Diese Seite enthält eigenständige Verfahren für jede unterstützte Quelle:

Selbst gehostete PostgreSQL-Quelle konfigurieren

So konfigurieren Sie eine selbst gehostete PostgreSQL-Quellinstanz (lokal oder auf einer Compute Engine-VM gehostet) für die kontinuierliche Migration:

  1. Bei selbst gehosteten PostgreSQL-Quellen migriert der Database Migration Service alle Datenbanken unter Ihrer Quellinstanz mit Ausnahme der Vorlagendatenbanken template0 und template1.
  2. Achten Sie darauf, dass die Quellinstanz die Standarddatenbank postgres enthält. Wenn diese Datenbank nicht vorhanden ist, erstellen Sie sie, bevor Sie die Migration konfigurieren.
  3. Konfigurieren Sie die Netzwerkclient-Authentifizierung in der Datei pg_hba.conf. Fügen Sie Einträge hinzu, die Replikationsverbindungen und Datenbankzugriff über den IP-Adressbereich des AlloyDB for PostgreSQL-Zielclusters, den VPC-CIDR-Bereich oder den Reverse-SSH-Bastion-Host zulassen: 
    # Allow replication connections
host  replication  MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5
# Allow database access
host  all          MIGRATION_USER_ACCOUNT_NAME  DESTINATION_IP_OR_CIDR  md5

    Laden Sie die PostgreSQL-Konfiguration neu, um die pg_hba.conf-Regeln anzuwenden:

    SELECT pg_reload_conf();
  4. Prüfen Sie die auf Ihren Quelldatenbanken installierten PostgreSQL-Erweiterungen. Der Database Migration Service migriert keine Erweiterungen, die von AlloyDB for PostgreSQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen nicht unterstützte Erweiterungen referenzieren. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

    Die Erweiterung pg_cron wird nicht automatisch vom Database Migration Service migriert, wird aber in AlloyDB for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihrer Quelldatenbank verwenden, installieren Sie es nach dem Hochstufen der Migration neu und konfigurieren Sie es im AlloyDB for PostgreSQL-Zielcluster.

  5. Erstellen Sie in Ihrer Quellinstanz ein dediziertes Nutzerkonto für die Migration und gewähren Sie ihm die erforderlichen Berechtigungen:
    1. Stellen Sie über ein Administratorkonto eine Verbindung zur Quellinstanz her, erstellen Sie den Nutzer und weisen Sie die Replikationsrolle zu: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
ALTER USER MIGRATION_USER_ACCOUNT_NAME WITH REPLICATION;
    2. Gewähren Sie dem Migrationsnutzerkonto die erforderlichen Berechtigungen für die Standarddatenbank postgres sowie für jede Datenbank, die Sie migrieren möchten. Führen Sie die folgenden Befehle in jeder Datenbank für jedes Schema aus, mit Ausnahme des Informationsschemas und der Schemas, die mit pg_ beginnen: 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. Installieren Sie die Erweiterung pglogical in jeder Datenbank, die Sie migrieren möchten, mit Ausnahme von template0 und template1:
    • Für PostgreSQL-Version 9.4: Führen Sie die folgenden Befehle aus: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
CREATE EXTENSION IF NOT EXISTS pglogical_origin;
    • Für PostgreSQL-Version 9.5 und höher: Führen Sie den folgenden Befehl aus: 
      CREATE EXTENSION IF NOT EXISTS pglogical;
  7. Prüfen Sie, ob Ihre Tabellen Primärschlüssel haben. Für kontinuierliche Migrationen erfordert die logische PostgreSQL-Replikation, dass Tabellen Primärschlüssel haben, um UPDATE- und DELETE-Vorgänge während der Change Data Capture-Phase (CDC) zu replizieren:
    • In Tabellen mit einem Primärschlüssel werden alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch repliziert.
    • Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service nur die Migration des ersten Snapshots und der nachfolgenden INSERT-Anweisungen während der CDC-Phase. Sie müssen die Anweisungen UPDATE und DELETE manuell migrieren.

      Wir empfehlen, Tabellen ohne Primärschlüssel vor Beginn der Migration Primärschlüssel hinzuzufügen. Informationen zum Generieren einer Abfrage zum Auflisten von Tabellen in einer PostgreSQL-Datenbank ohne Primärschlüssel oder zum manuellen Migrieren von UPDATE- und DELETE-Vorgängen finden Sie unter Debugging und andere Tools.

      Alternativ können Sie den Schnellstart-Migrationsablauf verwenden: ein vereinfachtes Migrationsszenario, bei dem Sie REPLICA IDENTITY verwenden können, um Tabellen ohne Primärschlüssel zu migrieren. Weitere Informationen finden Sie im Leitfaden Schnellstart-Migrationen verwenden.

  8. Quellen mit PostgreSQL-Version 9.5 und niedriger: Der Messwert für die Replikationsverzögerung ist für Quellinstanzen mit PostgreSQL-Versionen vor 9.6 nicht verfügbar. Wenn Sie diesen Messwert verwenden möchten, um den Migrationsfortschritt zu verfolgen, lesen Sie den Abschnitt Replikationsverzögerung aktivieren.
  9. Installieren Sie das pglogical-Paket und konfigurieren Sie die WAL- und Replikationsparameter auf Ihrem PostgreSQL-Server:
    1. Installieren Sie das Paket pglogical auf dem Hostbetriebssystem Ihres Datenbankservers. Pakete und Installationsanleitungen für Ihre Distribution finden Sie im pglogical-GitHub-Repository.
    2. Stellen Sie mit einem Administratorkonto eine Verbindung zu Ihrer PostgreSQL-Instanz her und legen Sie die folgenden Parameter fest:
      1. Legen Sie shared_preload_libraries so fest, dass 'pglogical' enthalten ist: 
        ALTER SYSTEM SET shared_preload_libraries = 'pglogical';
      2. Setzen Sie wal_level auf 'logical': 
        ALTER SYSTEM SET wal_level = 'logical';

        Weitere Informationen finden Sie in der PostgreSQL-Dokumentation unter wal_level.

      3. Setzen Sie wal_sender_timeout auf 0: 
        ALTER SYSTEM SET wal_sender_timeout = 0;

        Der Wert 0 deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird. Weitere Informationen finden Sie unter wal_sender_timeout.

      4. Legen Sie für max_replication_slots mindestens die Anzahl der zu migrierenden Datenbanken multipliziert mit der Anzahl der Migrationsjobs fest, zuzüglich Reserven für die Tabellensynchronisierung:

        Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und Sie 2 Migrationsjobs für diese Quelle erstellen, muss die Anzahl der Replikations-Slots mindestens 5 * 2 = 10 betragen, zuzüglich der Anzahl der Replikations-Slots, die bereits von anderen Aufgaben in der Quelle verwendet werden. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs prüfen. 

        ALTER SYSTEM SET max_replication_slots = MAX_REPLICATION_SLOTS;

        Der Standardwert für diesen Parameter ist 10. Siehe max_replication_slots.

      5. Setzen Sie max_wal_senders auf mindestens den Wert von max_replication_slots plus die Anzahl der Absender, die bereits auf Ihrer Instanz verwendet werden:

        Wenn für den Parameter max_replication_slots beispielsweise der Wert 10 festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs überprüfen. 

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

        Der Standardwert für diesen Parameter ist 10. Siehe max_wal_senders.

      6. Legen Sie für max_worker_processes mindestens die Anzahl der zu migrierenden Datenbanken plus die vorhandenen Worker-Prozesse auf Ihrer Instanz fest. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie zwei zusätzliche Worker-Prozesse pro Verbindung berücksichtigen (bis zu maximal 20 Worker): 
        ALTER SYSTEM SET max_worker_processes = MAX_WORKER_PROCESSES;

        Der Standardwert für diesen Parameter ist 8. Siehe max_worker_processes.

  10. Starten Sie den PostgreSQL-Server neu, damit die Konfigurationsänderungen wirksam werden.

Amazon RDS for PostgreSQL-Quelle konfigurieren

So konfigurieren Sie eine Amazon RDS for PostgreSQL-Quellinstanz für die kontinuierliche Migration:

  1. Bei Amazon RDS for PostgreSQL-Quellen migriert Database Migration Service alle Datenbanken unter Ihrer Quellinstanz, mit Ausnahme der Vorlagendatenbanken template0, template1 und der internen AWS-Datenbank rdsadmin.
  2. Achten Sie darauf, dass die Quellinstanz die Standarddatenbank postgres enthält. Wenn diese Datenbank nicht vorhanden ist, erstellen Sie sie, bevor Sie die Migration konfigurieren.
  3. Konfigurieren Sie die Regeln für eingehenden Traffic der Amazon RDS-VPC-Sicherheitsgruppe. Lassen Sie eingehende TCP-Verbindungen auf Port 5432 aus dem IP-Adressbereich des AlloyDB for PostgreSQL-Zielclusters, dem VPC-CIDR-Bereich oder der Reverse-SSH-Bastion-Host-VM zu.
  4. Prüfen Sie die auf Ihren Quelldatenbanken installierten PostgreSQL-Erweiterungen. Der Database Migration Service migriert keine Erweiterungen, die von AlloyDB for PostgreSQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen nicht unterstützte Erweiterungen referenzieren. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

    Die Erweiterung pg_cron wird nicht automatisch vom Database Migration Service migriert, wird aber in AlloyDB for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihrer Quelldatenbank verwenden, installieren Sie es nach dem Hochstufen der Migration neu und konfigurieren Sie es im AlloyDB for PostgreSQL-Zielcluster.

  5. Erstellen Sie in Ihrer Quellinstanz ein dediziertes Nutzerkonto für die Migration und gewähren Sie ihm die erforderlichen Berechtigungen:
    1. Stellen Sie mit einem Administratorkonto eine Verbindung zur Quellinstanz her, erstellen Sie den Nutzer und weisen Sie die von AWS verwaltete Rolle rds_replication zu: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. Gewähren Sie dem Migrationsnutzerkonto die erforderlichen Berechtigungen für die Standarddatenbank postgres sowie für jede Datenbank, die Sie migrieren möchten. Führen Sie die folgenden Befehle in jeder Datenbank für jedes Schema aus, mit Ausnahme des Informationsschemas und der Schemas, die mit pg_ beginnen: 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. Installieren Sie die Erweiterung pglogical in jeder Datenbank, die Sie migrieren möchten, mit Ausnahme von template0, template1 und rdsadmin. Führen Sie dazu diesen Befehl aus: 
    CREATE EXTENSION IF NOT EXISTS pglogical;

    Weitere Informationen zu den Anforderungen finden Sie in der AWS-Dokumentation unter PostgreSQL-Erweiterungen mit Amazon RDS for PostgreSQL verwenden.

  7. Prüfen Sie, ob Ihre Tabellen Primärschlüssel haben. Für kontinuierliche Migrationen erfordert die logische PostgreSQL-Replikation, dass Tabellen Primärschlüssel haben, um UPDATE- und DELETE-Vorgänge während der Change Data Capture-Phase (CDC) zu replizieren:
    • In Tabellen mit einem Primärschlüssel werden alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch repliziert.
    • Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service nur die Migration des ersten Snapshots und der nachfolgenden INSERT-Anweisungen während der CDC-Phase. Sie müssen die Anweisungen UPDATE und DELETE manuell migrieren.

      Wir empfehlen, Tabellen ohne Primärschlüssel vor Beginn der Migration Primärschlüssel hinzuzufügen. Informationen zum Generieren einer Abfrage zum Auflisten von Tabellen in einer PostgreSQL-Datenbank ohne Primärschlüssel oder zum manuellen Migrieren von UPDATE- und DELETE-Vorgängen finden Sie unter Debugging und andere Tools.

      Alternativ können Sie den Schnellstart-Migrationsablauf verwenden: ein vereinfachtes Migrationsszenario, bei dem Sie REPLICA IDENTITY verwenden können, um Tabellen ohne Primärschlüssel zu migrieren. Weitere Informationen finden Sie im Leitfaden Schnellstart-Migrationen verwenden.

  8. Konfigurieren Sie eine benutzerdefinierte DB-Parametergruppe und hängen Sie sie an Ihre Instanz an:
    1. Erstellen Sie eine benutzerdefinierte Parametergruppe (siehe Mit DB-Parametergruppen arbeiten in der AWS-Dokumentation) und konfigurieren Sie die folgenden Parameter:
      1. Legen Sie shared_preload_libraries so fest, dass pglogical enthalten ist.
      2. Setzen Sie rds.logical_replication auf 1. Mit diesem Parameter wird das logische WAL-Logging in Amazon RDS aktiviert. Siehe Logische Replikation für Amazon RDS for PostgreSQL.
      3. Setzen Sie wal_sender_timeout auf 0. Der Wert 0 deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird.
      4. Legen Sie für max_replication_slots mindestens die Anzahl der zu migrierenden Datenbanken multipliziert mit der Anzahl der Migrationsjobs fest, zuzüglich Reserven für die Tabellensynchronisierung:

        Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und Sie 2 Migrationsjobs für diese Quelle erstellen, muss die Anzahl der Replikations-Slots mindestens 5 * 2 = 10 betragen, zuzüglich der Anzahl der Replikations-Slots, die bereits von anderen Aufgaben in der Quelle verwendet werden. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs prüfen.

        Der Standardwert für diesen Parameter ist 10.

      5. Setzen Sie max_wal_senders auf mindestens den Wert von max_replication_slots plus die Anzahl der Absender, die bereits auf Ihrer Instanz verwendet werden:

        Wenn für den Parameter max_replication_slots beispielsweise der Wert 10 festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs überprüfen.

        Der Standardwert für diesen Parameter ist 10.

      6. Legen Sie für max_worker_processes mindestens die Anzahl der zu migrierenden Datenbanken plus die vorhandenen Worker-Prozesse auf Ihrer Instanz fest. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie zwei zusätzliche Worker-Prozesse pro Verbindung berücksichtigen (bis zu maximal 20 Worker):

        Der Standardwert für diesen Parameter ist 8.

    2. Hängen Sie die Parametergruppe an Ihre RDS-Datenbankinstanz an. Wenn Sie eine neue Instanz erstellen, finden Sie diese Option unter Zusätzliche Konfiguration. Andernfalls ändern Sie die Instanz, um die Parametergruppe anzuhängen.
  9. Starten Sie die Amazon RDS-Instanz neu, damit die Änderungen an der Parametergruppe wirksam werden.

Amazon Aurora PostgreSQL-Quelle konfigurieren

So konfigurieren Sie einen Amazon Aurora PostgreSQL-Quellcluster für die kontinuierliche Migration:

  1. Bei Amazon Aurora for PostgreSQL-Quellen migriert der Database Migration Service alle Datenbanken in Ihrem Quellcluster mit Ausnahme der Vorlagendatenbanken template0, template1 und der internen AWS-Datenbank rdsadmin.
  2. Achten Sie darauf, dass der Quellcluster die Standarddatenbank postgres enthält. Wenn diese Datenbank nicht vorhanden ist, erstellen Sie sie, bevor Sie die Migration konfigurieren.
  3. Konfigurieren Sie die Regeln für eingehenden Traffic der VPC-Sicherheitsgruppe Ihres Amazon Aurora-Clusters. Lassen Sie eingehende TCP-Verbindungen auf Port 5432 aus dem IP-Adressbereich des AlloyDB for PostgreSQL-Zielclusters, dem VPC-CIDR-Bereich oder der Reverse-SSH-Bastion-Host-VM zu.
  4. Prüfen Sie die auf Ihren Quelldatenbanken installierten PostgreSQL-Erweiterungen. Der Database Migration Service migriert keine Erweiterungen, die von AlloyDB for PostgreSQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen nicht unterstützte Erweiterungen referenzieren. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

    Die Erweiterung pg_cron wird nicht automatisch vom Database Migration Service migriert, wird aber in AlloyDB for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihrer Quelldatenbank verwenden, installieren Sie es nach dem Hochstufen der Migration neu und konfigurieren Sie es im AlloyDB for PostgreSQL-Zielcluster.

  5. Erstellen Sie in Ihrem Quellcluster ein dediziertes Nutzerkonto für die Migration und gewähren Sie ihm die erforderlichen Berechtigungen:
    1. Stellen Sie mit einem Administratorkonto eine Verbindung zum Quellcluster her, erstellen Sie den Nutzer und weisen Sie die von AWS verwaltete Rolle rds_replication zu: 
      CREATE USER MIGRATION_USER_ACCOUNT_NAME WITH PASSWORD 'PASSWORD';
GRANT rds_replication TO "MIGRATION_USER_ACCOUNT_NAME";
    2. Gewähren Sie dem Migrationsnutzerkonto die erforderlichen Berechtigungen für die Standarddatenbank postgres sowie für jede Datenbank, die Sie migrieren möchten. Führen Sie die folgenden Befehle in jeder Datenbank für jedes Schema aus, mit Ausnahme des Informationsschemas und der Schemas, die mit pg_ beginnen: 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. Installieren Sie die Erweiterung pglogical in jeder Datenbank, die Sie migrieren möchten, mit Ausnahme von template0, template1 und rdsadmin: 
    CREATE EXTENSION IF NOT EXISTS pglogical;
  7. Prüfen Sie, ob Ihre Tabellen Primärschlüssel haben. Für kontinuierliche Migrationen erfordert die logische PostgreSQL-Replikation, dass Tabellen Primärschlüssel haben, um UPDATE- und DELETE-Vorgänge während der Change Data Capture-Phase (CDC) zu replizieren:
    • In Tabellen mit einem Primärschlüssel werden alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch repliziert.
    • Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service nur die Migration des ersten Snapshots und der nachfolgenden INSERT-Anweisungen während der CDC-Phase. Sie müssen die Anweisungen UPDATE und DELETE manuell migrieren.

      Wir empfehlen, Tabellen ohne Primärschlüssel vor Beginn der Migration Primärschlüssel hinzuzufügen. Informationen zum Generieren einer Abfrage zum Auflisten von Tabellen in einer PostgreSQL-Datenbank ohne Primärschlüssel oder zum manuellen Migrieren von UPDATE- und DELETE-Vorgängen finden Sie unter Debugging und andere Tools.

      Alternativ können Sie den Schnellstart-Migrationsablauf verwenden: ein vereinfachtes Migrationsszenario, bei dem Sie REPLICA IDENTITY verwenden können, um Tabellen ohne Primärschlüssel zu migrieren. Weitere Informationen finden Sie im Leitfaden Schnellstart-Migrationen verwenden.

  8. Konfigurieren Sie eine benutzerdefinierte DB-Cluster-Parametergruppe und hängen Sie sie an Ihren Cluster an:
    1. Erstellen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe und konfigurieren Sie die folgenden Parameter:
      1. Legen Sie shared_preload_libraries so fest, dass pglogical enthalten ist.
      2. Setzen Sie rds.logical_replication auf 1. Dieser Parameter aktiviert das logische WAL-Logging.
      3. Setzen Sie wal_sender_timeout auf 0. Der Wert 0 deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird.
      4. Legen Sie für max_replication_slots mindestens die Anzahl der zu migrierenden Datenbanken multipliziert mit der Anzahl der Migrationsjobs fest, zuzüglich Reserven für die Tabellensynchronisierung:

        Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und Sie 2 Migrationsjobs für diese Quelle erstellen, muss die Anzahl der Replikations-Slots mindestens 5 * 2 = 10 betragen, zuzüglich der Anzahl der Replikations-Slots, die bereits von anderen Aufgaben in der Quelle verwendet werden. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs prüfen.

        Der Standardwert für diesen Parameter ist 10.

      5. Setzen Sie max_wal_senders auf mindestens den Wert von max_replication_slots plus die Anzahl der Absender, die bereits auf Ihrer Instanz verwendet werden:

        Wenn für den Parameter max_replication_slots beispielsweise der Wert 10 festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs überprüfen.

        Der Standardwert für diesen Parameter ist 10.

      6. Legen Sie für max_worker_processes mindestens die Anzahl der zu migrierenden Datenbanken plus die vorhandenen Worker-Prozesse auf Ihrer Instanz fest. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie zwei zusätzliche Worker-Prozesse pro Verbindung berücksichtigen (bis zu maximal 20 Worker):

        Der Standardwert für diesen Parameter ist 8.

    2. Hängen Sie die Parametergruppe des DB-Clusters an den Aurora-DB-Cluster an.
  9. Starten Sie den Amazon Aurora-Datenbankcluster neu, damit die Änderungen an der Parametergruppe wirksam werden.

Cloud SQL for PostgreSQL-Quelle konfigurieren

So konfigurieren Sie eine Cloud SQL for PostgreSQL-Quellinstanz für die kontinuierliche Migration:

  1. Bei Cloud SQL for PostgreSQL-Quellen migriert Database Migration Service alle Datenbanken unter Ihrer Quellinstanz mit Ausnahme der Vorlagendatenbanken template0 und template1.
  2. Achten Sie darauf, dass die Quellinstanz die Standarddatenbank postgres enthält. Wenn diese Datenbank nicht vorhanden ist, erstellen Sie sie, bevor Sie die Migration konfigurieren.
  3. Wenn Sie von einer Cloud SQL-Quellinstanz, die mit einer privaten IP-Adresse konfiguriert ist, zu einem AlloyDB for PostgreSQL-Zielcluster migrieren, der einen IP-Adressbereich außerhalb des RFC 1918-Bereichs verwendet, fügen Sie den Bereich außerhalb des RFC 1918-Bereichs den autorisierten Netzwerken Ihrer Quellinstanz hinzu. Weitere Informationen finden Sie unter Autorisierte Netzwerke konfigurieren.
  4. Prüfen Sie die auf Ihren Quelldatenbanken installierten PostgreSQL-Erweiterungen. Der Database Migration Service migriert keine Erweiterungen, die von AlloyDB for PostgreSQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen nicht unterstützte Erweiterungen referenzieren. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

    Die Erweiterung pg_cron wird nicht automatisch vom Database Migration Service migriert, wird aber in AlloyDB for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihrer Quelldatenbank verwenden, installieren Sie es nach dem Hochstufen der Migration neu und konfigurieren Sie es im AlloyDB for PostgreSQL-Zielcluster.

  5. Erstellen Sie in Ihrer Quellinstanz ein dediziertes Nutzerkonto für die Migration und gewähren Sie ihm die erforderlichen Berechtigungen:
    1. Folgen Sie der Anleitung auf der Seite Nutzer erstellen in der Cloud SQL-Dokumentation, um das Nutzerkonto zu erstellen.
    2. Weisen Sie dem Migrationsnutzerkonto die Rolle cloudsqlsuperuser zu: 
      GRANT cloudsqlsuperuser TO "MIGRATION_USER_ACCOUNT_NAME";
    3. Gewähren Sie dem Migrationsnutzerkonto die erforderlichen Berechtigungen für die Standarddatenbank postgres sowie für jede Datenbank, die Sie migrieren möchten. Führen Sie die folgenden Befehle in jeder Datenbank für jedes Schema aus, mit Ausnahme des Informationsschemas und der Schemas, die mit pg_ beginnen: 
      GRANT USAGE ON SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT USAGE ON SCHEMA pglogical TO PUBLIC;
GRANT SELECT ON ALL TABLES IN SCHEMA pglogical TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL TABLES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
GRANT SELECT ON ALL SEQUENCES IN SCHEMA SCHEMA_NAME TO "MIGRATION_USER_ACCOUNT_NAME";
  6. Installieren Sie die Erweiterung pglogical in jeder Datenbank, die Sie migrieren möchten, mit Ausnahme von template0 und template1. Führen Sie dazu diesen Befehl aus: 
    CREATE EXTENSION IF NOT EXISTS pglogical;
  7. Prüfen Sie, ob Ihre Tabellen Primärschlüssel haben. Bei kontinuierlichen Migrationen müssen Tabellen für die logische PostgreSQL-Replikation Primärschlüssel haben, um UPDATE- und DELETE-Vorgänge während der Change Data Capture-Phase (CDC) zu replizieren:
    • In Tabellen mit einem Primärschlüssel werden alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch repliziert.
    • Bei Tabellen ohne Primärschlüssel migriert Database Migration Service den ersten Snapshot und nachfolgende INSERT-Anweisungen während der CDC-Phase. Sie müssen die Anweisungen UPDATE und DELETE manuell migrieren.

      Wir empfehlen, Tabellen ohne Primärschlüssel vor Beginn der Migration Primärschlüssel hinzuzufügen. Informationen zum Generieren einer Abfrage zum Auflisten von Tabellen in einer PostgreSQL-Datenbank ohne Primärschlüssel oder zum manuellen Migrieren von UPDATE- und DELETE-Vorgängen finden Sie unter Debugging und andere Tools.

      Alternativ können Sie den Schnellstart-Migrationsablauf verwenden: ein vereinfachtes Migrationsszenario, bei dem Sie REPLICA IDENTITY verwenden können, um Tabellen ohne Primärschlüssel zu migrieren. Weitere Informationen finden Sie im Leitfaden Schnellstart-Migrationen verwenden.

  8. Konfigurieren Sie die folgenden Datenbank-Flags auf Ihrer Cloud SQL-Quellinstanz:
    1. Setzen Sie cloudsql.logical_decoding auf on.
    2. Setzen Sie cloudsql.enable_pglogical auf on.
    3. Setzen Sie wal_sender_timeout auf 0. Der Wert 0 deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird.
    4. Legen Sie für max_replication_slots mindestens die Anzahl der zu migrierenden Datenbanken multipliziert mit der Anzahl der Migrationsjobs fest, zuzüglich Reserven für die Tabellensynchronisierung.

      Wenn die Quellinstanz beispielsweise 5 Datenbanken hat und Sie 2 Migrationsjobs für diese Quelle erstellen, muss die Anzahl der Replikations-Slots mindestens 5 * 2 = 10 betragen, zuzüglich der Anzahl der Replikations-Slots, die bereits von anderen Aufgaben in der Quelle verwendet werden. Wenn Sie angepasste Einstellungen für die Parallelität des Datendumps verwenden möchten, müssen Sie die Anzahl der Replikationsslots erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs prüfen.

      Der Standardwert für dieses Flag ist 10.

    5. Setzen Sie max_wal_senders auf mindestens den Wert von max_replication_slots plus die Anzahl der Absender, die bereits auf Ihrer Instanz verwendet werden.

      Wenn für das Flag max_replication_slots beispielsweise der Wert 10 festgelegt ist und Sie bereits zwei Absender verwenden, beträgt die Anzahl der gleichzeitig ausgeführten WAL-Senderprozesse 10 + 2 = 12. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration beim Erstellen des Migrationsjobs überprüfen.

      Der Standardwert für dieses Flag ist 10.

    6. Setzen Sie max_worker_processes auf mindestens die Anzahl der zu migrierenden Datenbanken plus die vorhandenen Worker-Prozesse auf Ihrer Instanz. Wenn Sie angepasste Einstellungen für die Parallelität von Datendumps verwenden möchten, müssen Sie zwei zusätzliche Worker-Prozesse pro Verbindung berücksichtigen (bis zu maximal 20 Worker).

      Der Standardwert für dieses Flag ist 8.

    Weitere Informationen zum Ändern von Flags finden Sie in der Cloud SQL-Dokumentation unter Datenbank-Flags konfigurieren.

  9. Starten Sie die Cloud SQL-Quellinstanz neu, damit die Änderungen am Datenbank-Flag wirksam werden.

Nächste Schritte