PostgreSQL-Quelldatenbank für kontinuierliche Migrationen konfigurieren

Auf dieser Seite wird beschrieben, wie Sie Ihre Quelldatenbankinstanzen für standardmäßige homogene PostgreSQL-Migrationen konfigurieren. 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 Abschnitte für jede unterstützte Quelle:

Selbstverwaltete PostgreSQL-Quelle konfigurieren

So konfigurieren Sie eine selbstverwaltete PostgreSQL-Quellinstanz (lokal oder auf einer Compute Engine-VM gehostet) für den Migrationsprozess:

  1. Bei selbstverwalteten 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. Konfigurieren Sie die Netzwerkclient-Authentifizierung in der Datei pg_hba.conf. Fügen Sie Einträge hinzu, die Replikationsverbindungen und Datenbankzugriff von der ausgehenden IP-Adresse, dem VPC-CIDR-Bereich oder dem Reverse-SSH-Bastion-Host der Cloud SQL-Zielinstanz 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 PostgreSQL-Erweiterungen, die in Ihren Quelldatenbanken installiert sind. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen auf nicht unterstützte Erweiterungen verweisen. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

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

  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 den folgenden Befehl 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:
    • Tabellen mit einem Primärschlüssel replizieren alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch.
    • 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 Paket pglogical 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 prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen. 

        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 des Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen. 

        ALTER SYSTEM SET max_wal_senders = MAX_WAL_SENDERS;

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

      6. Setzen Sie max_worker_processes auf mindestens die Anzahl der zu migrierenden Datenbanken plus die Anzahl der vorhandenen Worker-Prozesse auf Ihrer Instanz. Wenn Sie angepasste Einstellungen für die Parallelität des Daten-Dumps 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 den Migrationsprozess:

  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 an Port 5432 von der ausgehenden IP-Adresse der Cloud SQL-Zieldatenbank, dem VPC-CIDR-Bereich oder der Reverse-SSH-Bastion-Host-VM zu.
  4. Prüfen Sie die PostgreSQL-Erweiterungen, die in Ihren Quelldatenbanken installiert sind. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen auf nicht unterstützte Erweiterungen verweisen. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

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

  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ür PostgreSQL-Version 9.4: Führen Sie den folgenden Befehl 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;

    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:
    • Tabellen mit einem Primärschlüssel replizieren alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch.
    • 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. 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. Weitere Informationen finden Sie unter 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 prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

        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 des Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

        Der Standardwert für diesen Parameter ist 10.

      6. Setzen Sie max_worker_processes auf mindestens die Anzahl der zu migrierenden Datenbanken plus die Anzahl der vorhandenen Worker-Prozesse auf Ihrer Instanz. Wenn Sie angepasste Einstellungen für die Parallelität des Daten-Dumps 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.
  10. Starten Sie die Amazon RDS-Instanz neu, damit die Änderungen an der Parametergruppe wirksam werden.

Amazon Aurora for PostgreSQL-Quelle konfigurieren

So konfigurieren Sie einen Amazon Aurora PostgreSQL-Quellcluster für den Migrationsprozess:

  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 Ihr 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 an Port 5432 von der ausgehenden IP-Adresse der Cloud SQL-Zieldatenbank, dem VPC-CIDR-Bereich oder der Reverse-SSH-Bastion-Host-VM zu.
  4. Prüfen Sie die PostgreSQL-Erweiterungen, die in Ihren Quelldatenbanken installiert sind. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen auf nicht unterstützte Erweiterungen verweisen. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

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

  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:
    • Tabellen mit einem Primärschlüssel replizieren alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch.
    • 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. Mit diesem Parameter wird das logische WAL-Logging aktiviert.
      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 sein, 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 prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

        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 des Datendumps verwenden möchten, müssen Sie die Anzahl der Absender erhöhen und Ihre Konfiguration prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

        Der Standardwert für diesen Parameter ist 10.

      6. Setzen Sie max_worker_processes auf mindestens die Anzahl der zu migrierenden Datenbanken plus die Anzahl der vorhandenen Worker-Prozesse auf Ihrer Instanz. Wenn Sie angepasste Einstellungen für die Parallelität des Daten-Dumps 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-DB-Cluster neu, damit die Änderungen an der Parametergruppe wirksam werden.

Microsoft Azure Database for PostgreSQL Flexible Server-Quelle konfigurieren

