Bekannte Einschränkungen

Bevor Sie Ihre Datenbanken zu AlloyDB for PostgreSQL migrieren, sollten Sie die bekannten Einschränkungen für dieses Migrationsszenario berücksichtigen.

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. Der Nutzer, der diesen Befehl auf der Quelle ausführt, muss bereits auf dem Replikat vorhanden sein.
    • 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.

  • Objektbeschränkungen:

    • Fremde Tabellen werden nicht durch logische Replikation repliziert.
    • 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.
    • 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.

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

  • Es können nur Erweiterungen und Erweiterungsversionen migriert werden, die AlloyDB for PostgreSQL für PostgreSQL unterstützt. Der Database Migration Service migriert keine Erweiterungen, die von AlloyDB for PostgreSQL nicht unterstützt werden. Wenn in der Quelldatenbank Erweiterungen vorhanden sind, deren Versionen von AlloyDB for PostgreSQL nicht unterstützt werden, kann das Testen oder Starten des Migrationsjobs fehlschlagen. Prüfen Sie, ob Ihre Quellerweiterungen unterstützt werden und Ihre Anwendungen nicht auf nicht unterstützte Erweiterungen verweisen, um eine reibungslose Migration zu gewährleisten. Eine Liste der unterstützten Erweiterungen finden Sie in der AlloyDB for PostgreSQL-Dokumentation unter Unterstützte Erweiterungen.

  • Die Erweiterung pg_cron (oder alle in der Erweiterung konfigurierten Cronjobs) wird nicht vom Database Migration Service migriert, wird aber in AlloyDB for PostgreSQL-Zielen unterstützt. Wenn Sie pg_cron in Ihren Quelldatenbanken verwenden, installieren Sie die Erweiterung neu und konfigurieren Sie Ihre Cronjobs im Zielcluster, 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 AlloyDB for PostgreSQL unterstützt werden.

  • 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 AlloyDB for PostgreSQL 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.

  • Migrierende Datenbanken sind während der Migration nicht schreibgeschützt: AlloyDB for PostgreSQL führt die Zielinstanz während der Migration nicht im Lesemodus aus. Sie können zwar eine Verbindung zum Zielcluster herstellen, um Datenbanknutzer zu erstellen und zu verwalten oder erforderliche Schemaänderungen (DDL) anzuwenden, aber führen Sie keine Schreibvorgänge (z. B. INSERT, UPDATE oder DELETE) für Datenbanken oder Tabellen aus, die migriert werden. Das Schreiben in migrierende Daten kann zu Replikationskonflikten oder Migrationsfehlern führen.

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

  • Benutzerdefinierte Tablespaces werden dem Standard-Tablespace pg_default in AlloyDB for PostgreSQL zugeordnet.

  • Die Verbindungsmethode für Private Service Connect-Schnittstellen wird nur für die Migration zu vorhandenen Zielclustern unterstützt. Wenn Sie eine private IP-Verbindung verwenden und im Rahmen einer Standardmigration zu einem neuen Zielcluster migrieren möchten, verwenden Sie VPC-Peering.

  • Die Identity and Access Management-Datenbankauthentifizierung für Zielcluster wird nicht unterstützt. Database Migration Service stellt über die Datenbanknutzerauthentifizierung eine Verbindung zur Zieldatenbank her. Weitere Informationen zu IAM finden Sie in der AlloyDB for PostgreSQL-Dokumentation unter IAM-Authentifizierung verwalten.

Security Definer-Funktionen

Funktionen, die mit SECURITY DEFINER definiert sind, werden mit den Berechtigungen des Nutzers ausgeführt, dem die Funktion gehört, und nicht mit den Berechtigungen des Nutzers, der sie ausführt.

Während der kontinuierlichen Migration zu AlloyDB for PostgreSQL werden Routinen, die mit SECURITY DEFINER definiert wurden, dem internen Migrationsdienstnutzer alloydbexternalsync auf der primären Zielinstanz zugewiesen. Da alloydbexternalsync über erweiterte Administratorberechtigungen verfügt, einschließlich der Rollen alloydbsuperuser und alloydbreplica, werden diese Funktionen von allen Nutzern, die zur Ausführung dieser Funktionen berechtigt sind, mit vollen alloydbsuperuser-Rechten ausgeführt. Dies führt zu einem unbeabsichtigten Risiko der Rechteausweitung.

