FAQs zum Database Migration Service for PostgreSQL

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

• Was ist der Datenbank-Migrationsdienst?
• Welche Quellen werden unterstützt?
• Welche Ziele werden unterstützt?
• Gibt es eine versionsübergreifende Unterstützung?
• Welche Daten-, Schema- und Metadatenkomponenten werden migriert?
• Welche Änderungen werden während der kontinuierlichen Migration repliziert?
• Was wird nicht migriert?
• Welche Netzwerkmethoden werden verwendet?
• Welche bekannten Einschränkungen gibt es?

Was ist der Database Migration Service?

Database Migration Service ist ein Dienst, mit dem Sie Ihre Daten einfacher zu Google Cloudmigrieren können. Mit dem Database Migration Service können Sie Ihre PostgreSQL-Arbeitslasten zu Cloud SQL migrieren.

Welche Quellen werden unterstützt?

• Amazon RDS 9.6.10+, 10.5+, 11.1+, 12, 13, 14, 15, 16, 17
• Amazon Aurora 10.11 und höher, 11.6 und höher, 12.4 und höher sowie 13.3 und höher, 14.6 und höher, 15.2 und höher, 16 und 17
• Selbstverwaltetes PostgreSQL (lokal oder auf einer beliebigen von Ihnen verwalteten Cloud-VM) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
• Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17
• Microsoft Azure Database for PostgreSQL Flexible Server: 11 oder höher

Welche Ziele werden unterstützt?

• Cloud SQL for PostgreSQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Ist die Versionsunterstützung geräteübergreifend?

Der Database Migration Service unterstützt Migrationen von PostgreSQL zu Cloud SQL für alle Hauptversionen, bei denen die Zielversion der Quelldatenbank entspricht oder höher ist.

Welche Daten-, Schema- und Metadatenkomponenten werden migriert?

Der Database Migration Service migriert Schema, Daten und Metadaten von der Quelle zum Ziel. Im Rahmen der Datenbankmigration werden alle folgenden Daten-, Schema- und Metadatenkomponenten migriert:

Datenmigration

• Alle Schemas und alle Tabellen aus der ausgewählten Datenbank.

Schemamigration

• Benennung
• Primärschlüssel
• Datentyp
• Ordinale Position
• Standardwert
• Null-Zulässigkeit
• Attribute mit automatischer Inkrementenfolge
• Sekundäre Indexe

Metadatenmigration

• Gespeicherte Prozeduren
• Funktionen
• Trigger
• Aufrufe
• Einschränkungen für Fremdschlüssel

Welche Änderungen werden während der kontinuierlichen Migration repliziert?

Nur DML-Änderungen werden während der Migration automatisch aktualisiert. Die Verwaltung der DDL so, dass die Quell- und Zieldatenbanken kompatibel bleiben, liegt in der Verantwortung des Nutzers. Dies kann auf zwei Arten erfolgen:

1. Beenden Sie Schreibvorgänge in die Quelle und führen Sie die DDL-Befehle in der Quelle und dem Ziel aus. Gewähren Sie dem Cloud SQL-Nutzer, der die DDL-Änderungen anwendet, die Rolle cloudsqlexternalsync, bevor die DDL-Befehle für das Ziel ausgeführt werden. Gewähren Sie den entsprechenden Cloud SQL-Nutzern die Rolle cloudsqlexternalsync, um Abfragen oder Änderungen der Daten zu ermöglichen.

