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 schéma suivant présente l'architecture générale d'une migration gérée.
Flux de migration gérée
Pour effectuer une migration gérée, votre service passe par deux processus de migration : démarrer la migration et terminer la migration. Vous pouvez annuler une migration à tout moment à l'aide de la procédure Annuler la migration. Vous pouvez également exécuter un certain nombre de commandes opérationnelles 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 de ce processus, votre service passe également par différents états de 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 votre instance Cloud SQL à 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). Il reste également la source de vérité pour vos données pendant la migration. Les lectures et écritures de métadonnées se produisent toujours dans Cloud SQL lorsque la migration est active.
Un pipeline de capture de données modifiées (CDC) est lancé. 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 le processus de démarrage de la migration terminé, vous pouvez commencer à acheminer les charges de travail de données vers Dataproc Metastore. À ce stade, Cloud SQL reste 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 finaliser la migration. Lorsqu'un processus de migration complète est appelé, les événements suivants se produisent:
- 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 de Cloud SQL. Dataproc Metastore sert désormais de source de référence pour vos données HMS.
Considérations concernant le proxy et le pipeline
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 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 VPC pour établir une connexion entre Datastream et Cloud SQL à adresse IP privée.
Pour chaque migration, une nouvelle connexion privée est créée et une nouvelle connexion d'appairage est établie.
Le réseau VPC hébergeant l'instance Cloud SQL comporte autant de connexions d'appariement que de migrations actives. Assurez-vous que votre réseau VPC a la capacité d'héberger toutes les connexions d'appairage nécessaires.