La migration gérée est une fonctionnalité automatisée qui vous aide à migrer les données un service Hive Metastore autogéré en service Dataproc Metastore, sans tout temps d'arrêt important (également appelé jour de signalement).
Architecture de migration gérée
Le schéma suivant présente l'architecture de haut niveau d'une infrastructure gérée la migration.
Flux de migration géré
Pour effectuer une migration gérée, votre service effectue deux migrations processus : lancez la migration et finalisez la migration. Vous pouvez annuler une migration à tout moment en suivant le processus d'annulation. Il existe également un certain nombre de commandes opérationnelles que vous pouvez exécuter, qui ne sont pas nécessaires pour effectuer une migration. Par exemple, répertorier les migrations ou supprimer et des migrations.
Au fur et à mesure que votre service progresse dans ce processus, il passe d'une
états de la migration et phases de migration. Ces états et phases représentent
qui s'exécutent en arrière-plan. Par exemple, MIGRATING
indique que le service transfère activement des données depuis votre
de la base de données Cloud SQL vers Dataproc Metastore.
Lancer la migration
Dataproc Metastore établit une connexion avec vos une instance Cloud SQL avec adresse IP privée. Une fois la connexion établie, Dataproc Metastore utilise l'instance Cloud SQL Base de données backend de métastore Hive (HMS). Elle demeure également la source pour vos données pendant la migration. Les opérations de lecture et d'écriture de métadonnées se produisent dans Cloud SQL lorsque la migration est active.
Un pipeline de capture des données modifiées (CDC, Change Data Capture) est démarré. Ce pipeline conserve Cloud SQL de votre projet et Spanner dans le Le projet géré Dataproc Metastore est synchronisé. Cela signifie que toutes les modifications apportées à la base de données HMS dans l'instance Cloud SQL sont capturées à l'aide de Datastream et qu'elles sont écrites Base de données Spanner Dataproc Metastore.
Une fois la migration lancée, vous pouvez commencer le routage charges de travail de données vers Dataproc Metastore. À ce stade, Cloud SQL est toujours la source de vérité pour vos données.
Terminer la migration
Après avoir déplacé vos charges de travail vers Dataproc Metastore, peut terminer la migration. Lorsqu'un processus de migration complète est appelé, voici ce qui se produit:
- Dataproc Metastore passe en mode lecture seule jusqu'à ce que migration complète se termine.
- Le flux CDC transfère toutes les données en cours de transfert vers Dataproc Metastore.
- Dataproc Metastore se connecte à Spanner et se déconnecte depuis Cloud SQL. Dataproc Metastore sert désormais de source pour vos données HMS.
Considérations relatives aux proxys et aux pipelines
les proxys ;
Dataproc Metastore utilise un proxy d'authentification Cloud SQL enchaîné à un proxy SOCKS5 pour se connecter à votre instance Cloud SQL privée. Les serveurs proxy SOCKS5 sont exposés via un rattachement de service, comme illustré indiqué dans le diagramme d'architecture précédent.
Chaque migration nécessite un sous-réseau NAT dédié. En effet, un sous-réseau NAT ne peut pas avoir plusieurs rattachements de service.
Pour éviter les problèmes de latence interrégionale, fournissez des sous-réseaux situés dans dans la même région que votre instance Cloud SQL pour héberger le proxy SOCKS5. Par exemple,
proxy_subnetetnat_subnet.
Pipeline de capture des données modifiées
Le pipeline de capture des données modifiées utilise l'appairage de VPC pour établir une connexion entre Datastream et Cloud SQL, adresse IP privée
Pour chaque migration, une connexion privée est créée et un réseau la connexion d'appairage est établie.
Le réseau VPC hébergeant l'instance Cloud SQL des connexions d'appairage en cas de migrations actives. Assurez-vous que votre Le réseau VPC a la capacité d'héberger toutes les connexions d'appairage nécessaires.