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.
Architektur für verwaltete Migrationen
Das folgende Diagramm zeigt die allgemeine Architektur einer verwalteten Migration.
Ablauf einer verwalteten Migration
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 Befehlen, die Sie ausführen können, die für die Migration nicht erforderlich sind. Beispiel: migrations auflisten oder migrations löschen.
Während der Dienst diesen Prozess durchläuft, wechselt er auch zwischen verschiedenen Migrationsstatus und Migrationsphasen. Diese Status und Phasen stehen für die Prozesse, die im Hintergrund ablaufen. 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. Außerdem bleibt es während der Migration die vertrauenswürdige Quelle für Ihre Daten. 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 über Datastream erfasst und in die Spanner-Datenbank von Dataproc Metastore geschrieben werden.
Sobald der Migrationsprozess gestartet wurde, können Sie mit dem Weiterleiten von Datenarbeitslasten an Dataproc Metastore beginnen. Cloud SQL ist derzeit noch die vertrauenswürdige Quelle für Ihre Daten.
Migration abschließen
Nachdem Sie Ihre Arbeitslasten in den Dataproc Metastore verschoben haben, können Sie die Migration abschließen. Wenn ein vollständiger Migrationsprozess aufgerufen wird, geschieht Folgendes:
- Dataproc Metastore wechselt in den Lesezugriffsmodus, bis die vollständige Migration abgeschlossen ist.
- Der CDC-Stream überträgt alle laufenden Daten an Dataproc Metastore.
- Dataproc Metastore stellt eine Verbindung zu Spanner her und trennt die Verbindung zu Cloud SQL. Dataproc Metastore dient jetzt als Source of Truth für Ihre HMS-Daten.
Proxy- und Pipeline-Hinweise
Proxys
Der Dataproc-Metastore verwendet einen Cloud SQL Auth-Proxy, der mit einem SOCKS5-Proxy verkettet ist, um eine Verbindung zu Ihrer Cloud SQL-Instanz mit privater IP-Adresse herzustellen. Die SOCKS5-Proxyserver werden über einen Dienst-Anhang freigegeben, wie im vorherigen Architekturdiagramm dargestellt.
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 regionenübergreifende Latenzprobleme zu vermeiden, sollten Sie Subnetze in derselben Region wie Ihre Cloud SQL-Instanz angeben, um den SOCKS5-Proxy zu hosten. Beispiel:
proxy_subnetundnat_subnet.
Change Data Capture-Pipeline
Die Change Data Capture-Pipeline verwendet VPC-Peering, um eine Verbindung zwischen Datastream und Cloud SQL mit privater IP-Adresse herzustellen.
Für jede Migration wird eine neue private Verbindung und eine neue Peering-Verbindung hergestellt.
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 Ihr VPC-Netzwerk die Kapazität hat, alle erforderlichen Peering-Verbindungen zu hosten.