FAQs zum Database Migration Service für AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

• Was ist der Database Migration Service?
• Welche Quellen werden unterstützt?
• Gibt es versionsübergreifenden Support?
• 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 Einschränkungen sind bekannt?

Was ist der Database Migration Service?

Database Migration Service ist ein Dienst, mit dem Sie Ihre Daten einfacher zu Google Cloudmigrieren können. Mit Database Migration Service können Sie Ihre PostgreSQL-Arbeitslasten in AlloyDB 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+, 11.6+, 12.4+, 13.3+, 14, 15, 16, 17
• Selbstverwaltetes PostgreSQL 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17 (lokal oder auf einer vollständig von Ihnen verwalteten Cloud-VM)
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Welche Ziele werden unterstützt?

• AlloyDB for PostgreSQL 14, 15, 16, 17

Gibt es versionsübergreifende Unterstützung?

Database Migration Service unterstützt Migrationen von PostgreSQL zu AlloyDB aus allen unterstützten Quelldatenbankversionen.

Welche Daten-, Schema- und Metadatenkomponenten werden migriert?

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

Datenmigration

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

Schema-Migration

• Benennung
• Primärschlüssel
• Datentyp
• Ordnungszahl
• Standardwert
• Null-Zulässigkeit
• Attribute für automatische Inkrementierung
• Sekundäre Indexe

Metadatenmigration

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

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

Während der Migration werden nur DML-Änderungen automatisch aktualisiert. Die DDL so zu verwalten, dass die Quell- und Zieldatenbank(en) kompatibel bleiben, liegt in der Verantwortung des Nutzers. Dies kann auf zwei Arten erreicht werden:

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 alloydbexternalsync, bevor die DDL-Befehle für das Ziel ausgeführt werden. Gewähren Sie den entsprechenden Cloud SQL-Nutzern die Rolle alloydbexternalsync, um Abfragen oder Änderungen der Daten zu ermöglichen.

2. Verwenden Sie 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 in der Quelle als auch im Ziel denselben Nutzernamen haben und der Superuser oder der Inhaber des migrierten Artefakts (z. B. der Tabelle, Sequenz, Ansicht oder Datenbank) sein.

   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 AlloyDB-Zielinstanz Nutzer hinzufügen möchten, fügen Sie sie über den PostgreSQL-Client hinzu. Weitere Informationen zum Erstellen und Verwalten von PostgreSQL-Nutzern

Große Objekte können nicht repliziert werden, da die Funktion zur logischen Decodierung von PostgreSQL keine Decodierung von Ä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 (Lesen mit lo_get, Exportieren mit lo_export oder Prüfen des Katalogs pg_largeobject für die angegebene OID), schlägt dies mit einer Meldung fehl, 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 die Anweisungen UPDATE und DELETE 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-Status (z. B. last_value) im neuen AlloyDB-Ziel können sich von den SEQUENCE-Status der Quelle unterscheiden.

Welche Netzwerkmethoden werden verwendet?

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

Netzwerkverfahren	Beschreibung	Vorteile	Nachteile
Umgekehrter SSH-Tunnel über in der Cloud gehostete VM	Stellt die Verbindung vom Ziel zur Quelle über einen sicheren umgekehrten SSH-Tunnel her. Erfordert eine Bastion Host-VM im Google Cloud Projekt und einen Computer (z. B. einen Laptop im Netzwerk), der eine Verbindung zur Quelle hat. Database Migration Service erfasst die erforderlichen Informationen beim Erstellen der Migration und generiert das Skript für die Einrichtung automatisch.	Einfach zu konfigurieren. Es ist keine benutzerdefinierte Firewallkonfiguration erforderlich. Empfohlen für kurzlebige Migrationsszenarien (POC oder kleine Datenbankmigrationen).	Sie sind Inhaber der Bastion-VM und verwalten sie. Es können zusätzliche Kosten anfallen.
TCP-Proxy über eine in der Cloud gehostete VM	Stellt eine Verbindung vom Ziel zur Quelle über einen TCP-Proxy über eine in der Cloud gehostete VM her. Database Migration Service erfasst die erforderlichen Informationen beim Erstellen der Migration und generiert das Skript für die Einrichtung automatisch. Relevant für AlloyDB-Migrationen, bei denen sich die Quelle in der alten Netzwerkarchitektur befindet.	Einfach zu konfigurieren. Es ist keine benutzerdefinierte Firewallkonfiguration erforderlich.	Die Bastion-VM gehört Ihnen und wird von Ihnen verwaltet. Es können zusätzliche Kosten anfallen.
VPC-Peering	Bei dieser Methode werden die VPCs für die Kommunikation miteinander konfiguriert.	Native Google Cloud Lösung. Einfach zu konfigurieren. Hohe Bandbreite Empfohlen für Migrationen mit langer Laufzeit oder hohem Volumen.	Gilt nur, wenn sowohl die Quell- als auch die Zieldatenbank in Google Cloudgehostet werden.
VPN	Richtet einen IPSec-VPN-Tunnel ein, der das interne Netzwerk und die Google Cloud VPC über eine sichere Verbindung über das öffentliche Internet verbindet. Verwenden Sie Google Cloud VPN oder eine beliebige VPN-Lösung, die für das interne Netzwerk eingerichtet ist.	Robuste und skalierbare Konnektivitätslösung Mittlere bis hohe Bandbreite. Integrierte Sicherheit. Google Cloud Lösungen oder von anderen Dritten angeboten.	Zusätzliche Kosten. Nicht triviale Konfiguration (sofern nicht bereits vorhanden).
Cloud Interconnect	Verwendet eine hochverfügbare Verbindung mit niedriger Latenz zwischen dem lokalen Netzwerk und Google Cloud.	Höchste Bandbreite, ideal für lang andauernde Migrationen mit hohem Volumen.	Zusätzliche Kosten. Die Verbindung ist standardmäßig nicht sicher. Nicht triviale Konfiguration (sofern nicht bereits vorhanden).

Welche Einschränkungen sind bekannt?

Bekannte Einschränkungen