Bekannte Einschränkungen

Bevor Sie Ihre Datenbanken zu Cloud SQL migrieren, sollten Sie sich über die bekannten Einschränkungen für dieses Migrationsszenario informieren.

Zu den bekannten Einschränkungen bei der Verwendung einer PostgreSQL-Datenbank als Quelle gehören:

  • Die Erweiterung pglogical unterstützt die Replikation von generierten Spalten für PostgreSQL 12 und höher nicht.

  • Änderungen an Tabellenstrukturen (DDL) werden nicht über Standard-DDL-Befehle repliziert, sondern nur mit Befehlen, die mit der für die Replikation verwendeten pglogical-Erweiterung ausgeführt werden. Dazu gehören Änderungen an enum-Typen.

    • pglogical bietet beispielsweise die Funktion pglogical.replicate_ddl_command, mit der DDL sowohl in der Quelldatenbank als auch im Replikat zu einem konsistenten Zeitpunkt ausgeführt werden kann.
    • Wenn Sie Daten für neu erstellte Tabellen replizieren möchten, müssen Sie den Befehl pglogical.replication_set_add_table verwenden, um neue Tabellen zu vorhandenen Replikationssätzen hinzuzufügen.
    • Weitere Informationen zur DDL-Replikation während der Migration finden Sie unter Genauigkeit der Migration.

  • Bei Tabellen ohne Primärschlüssel unterstützt Database Migration Service die Migration des ersten Snapshots und der INSERT-Anweisungen während der CDC-Phase (Change Data Capture). Die Migration von UPDATE- und DELETE-Anweisungen unterscheidet sich für:

    • Standardmigrationen: UPDATE- und DELETE-Anweisungen werden für Tabellen ohne Primärschlüssel nicht migriert. Sie müssen vor der Migration Primärschlüssel für Ihre Spalten hinzufügen oder UPDATE- und DELETE-Anweisungen manuell migrieren.
    • Schnellstart-Migrationen: Bei Schnellstart-Migrationen sind keine Primärschlüssel erforderlich, um UPDATE- und DELETE-Vorgänge zu replizieren, wenn Sie die Replikatidentität auf INDEX oder FULL festlegen. Durch die Konfiguration von REPLICA IDENTITY FULL erhöht sich das WAL-Volumen (Write-Ahead Log) und der Ressourcenaufwand. Es wird empfohlen, nach Möglichkeit einen Primärschlüssel hinzuzufügen. Weitere Informationen finden Sie in der PostgreSQL-Dokumentation zur Replikatidentität und in der Kurzanleitung für Migrationen.

  • Der Database Migration Service migriert keine Daten aus materialisierten Ansichten, sondern nur das Ansichtsschema. Führen Sie den folgenden Befehl aus, um die Ansichten in der Zieldatenbank zu füllen: REFRESH MATERIALIZED VIEW view_name.

  • Die SEQUENCE-Status (z. B. last_value) am Ziel können während der laufenden CDC von der Quelle abweichen. Sequenzwerte werden während des letzten Hochstufungsschritts synchronisiert.

  • UNLOGGED- und TEMPORARY-Tabellen werden nicht repliziert und können nicht repliziert werden.

  • Der Datentyp „Large Object“ (oid, der auf pg_largeobject verweist) wird von der logischen Decodierung von PostgreSQL nicht unterstützt.

  • Es können nur Erweiterungen migriert werden, die von Cloud SQL for PostgreSQL unterstützt werden. Der Database Migration Service migriert keine Erweiterungen, die von Cloud SQL nicht unterstützt werden. Das Vorhandensein dieser Erweiterungen blockiert die Migration nicht. Um jedoch eine reibungslose Migration zu gewährleisten, sollten Sie prüfen, ob Ihre Anwendungen nicht unterstützte Erweiterungen referenzieren. Eine Liste der unterstützten Erweiterungen finden Sie in der Cloud SQL-Dokumentation unter PostgreSQL-Erweiterungen.

  • Die Erweiterung pg_cron (oder alle in der Erweiterung konfigurierten Cronjobs) wird nicht vom Database Migration Service migriert, wird aber in Cloud SQL for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihren Quelldatenbanken verwenden, installieren Sie die Erweiterung neu und konfigurieren Sie Ihre Cronjobs auf der Zielinstanz, nachdem die Migration abgeschlossen ist.

  • Database Migration Service unterstützt nicht die Migration von Lesereplikaten, die sich im Wiederherstellungsmodus befinden.

  • Database Migration Service unterstützt keine Amazon RDS-Quellen, auf die das AWS SCT-Erweiterungspaket angewendet wird.

  • In C geschriebene benutzerdefinierte Funktionen können nicht migriert werden, mit Ausnahme von Funktionen, die beim Erstellen von Erweiterungen installiert werden, die von Cloud SQL unterstützt werden.

  • Wenn in der Quelldatenbank andere Erweiterungen vorhanden sind und deren Versionen von Cloud SQL nicht unterstützt werden, schlägt das Testen oder Starten des Migrationsjobs fehl.

  • Datenbanken, die der Quellinstanz nach dem Start des Migrationsjobs hinzugefügt werden, werden nicht migriert.

  • Sie können bestimmte Datenbanken auswählen, wenn Sie mit Database Migration Service migrieren. Alle Tabellen und Schemas aus den ausgewählten Datenbanken werden migriert, mit Ausnahme von:

    • Das Informationsschema (information_schema).
    • Alle Schemas, die mit pg_ beginnen (z. B. pg_catalog, pg_toast, pgtemp*). Eine vollständige Liste der PostgreSQL-Kataloge, die mit pg_ beginnen, finden Sie in der PostgreSQL-Dokumentation unter PostgreSQL-Systemkataloge.
    • Anmeldedaten und Rollen von Nutzern.

  • Wenn für verschlüsselte Datenbanken kundenverwaltete Verschlüsselungsschlüssel (CMEK) zum Entschlüsseln von Daten erforderlich sind und Database Migration Service keinen Zugriff auf die Schlüssel hat, können die Datenbanken nicht migriert werden. Daten, die mit der Erweiterung pgcrypto verschlüsselt wurden, können jedoch migriert werden, da Cloud SQL pgcrypto unterstützt. Database Migration Service unterstützt auch die Migration von verschlüsselten Amazon Aurora- oder Amazon RDS-Datenbanken, da AWS die Entschlüsselung transparent verarbeitet. Weitere Informationen finden Sie unter Amazon Aurora-Ressourcen verschlüsseln und Amazon RDS-Ressourcen verschlüsseln.

  • Betriebsverhalten der Zieldatenbank während der Migration:

    • Beschreibbare Zieldatenbank: Cloud SQL for PostgreSQL führt die Zieldatenbank während der Migration nicht im Lesemodus aus. Die Zielinstanz wird nicht herabgestuft, wenn sie von Database Migration Service erstellt wird.

    • Vermeiden Sie Schreibvorgänge für migrierte Daten: Führen Sie keine Schreibvorgänge (z. B. INSERT, UPDATE, DELETE oder DDL-Schemaänderungen) für Tabellen oder Datenbanken aus, die an der Migration beteiligt sind. Das Ausführen von Schreibvorgängen für migrierte Daten kann zu Replikationskonflikten mit dem eingehenden Change Data Capture-Stream (CDC) führen.

    • Datenbanknutzer verwalten: Sie können Datenbanknutzer jederzeit mit standardmäßigen psql-Befehlen oder über Cloud SQL in der Google Cloud Console erstellen und verwalten. Weitere Informationen finden Sie in der Cloud SQL-Dokumentation unter Nutzer verwalten.

    • Ausgesetzte Funktionen: Automatische Sicherungen und die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) werden während der kontinuierlichen Replikation ausgesetzt. Außerdem können Sie erst dann Cloud SQL-Lesereplikate aus der Zielinstanz erstellen, wenn der Migrationsjob hochgestuft wurde.

  • Das Triggerverhalten hängt von der Triggerkonfiguration ab. Standardmäßig werden Trigger während der Replikation nicht auf dem Replikat ausgelöst, es sei denn, sie sind mit ALTER EVENT TRIGGER oder ALTER TABLE ... ENABLE ALWAYS TRIGGER konfiguriert.

  • Mit SECURITY DEFINER definierte Funktionen werden von cloudsqlexternalsync in der Cloud SQL-Zielinstanz erstellt, die über erhöhte Berechtigungen verfügt. Schränken Sie die Ausführungsberechtigungen für sensible SECURITY DEFINER-Funktionen ein, indem Sie öffentliche Berechtigungen widerrufen und den Zugriff selektiv gewähren.

  • Cloud SQL unterstützt keine benutzerdefinierten Tablespaces. Alle Objekte in benutzerdefinierten Tablespaces werden zum Standard-Tablespace pg_default in Cloud SQL migriert.

  • Die Verbindungsmethode für Private Service Connect-Schnittstellen wird nur für die Migration zu vorhandenen Zielinstanzen unterstützt. Wenn Sie eine Verbindung über eine private IP-Adresse verwenden und zu einer neuen Zielinstanz migrieren möchten, verwenden Sie VPC-Peering.

