La migration gérée est une fonctionnalité automatisée qui vous aide à migrer des données d'un métastore Hive autogéré vers un service Dataproc Metastore, sans temps d'arrêt important (également appelé jour de drapeau).
Architecture de migration gérée
Le diagramme suivant présente l'architecture générale d'une migration gérée.
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 à l'aide de la procédure Annuler la migration. 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, list migrations (lister les migrations) ou delete migrations (supprimer les 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 les processus en cours en arrière-plan. Par exemple, l'état MIGRATING indique que votre service transfère activement des données de votre base de données Cloud SQL vers Dataproc Metastore.
Démarrer 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 comme base de données backend du 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 synchronise l'instance Cloud SQL de votre projet et Spanner dans le projet géré Dataproc Metastore. Cela signifie que toutes les modifications apportées à la base de données HMS dans l'instance Cloud SQL sont capturées via Datastream et écrites dans la base de données Spanner de 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.
Effectuer la migration
Une fois que vous avez terminé de déplacer vos charges de travail vers Dataproc Metastore, vous pouvez terminer la migration. Lorsqu'un processus de migration complet est appelé, voici ce qui se produit:
- Dataproc Metastore passe en mode lecture seule jusqu'à la fin du processus de migration complète.
- 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 de référence pour vos données HMS.
Considérations relatives aux proxys et aux pipelines
les proxys ;
Dataproc Metastore utilise un proxy d'authentification Cloud SQL associé à un proxy SOCKS5 pour se connecter à votre instance Cloud SQL à adresse IP privée. Les serveurs proxy SOCKS5 sont exposés via une pièce jointe de service, comme indiqué dans le schéma 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 de modification utilise l'appairage 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.