Um dieses Risiko zu minimieren, prüfen Sie alle SECURITY DEFINER-Funktionen in Ihrem Zielcluster und widerrufen Sie die öffentlichen Ausführungsberechtigungen sofort nach der Migration:

REVOKE EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) FROM PUBLIC;
GRANT EXECUTE ON FUNCTION SCHEMA_NAME.FUNCTION_NAME(ARGUMENT_TYPES) TO "AUTHORIZED_USER";

Sortierung und Gebietsschemaausrichtung

AlloyDB for PostgreSQL verwendet standardmäßig die von libc bereitgestellten Sprachen C.UTF-8 und en_US.utf8. Alle anderen Locales in AlloyDB for PostgreSQL verwenden ICU-Sortierungen (International Components for Unicode).

Wenn Ihre Quelldatenbank eine Standardsortierung basierend auf einem anderen libc-Gebietsschema verwendet, wird dieser Standard nicht automatisch übernommen. Damit Abfragen mit ORDER BY einheitlich sortiert werden, müssen Sie Ihre Tabellen nach der Migration möglicherweise mit expliziten ICU-Sortierungen aktualisieren. Weitere Informationen finden Sie in der AlloyDB for PostgreSQL-Dokumentation unter Unterstützte Sprachen für importierte Daten.

Einschränkungen für Migrationen zu vorhandenen Zielclustern

  • Sie können nur einen aktiven Migrationsjob pro Zielcluster konfigurieren.
  • Herabstufung des Zielclusters für Standardmigrationen: Bei Standardmigrationen zu vorhandenen AlloyDB for PostgreSQL-Clustern stuft Database Migration Service den eigenständigen Cluster herab, um ihn als externes Replikat der Quelldatenbank zu konfigurieren.
    • Sie müssen die Herabstufung beim Erstellen des Migrationsjobs in der Google Cloud -Console bestätigen, indem Sie die ID des Zielclusters eingeben (oder gcloud database-migration migration-jobs demote-destination ausführen).
    • Bei Schnellstart-Migrationen wird die logische Replikation von PostgreSQL pgnative verwendet. Eine Herabstufung des Zielclusters ist nicht erforderlich und wird nicht durchgeführt.
  • Bei Standardmigrationen muss der vorhandene Zielcluster leer sein oder nur Standarddaten zur Systemkonfiguration enthalten. Die Migration zu einem vorhandenen Zielcluster, der Nutzerdaten (z. B. Tabellen) enthält, wird für Standardmigrationen nicht unterstützt.

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

  • Die Migration zu Clustern mit Lesepoolinstanzen wird unterstützt. Weitere Informationen zu AlloyDB for PostgreSQL-Clustern und -Instanzen finden Sie unter AlloyDB for PostgreSQL – Übersicht.

Ü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 Ihrer Quelldatenbank als auch in Ihrem AlloyDB for PostgreSQL-Zielcluster.

  • 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 verteilt sie auf parallele Abos. Database Migration Service erstellt bis zu 2 Abos pro Datenbank (und insgesamt bis zu 2 Abos für alle Datenbanken) für die optimale Parallelität und bis zu 4 Abos pro Datenbank (und insgesamt bis zu 4 Abos für alle Datenbanken) für die maximale Parallelität, wobei mindestens 1 Abo pro migrierter Datenbank erstellt wird. Wenn eine Datenbank beispielsweise eine 1-TB-Tabelle und mehrere kleine Tabellen enthält, isoliert Database Migration Service die 1-TB-Tabelle in einem Abo und verteilt die kleineren Tabellen auf die verbleibenden Abos. Auch wenn mehrere Abos aktiv sind, wird die Gesamtgeschwindigkeit des ersten Dumps immer noch durch die Zeit begrenzt, die zum Kopieren der einzelnen 1-TB-Tabelle erforderlich 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.

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. Weitere Informationen finden Sie unter Kontingente und Limits.

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.

Nächste Schritte