Verwaltete Migration

Die verwaltete Migration ist eine automatisierte Funktion, mit der Sie Daten ohne nennenswerte Ausfallzeiten (Flag Day) von einem selbstverwalteten Hive-Metastore zu einem Dataproc Metastore-Dienst migrieren können.

Verwaltete Migrationsarchitektur

Das folgende Diagramm zeigt die allgemeine Architektur einer verwalteten Migration.

Verwaltete Migration zu Dataproc Metastore

Verwalteter Migrationsablauf

Für die Durchführung einer verwalteten Migration durchläuft Ihr Dienst zwei Migrationsprozesse: Migration starten und Migration abschließen. Sie können eine Migration jederzeit mit dem Migration abbrechen-Vorgang abbrechen. Es gibt auch eine Reihe von operativen Befehlen, die Sie ausführen können, die die für eine Migration erforderlich sind. Beispiel: Migrationen auflisten oder Löschen .

Während Ihr Dienst diesen Prozess durchläuft, wechselt er auch zwischen verschiedenen Migrationsstatus und Migrationsphasen. Diese Zustände und Phasen stellen die im Hintergrund ablaufende Prozesse. Der Status MIGRATING gibt beispielsweise an, dass Ihr Dienst aktiv Daten aus Ihrer Cloud SQL-Datenbank in den Dataproc Metastore überträgt.

Migration starten

  • Dataproc Metastore stellt eine Verbindung zu Ihrer Cloud SQL-Instanz mit privater IP-Adresse her. Nach der Verbindung wird die Cloud SQL-Instanz als HMS-Back-End-Datenbank (Hive Metastore) vom Dataproc Metastore verwendet. Sie bleibt auch die Quelle für Ihre Daten während der Migration. Lese- und Schreibvorgänge für Metadaten erfolgen weiterhin in Cloud SQL, wenn die Migration aktiv ist.

  • Eine CDC-Pipeline (Change Data Capture) wird gestartet. Mit dieser Pipeline werden die Cloud SQL-Instanz in Ihrem Projekt und Spanner im verwalteten Dataproc Metastore-Projekt synchronisiert. Das bedeutet, dass Alle Änderungen an der HMS-Datenbank in der Cloud SQL-Instanz werden erfasst. über Datastream verarbeitet und in den Dataproc Metastore-Spanner-Datenbank.

Sobald der Migrationsprozess erfolgreich gestartet wurde, können Sie mit dem Routing beginnen. Datenarbeitslasten in Dataproc Metastore hochladen. Jetzt ist Cloud SQL und trotzdem die zentrale Informationsquelle für Ihre Daten.

Migration abschließen

Nachdem Sie Ihre Arbeitslasten in Dataproc Metastore verschoben haben, die Migration abschließen können. Wenn ein vollständiger Migrationsprozess aufgerufen wird, geschieht Folgendes:

  • Dataproc Metastore wechselt in einen schreibgeschützten Modus, bis die vollständige Migration abgeschlossen haben.
  • Der CDC-Stream überträgt alle In-Flight-Daten an Dataproc Metastore.
  • Dataproc Metastore stellt eine Verbindung zu Spanner her und trennt die Verbindung aus Cloud SQL. Dataproc Metastore dient jetzt als Source of Truth für Ihre HMS-Daten.

Überlegungen zu Proxy und Pipeline

Proxys

Dataproc Metastore verwendet einen Cloud SQL Auth-Proxy an einen SOCKS5-Proxy verkettet ist, um eine Verbindung zu Ihrer privaten IP-Instanz in Cloud SQL herzustellen. Die SOCKS5-Proxyserver werden wie unten gezeigt über einen Dienstanhang verfügbar gemacht. im vorherigen Architekturdiagramm.

  • Für jede Migration ist ein eigenes NAT-Subnetz erforderlich. Das liegt daran, dass ein NAT-Subnetz nicht mehr als einen Dienstanhang haben kann.

  • Um regionsübergreifende Latenzprobleme zu vermeiden, geben Sie Subnetze im in der sich Ihre Cloud SQL-Instanz befindet, um den SOCKS5-Proxy zu hosten. Beispiel: proxy_subnet und nat_subnet.

Change Data Capture-Pipeline

Die Change-Data-Capture-Pipeline verwendet VPC-Peering, um eine Verbindung herzustellen zwischen Datastream und privater IP-Adresse in Cloud SQL

  • Bei jeder Migration wird eine neue private Verbindung erstellt und eine neue Peering-Verbindung hergestellt wird.

  • Das VPC-Netzwerk, in dem die Cloud SQL-Instanz gehostet wird, hat so viele Peering-Verbindungen wie es aktive Migrationen gibt. Achten Sie darauf, dass die Das VPC-Netzwerk kann alle erforderlichen Peering-Verbindungen hosten.

Nächste Schritte