La migración gestionada es una función automatizada que te ayuda a migrar datos de un Hive Metastore autogestionado a un servicio Dataproc Metastore sin que se produzca un tiempo de inactividad considerable (también conocido como día de la bandera).
Arquitectura de migración gestionada
En el siguiente diagrama se muestra la arquitectura general de una migración gestionada.
Flujo de migración gestionado
Para completar una migración gestionada, tu servicio debe pasar por dos procesos de migración: iniciar migración y completar migración. Puedes cancelar una migración en cualquier momento con el proceso cancelar migración. También puedes ejecutar varios comandos operativos, que no son necesarios para completar una migración. Por ejemplo, list migrations o delete migrations.
A medida que tu servicio avanza en este proceso, también pasa por varios estados de migración y fases de migración. Estos estados y fases representan los procesos que se producen en segundo plano. Por ejemplo, el estado MIGRATING
indica que tu servicio está transfiriendo datos de forma activa desde tu base de datos de Cloud SQL a Dataproc Metastore.
Iniciar migración
Dataproc Metastore establece una conexión con tu instancia de Cloud SQL de IP privada. Una vez establecida la conexión, Dataproc Metastore usa la instancia de Cloud SQL como base de datos de backend de Hive Metastore (HMS). También sigue siendo la fuente de información veraz de tus datos durante la migración. Las lecturas y escrituras de metadatos siguen produciéndose en Cloud SQL cuando la migración está activa.
Se inicia una canalización de captura de datos de cambios (CDC). Esta canalización mantiene sincronizadas la instancia de Cloud SQL de tu proyecto y Spanner en el proyecto gestionado de Dataproc Metastore. Esto significa que todos los cambios en la base de datos de HMS de la instancia de Cloud SQL se capturan a través de Datastream y se escriben en la base de datos de Spanner de Dataproc Metastore.
Una vez que el proceso de inicio de la migración se haya completado correctamente, puedes empezar a enrutar cargas de trabajo de datos a Dataproc Metastore. En este punto, Cloud SQL sigue siendo la fuente de información veraz de tus datos.
Completar migración
Una vez que hayas terminado de mover tus cargas de trabajo a Dataproc Metastore, puedes completar la migración. Cuando se llama a un proceso de migración completa, ocurre lo siguiente:
- Dataproc Metastore pasa a modo de solo lectura hasta que finaliza el proceso de migración completa.
- El flujo de CDC transfiere todos los datos en tránsito a Dataproc Metastore.
- Dataproc Metastore se conecta a Spanner y se desconecta de Cloud SQL. Dataproc Metastore ahora actúa como fuente de información veraz para tus datos de HMS.
Consideraciones sobre proxies y flujos de procesamiento
Proxies
Dataproc Metastore usa un proxy de autenticación de Cloud SQL encadenado a un proxy SOCKS5 para conectarse a tu instancia de Cloud SQL con IP privada. Los servidores proxy SOCKS5 se exponen a través de un acoplamiento de servicio, tal como se muestra en el diagrama de arquitectura anterior.
Cada migración requiere una subred NAT específica. Esto se debe a que una subred NAT no puede tener más de un adjunto de servicio.
Para evitar problemas de latencia entre regiones, proporciona subredes que estén en la misma región que tu instancia de Cloud SQL para alojar el proxy SOCKS5. Por ejemplo,
proxy_subnetynat_subnet.
Flujo de procesamiento de captura de datos de cambios
La canalización de captura de cambios de datos usa el peering de VPC para establecer una conexión entre Datastream y Cloud SQL con IP privada.
En cada migración, se crea una conexión privada y se establece una conexión de emparejamiento.
La red de VPC que aloja la instancia de Cloud SQL tiene tantas conexiones de emparejamiento como migraciones activas. Asegúrate de que tu red de VPC tenga capacidad para alojar todas las conexiones de peering necesarias.