2. Verwenden Sie die pglogical.replicate_ddl_command, um DDL an der Quelle und am Ziel an einem konsistenten Punkt auszuführen. Der Nutzer, der diesen Befehl ausführt, muss sowohl an der Quelle als auch am Ziel denselben Nutzernamen haben. Außerdem sollte er der Superuser oder Inhaber des zu migrierenden Artefakts sein (z. B. der Tabelle, Sequenz, Ansicht oder Datenbank).

   Hier einige Beispiele für die Verwendung von pglogical.replicate_ddl_command.

   Führen Sie den folgenden Befehl aus, um einer Datenbanktabelle eine Spalte hinzuzufügen:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] add column surname varchar(20)', '{default}');

   Führen Sie den folgenden Befehl aus, um den Namen einer Datenbanktabelle zu ändern:

   select pglogical.replicate_ddl_command('ALTER TABLE [schema].[table] RENAME TO [table_name]','{default}');

   Führen Sie die folgenden Befehle aus, um eine Datenbanktabelle zu erstellen:

   1. select pglogical.replicate_ddl_command(command := 'CREATE TABLE [schema].[table] (id INTEGER PRIMARY KEY, name VARCHAR);', replication_sets := ARRAY['default'']);
   2. select pglogical.replication_set_add_table('default', '[schema].[table]');

Was wird nicht migriert?

Wenn Sie der Cloud SQL-Ziellininstanz Nutzer hinzufügen möchten, rufen Sie die Instanz auf und fügen Sie Nutzer auf dem Tab Nutzer oder über den PostgreSQL-Client hinzu. Weitere Informationen zum Erstellen und Verwalten von PostgreSQL-Nutzern

Große Objekte können nicht repliziert werden, da die logische Decodierungsfunktion von PostgreSQL keine Decodierungsänderungen an großen Objekten unterstützt. Bei Tabellen mit dem Spaltentyp „oid“, der auf große Objekte verweist, werden die Zeilen weiterhin synchronisiert und neue Zeilen repliziert. Wenn Sie jedoch versuchen, auf das große Objekt in der Zieldatenbank zuzugreifen (mit lo_get lesen, mit lo_export exportieren oder den Katalog pg_largeobject auf die angegebene OID prüfen), wird die Meldung angezeigt, dass das große Objekt nicht vorhanden ist.

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). Sie sollten UPDATE- und DELETE-Anweisungen manuell migrieren.

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

Die SEQUENCE-Zustände (z. B. last_value) im neuen Cloud SQL-Ziel können von den SEQUENCE-Zuständen der Quelle abweichen.

Welche Netzwerkmethoden werden verwendet?

Um eine Migration im Database Migration Service zu erstellen, muss eine Verbindung zwischen der Quelle und der Cloud SQL-Zielinstanz hergestellt werden. Es werden verschiedene Methoden unterstützt. Wählen Sie diejenige aus, die für die jeweilige Arbeitslast am besten geeignet ist.

Netzwerkmethode	Beschreibung	Vorteile	Nachteile
IP-Zulassungsliste	Bei dieser Methode wird der Quelldatenbankserver so konfiguriert, dass er Verbindungen von der öffentlichen IP-Adresse der Cloud SQL-Instanz akzeptiert. Wenn Sie sich für diese Methode entscheiden, werden Sie beim Erstellen der Migration durch den Einrichtungsvorgang geführt.	Einfach zu konfigurieren. Empfohlen für kurzfristige Migrationsszenarien (POC oder kleine Datenbankmigrationen).	Die Konfiguration der Firewall erfordert möglicherweise Unterstützung von der IT-Abteilung. Die Quelldatenbank ist über eine öffentliche IP-Adresse zugänglich. Die Verbindung ist standardmäßig nicht verschlüsselt. SSL muss in der Quelldatenbank aktiviert werden, um die Verbindung zu verschlüsseln.
Umgekehrter SSH-Tunnel über in der Cloud gehostete VM	Stellt über einen sicheren umgekehrten SSH-Tunnel eine Verbindung vom Ziel zur Quelle her. Erfordert eine Bastion Host-VM im Projekt Google Cloud und einen Computer (z. B. einen Laptop im Netzwerk), der eine Verbindung zur Quelle hat. Der Database Migration Service erfasst die erforderlichen Informationen beim Erstellen der Migration und generiert automatisch das Skript für die Einrichtung.	Einfach zu konfigurieren. Erfordert keine benutzerdefinierte Firewallkonfiguration. Empfohlen für kurzfristige Migrationsszenarien (POC oder kleine Datenbankmigrationen).	Sie sind Inhaber und verwalten die Bastion-VM. Es können zusätzliche Kosten anfallen.
VPC-Peering	Bei dieser Methode werden die VPCs für die Kommunikation miteinander konfiguriert. Dies ist nur möglich, wenn sich die Quelle und das Ziel in Google Cloudbefinden. Empfohlen für langwierige Migrationen oder Migrationen mit großem Volumen.	Google Cloud -Lösung. Einfach zu konfigurieren. Hohe Bandbreite	Nur verfügbar, wenn die Quelle in Google Cloudgehostet wird.
VPN	Hiermit wird ein IPSec-VPN-Tunnel eingerichtet, der das interne Netzwerk und das Google Cloud VPC über eine sichere Verbindung über das öffentliche Internet verbindet. Verwenden Sie Google Cloud VPN oder eine andere VPN-Lösung, die für das interne Netzwerk eingerichtet ist.	Robuste und skalierbare Konnektivitätslösung. Mittelhohe Bandbreite. Integrierte Sicherheit. Als Google Cloud Lösungen oder von anderen Drittanbietern angeboten.	Zusätzliche Kosten. Nicht triviale Konfiguration (es sei denn, sie ist bereits vorhanden).
Cloud Interconnect	Es wird eine hochverfügbare Verbindung mit niedriger Latenz zwischen dem lokalen Netzwerk und Google Cloudverwendet.	Die höchste Bandbreite, ideal für langwierige Migrationen mit hohem Volumen.	Zusätzliche Kosten. Die Verbindung ist standardmäßig nicht sicher. Nicht triviale Konfiguration (es sei denn, sie ist bereits vorhanden).

Welche bekannten Einschränkungen gibt es?

Weitere Informationen zu bekannten Einschränkungen