Bekannte Einschränkungen

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

Hinweis: Sie können auch das Google Cloud Migration Center verwenden, um Lücken in der Funktionsunterstützung zu finden. Weitere Informationen finden Sie in der Migration Center-Dokumentation unter Datenbanken erkennen und importieren.

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. Wenn Sie REPLICA IDENTITY FULL konfigurieren, 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 im Schnellstart-Migrationsleitfaden.

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

• Die Tabellen UNLOGGED und TEMPORARY 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 auf nicht unterstützte Erweiterungen verweisen. 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.

• Der Database Migration Service unterstützt keine 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.

  • Schreibvorgänge für migrierende Daten vermeiden: 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.

• Die Datenbankauthentifizierung über Identity and Access Management für Zielinstanzen oder -cluster wird nicht unterstützt. Database Migration Service stellt über die Datenbanknutzerauthentifizierung eine Verbindung zur Zieldatenbank her. Weitere Informationen zu IAM finden Sie in der Cloud SQL-Dokumentation unter IAM-Authentifizierung.

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 schreibgeschützten Modus 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 Platz für weitere benötigen, löschen Sie nicht verwendete Migrationsjobs und Verbindungsprofile.

Überlegungen zur Datendump-Parallelität

Wenn Sie einen Migrationsjob erstellen, können Sie die Anzahl der parallelen Abos erhöhen, um den ersten Datendump und die laufende CDC-Replikation (Change Data Capture) zu beschleunigen. Wenn Sie höhere Einstellungen für die Parallelität von Datendumps verwenden, erhöht sich auch die Verbindungs- und Ressourcenauslastung sowohl in der Quelldatenbank als auch in der Cloud SQL-Zielinstanz.

• Achten Sie darauf, dass Ihre Quelldatenbank über ausreichend CPU, Arbeitsspeicher und E/A-Kapazität verfügt, bevor Sie die maximale Parallelität verwenden.
• Wenn Sie die angepasste Parallelität für Datendumps verwenden, müssen Sie für max_replication_slots, max_wal_senders und max_worker_processes in Ihrer Quelldatenbank höhere Werte konfigurieren. Eine detaillierte Parameterberechnung finden Sie unter Quelldatenbank konfigurieren.
• Die Erweiterung pglogical repliziert Daten während des ersten vollständigen Dumps auf Tabellenebene. Eine einzelne nicht partitionierte Tabelle wird einem Abo zugewiesen und nicht auf mehrere parallele Abos oder Worker-Threads aufgeteilt.
• Die Erweiterung pglogical repliziert einzelne Blattpartitionen als separate Tabellen und kann während des ersten vollständigen Dumps mehrere Blattpartitionen auf parallele Abos verteilen. Eine einzelne große Blattpartition kann nicht auf mehrere Abos aufgeteilt werden und wird von einem einzelnen Thread kopiert.
• Database Migration Service sortiert Tabellen nach Größe und fügt nur dann parallele Abos hinzu, wenn das Gesamtvolumen des größten Abos reduziert werden kann. Database Migration Service erstellt bis zu 2 Abos pro Datenbank für optimale Parallelität und bis zu 4 Abos pro Datenbank für maximale Parallelität. Diese werden nach Datenbankgröße aus einem Zielpool von 10 Abos über alle Datenbanken hinweg aufgeteilt (mit mindestens 1 Abo pro migrierter Datenbank). Wenn eine Datenbank stark ungleiche Tabellengrößen hat, weist der Database Migration Service weniger Abos als die maximale Obergrenze zu. Wenn eine Datenbank beispielsweise eine 1-TB-Tabelle und mehrere kleine Tabellen enthält, isoliert der Database Migration Service die 1-TB-Tabelle in einem Abo und gruppiert die kleineren Tabellen in einem zweiten Abo. In diesem Szenario verwendet der Database Migration Service nur zwei Abos, auch wenn die Parallelität auf Maximum festgelegt ist.
• Database Migration Service weist Tabellen ohne Primärschlüssel dedizierten Replikationssätzen nur für Einfügungen zu (einen pro parallelem Abo). Mehrere Tabellen ohne Primärschlüssel können auf parallele Abos verteilt werden. Während des ersten vollständigen Dumps wird jedoch jede einzelne Tabelle als einzelner Tabellenstream innerhalb eines Abos kopiert und nicht auf mehrere parallele Threads aufgeteilt.

Kompatibilität der PostgreSQL-Erweiterungsversion 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 Dienstprogramm pg_restore keine genaue Erweiterungsversion angeben.

Wenn Ihre Quelldatenbank eine Erweiterungsversion verwendet, die mit der Standardversion, die auf der PostgreSQL-Hauptversion des Ziels installiert ist, nicht schemakompatibel ist, kann die Migration aufgrund einer Schemaabweichung 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.