Einschränkungen für Migrationen zu vorhandenen Zielinstanzen

  • Herabstufung der Zielinstanz für Standardmigrationen: Bei Standardmigrationen zu vorhandenen Cloud SQL-Instanzen stuft Database Migration Service die eigenständige Instanz herab, um sie als externes Replikat der Quelldatenbank zu konfigurieren.
    • Durch das Herabstufen der Instanz wird die PostgreSQL-Engine nicht in den Lesemodus versetzt. Sie müssen jedoch Schreibvorgänge für migrierte Tabellen vermeiden, um Replikationskonflikte zu verhindern.
    • Durch das Herabstufen der Instanz werden automatische Sicherungen und die Wiederherstellung zu einem bestimmten Zeitpunkt (Point-in-Time Recovery, PITR) ausgesetzt. Außerdem können bis zum Hochstufen keine Cloud SQL-Lesereplikate hinzugefügt werden.
    • Sie müssen die Herabstufung beim Erstellen des Migrationsjobs in der Google Cloud Console bestätigen, indem Sie die ID der Zielinstanz eingeben (oder gcloud database-migration migration-jobs demote-destination ausführen).
    • Schnellstartmigrationen verwenden die logische Replikation von PostgreSQL pgnative und erfordern keine Herabstufung der Zielinstanz.
  • Ihre vorhandene Zielinstanz darf nur Standardsystemdatenbanken enthalten, die beim Erstellen der Zielinstanz automatisch eingerichtet werden. Die Migration zu vorhandenen Zielinstanzen, die Nutzerdaten enthalten, wird nicht unterstützt.

    Wenn Probleme aufgrund zusätzlicher Daten in Ihrer vorhandenen Zielinstanz auftreten, löschen Sie die Datenbanken in Ihrer Zielinstanz und versuchen Sie es noch einmal mit dem Migrationsjob. Weitere Informationen finden Sie unter Zusätzliche Daten aus der vorhandenen Zielinstanz löschen.

  • Sie können nur einen Migrationsjob pro Zielinstanz konfigurieren.
  • Sie können nur zu eigenständigen Cloud SQL-Instanzen migrieren. Die Migration zu externen Serverreplikaten wird nicht unterstützt.
  • Nachdem Sie eine Instanz hochgestuft haben, müssen Sie die Wiederherstellung zu einem bestimmten Zeitpunkt aktivieren.
  • Wenn Ihre Instanz benutzerdefinierte Sicherungseinstellungen hat (z. B. einen benutzerdefinierten Sicherungsspeicherort), müssen Sie die Sicherungseinstellungen nach dem Hochstufen noch einmal wiederherstellen. Während des Hochstufungsprozesses setzt Cloud SQL die Sicherungseinstellungen auf die Standardwerte zurück.
  • Für Terraform-Nutzer: Database Migration Service ändert die Sicherungs- und Wiederherstellungseinstellungen Ihrer Zielinstanz. Dies kann dazu führen, dass die Einstellungen der Zielinstanz von der Terraform-Konfiguration abweichen, die für die Bereitstellung verwendet wurde. Wenn dieses Problem auftritt, lesen Sie die Anleitung unter Probleme diagnostizieren.

