FAQs zum Database Migration Service für AlloyDB

MySQL   |  PostgreSQL   |  PostgreSQL zu AlloyDB

• Was ist Database Migration Service?
• Welche Quellen werden unterstützt?
• Gibt es 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 Database Migration Service?

Database Migration Service ist ein Dienst, mit dem Sie Ihre Daten einfacher zu migrieren können Google Cloud. Mit Database Migration Service können Sie Ihre PostgreSQL-Arbeitslasten zu 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 (lokal oder auf einer beliebigen Cloud-VM, die Sie vollständig kontrollieren) 9.4, 9.5, 9.6, 10, 11, 12, 13, 14, 15, 16, 17
• Cloud SQL 9.6, 10, 11, 12, 13, 14, 15, 16, 17

Welche Ziele werden unterstützt?

• AlloyDB for PostgreSQL 14, 15, 16, 17, 18

Gibt es versionsübergreifende Unterstützung?

Database Migration Service unterstützt PostgreSQL-zu-AlloyDB-Migrationen 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. Alle folgenden Daten-, Schema- und Metadatenkomponenten werden im Rahmen der Datenbankmigration migriert:

Datenmigration

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

Schemamigration

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

Metadatenmigration

• Gespeicherte Prozeduren
• Funktionen
• Trigger
• Aufrufe
• Fremdschlüsselbeschränkungen

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

Während der Migration werden nur DML-Änderungen automatisch aktualisiert. Der Nutzer ist für die Verwaltung von DDL verantwortlich, damit die Quell- und Zieldatenbank(en) kompatibel bleiben. 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 die pglogical.replicate_ddl_command, um die DDL an einem konsistenten Punkt für die Quelle und das Ziel auszuführen. Der Nutzer, der diesen Befehl ausführt, muss denselben Nutzernamen für die Quelle und das Ziel haben und Superuser oder Inhaber des migrierten Artefakts sein (z. B. die Tabelle, Sequenz, Ansicht oder Datenbank).

   Hier sind 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 logische 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 Überprü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). UPDATE- und DELETE-Anweisungen sollten Sie manuell migrieren.

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) in der neuen AlloyDB-Zielinstanz können von den SEQUENCE-Zuständen der Quelle abweichen.

Welche Netzwerkmethoden werden verwendet?

Um eine Migration in 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 die Methode aus, die für die jeweilige Arbeitslast am besten geeignet ist.

Netzwerkmethode	Beschreibung	Vorteile	Nachteile
Umgekehrter SSH-Tunnel über in der Cloud gehostete VM	Stellt eine Verbindung vom Ziel zur Quelle über einen sicheren umgekehrten SSH-Tunnel her. Erfordert einen Bastion-Host auf einer 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 bei der Erstellung der Migration und generiert automatisch das Skript für die Einrichtung.	Einfach zu konfigurieren. Erfordert keine benutzerdefinierte Firewallkonfiguration. Empfohlen für kurzlebige Migrationsszenarien (POC oder kleine Datenbankmigrationen).	Sie sind Inhaber der Bastion-VM und verwalten sie. Kann zusätzliche Kosten verursachen.
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 bei der Erstellung der Migration und generiert automatisch das Skript für die Einrichtung. Relevant für AlloyDB-Migrationen, bei denen sich die Quelle in der alten Netzwerkarchitektur befindet.	Einfach zu konfigurieren. Erfordert keine benutzerdefinierte Firewallkonfiguration.	Sie sind Inhaber der Bastion-VM und verwalten sie. Dadurch 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.	Nur anwendbar, wenn sowohl die Quell- als auch die Zieldatenbank ingehostet werden Google Cloud.
VPN	Richtet einen IPSec-VPN-Tunnel ein, der das interne Netzwerk und 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 Lösung für die Verbindung. Mittlere bis hohe Bandbreite. Integrierte Sicherheit. Wird als Google Cloud Lösung oder von anderen Drittanbietern 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 Migrationen mit langer Laufzeit und hohem Volumen.	Zusätzliche Kosten. Die Verbindung ist standardmäßig nicht sicher. Nicht triviale Konfiguration (sofern nicht bereits vorhanden).

Welche bekannten Einschränkungen gibt es?

Bekannte Einschränkungen ansehen.