So konfigurieren Sie eine Microsoft Azure Database for PostgreSQL Flexible Server-Quellinstanz für den Migrationsprozess:

  1. Bei Microsoft Azure Database for PostgreSQL Flexible Server-Quellen migriert der Database Migration Service alle Datenbanken unter Ihrer Quellinstanz mit Ausnahme der Azure-System- und Vorlagendatenbanken: azure_maintenance, azure_sys, 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 Azure-Firewall- und SSL/TLS-Einstellungen:
    1. Fügen Sie in den Azure-Netzwerkeinstellungen Firewallregeln hinzu, die eingehende TCP-Verbindungen auf Port 5432 von der ausgehenden IP-Adresse des Cloud SQL-Ziels, dem VPC-CIDR-Bereich oder der Bastion-Host-VM für Reverse-SSH zulassen.
    2. Prüfe den Wert des Serverparameters require_secure_transport. Standardmäßig erfordern Azure-Datenbanken eine SSL/TLS-Verschlüsselung für eingehende Verbindungen. Wählen Sie je nach Einstellung für require_secure_transport eine der folgenden Verschlüsselungseinstellungen aus, wenn Sie das Quellverbindungsprofil erstellen:
      • Wenn require_secure_transport auf on gesetzt ist, wählen Sie Basic, TLS oder mTLS aus.
      • Wenn require_secure_transport auf off gesetzt ist, wählen Sie Keine aus.
  4. Prüfen Sie die PostgreSQL-Erweiterungen, die in Ihren Quelldatenbanken installiert sind. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen auf nicht unterstützte Erweiterungen verweisen. Entfernen Sie nicht unterstützte Erweiterungen und Verweise aus Ihren Quelldatenbanken, bevor Sie fortfahren.

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

  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 azure_maintenance, azure_sys, template0 und template1:
    • Für PostgreSQL-Version 9.4: Führen Sie den folgenden Befehl 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:
    • Tabellen mit einem Primärschlüssel replizieren alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch.
    • 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. Konfigurieren Sie die folgenden Serverparameter in Azure. Weitere Informationen finden Sie unter Serverparameter in Azure Database for PostgreSQL konfigurieren.
    1. Legen Sie shared_preload_libraries so fest, dass pglogical enthalten ist.
    2. Legen Sie azure.extensions so fest, dass pglogical enthalten ist.
    3. Setzen Sie wal_level auf logical.
    4. Setzen Sie wal_sender_timeout auf 0. Der Wert 0 deaktiviert das Zeitlimit, das zum Beenden inaktiver Replikationsverbindungen verwendet wird.
    5. 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 prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

      Der Standardwert für diesen Parameter ist 10.

    6. 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 des Datendumps verwenden möchten, müssen Sie die Anzahl der Sender erhöhen und Ihre Konfiguration überprüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

      Der Standardwert für diesen Parameter ist 10.

    7. 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 des 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.

    Weitere Informationen zu den Parametern finden Sie in der Liste aller Serverparameter in Azure Database for PostgreSQL in der Microsoft-Dokumentation.

  10. Starten Sie die Microsoft Azure Database for PostgreSQL Flexible Server-Instanz neu, damit die Änderungen der Serverparameter wirksam werden.

Cloud SQL for PostgreSQL-Quelle konfigurieren

So konfigurieren Sie eine Cloud SQL for PostgreSQL-Quellinstanz für den Migrationsprozess:

  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 einer Cloud SQL-Zielinstanz migrieren, die 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 PostgreSQL-Erweiterungen, die in Ihren Quelldatenbanken installiert sind. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Prüfen Sie, ob Ihre Quelldatenbankobjekte und Anwendungsabfragen nicht auf nicht unterstützte Erweiterungen verweisen. 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 Cloud SQL for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihrer Quelldatenbank verwenden, installieren Sie es nach dem Hochstufen der Migration auf der Zielinstanz neu und konfigurieren Sie es.

  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.
    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 den folgenden Befehl 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 Replikation von PostgreSQL, dass Tabellen Primärschlüssel haben, um UPDATE- und DELETE-Vorgänge während der Change Data Capture-Phase (CDC) zu replizieren:
    • Tabellen mit einem Primärschlüssel replizieren alle INSERT-, UPDATE- und DELETE-Vorgänge automatisch.
    • 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. 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. 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 prüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

      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 des Datendumps verwenden möchten, müssen Sie die Anzahl der Sender erhöhen und Ihre Konfiguration überprüfen, indem Sie beim Erstellen des Migrationsjobs den Migrationsjobtest ausführen.

      Der Standardwert für dieses Flag 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 dieses Flag ist 8.

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

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

Nächste Schritte