Kontingente

  • Es können immer bis zu 2.000 Verbindungsprofile und 1.000 Migrationsjobs gleichzeitig vorhanden sein. Wenn Sie mehr Platz benötigen, löschen Sie nicht verwendete Migrationsjobs und Verbindungsprofile.

Kompatibilität von PostgreSQL-Erweiterungsversionen bei Hauptversionsupgrades

Wenn Sie zu einer höheren PostgreSQL-Hauptversion migrieren, verwendet der Database Migration Service das Dienstprogramm pg_restore, das die Standarderweiterungsversion der PostgreSQL-Zielhauptversion installiert. Sie können für das pg_restore-Dienstprogramm keine genaue Erweiterungsversion angeben.

Wenn Ihre Quelldatenbank eine Erweiterungsversion verwendet, die schemainkompatibel mit der Standardversion ist, die auf der PostgreSQL-Hauptversion des Ziels installiert ist, kann die Migration aufgrund eines Schema-Konflikts oder interner Fehler fehlschlagen.

Prüfen Sie die Schemakompatibilität, um Migrationsfehler zu vermeiden. Aktualisieren Sie vor der Migration die Erweiterungen in Ihrer Quelldatenbank auf eine Version, die mit der PostgreSQL-Hauptversion des Ziels kompatibel ist.