Migra de AWS a Google Cloud: Migra de Amazon RDS y Amazon Aurora para MySQL a Cloud SQL para MySQL

Last reviewed 2024-08-16 UTC

Google Cloud proporciona herramientas, productos, orientación y servicios profesionales para migrar de Amazon Relational Database Service (RDS) o Amazon Aurora a Cloud SQL para MySQL.

Este documento está dirigido a los administradores de la nube y de bases de datos que desean planificar, implementar y validar un proyecto de migración de bases de datos. También está dirigido a los encargados de tomar decisiones que evalúan la oportunidad de migrar y que desean ver un ejemplo de cómo podría ser la migración.

Este documento se enfoca en una migración de bases de datos homogénea, que es una migración en la que las bases de datos de origen y de destino usan la misma tecnología de base de datos. En esta guía de migración, el origen es Amazon RDS o Amazon Aurora para MySQL, y el destino es Cloud SQL para MySQL.

Este documento pertenece a una serie de varias partes sobre la migración de AWS a Google Cloud que incluye los siguientes documentos:

Para esta migración a Google Cloud, te recomendamos que sigas el framework de migración que se describe en Migra a Google Cloud: Comienza ahora.

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

Puedes migrar de tu entorno de origen a Google Cloud en una serie de iteraciones, por ejemplo, puedes migrar algunas cargas de trabajo primero y otras más tarde. Para cada iteración de migración independiente, debes seguir las fases del framework de migración general:

  1. Evalúa y descubre las cargas de trabajo y los datos.
  2. Planifica y compila una base en Google Cloud.
  3. Migra tus cargas de trabajo y datos a Google Cloud.
  4. Optimiza tu entorno de Google Cloud .

Para obtener más información sobre las fases de este framework, consulta Migra a Google Cloud: Comienza ahora.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y te asegures de tener una estrategia de reversión. Para ayudarte a validar tu plan de migración, consulta Migra a Google Cloud: Prácticas recomendadas para validar un plan de migración.

Evalúa el entorno de origen|

En la fase de evaluación, determinarás los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.

La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las cargas de trabajo que deseas migrar, sus requisitos, sus dependencias y tu entorno actual. Debes saber cuál es tu punto de partida para planificar y ejecutar de forma correcta una migración de Google Cloud.

La fase de evaluación consta de las siguientes tareas:

  1. Crea un inventario completo de tus aplicaciones.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Capacitar y educar a tus equipos sobre Google Cloud
  4. Crea experimentos y pruebas de concepto en Google Cloud.
  5. Calcular el costo total de propiedad (TCO) del entorno de destino
  6. Elige la estrategia de migración para tus cargas de trabajo.
  7. Elige tus herramientas de migración.
  8. Define el plan y el cronograma de migración.
  9. Valida tu plan de migración.

La fase de evaluación de la base de datos te ayuda a elegir el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL de destino que coincida con la fuente para necesidades de rendimiento similares. Presta especial atención al tamaño del disco y a la capacidad de procesamiento, las IOPS y la cantidad de CPU virtuales. Las migraciones pueden tener dificultades o fallar debido a un tamaño incorrecto de la instancia de la base de datos de destino. Un tamaño incorrecto puede generar tiempos de migración prolongados, problemas de rendimiento de la base de datos, errores de la base de datos y problemas de rendimiento de la aplicación. Cuando decidas qué instancia de Cloud SQL usar, ten en cuenta que el rendimiento del disco se basa en su tamaño y en la cantidad de CPU virtuales.

Las siguientes secciones se basan en Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo, y se integra la información de ese documento.

Crea un inventario de tus instancias de Amazon RDS o Amazon Aurora

Para definir el alcance de la migración, crea un inventario y recopila información sobre tus instancias de Amazon RDS o Amazon Aurora. Te recomendamos que automatices este proceso con herramientas especializadas, ya que los enfoques manuales son propensos a errores y pueden generar suposiciones incorrectas.

Es posible que Amazon RDS o Amazon Aurora y Cloud SQL no tengan funciones, especificaciones de instancias ni operaciones similares. Es posible que algunas funciones se implementen de manera diferente o no estén disponibles. Las áreas de diferencias pueden incluir infraestructura, almacenamiento, autenticación y seguridad, replicación, copia de seguridad, alta disponibilidad, modelo de capacidad de recursos y, también, integraciones y extensiones de funciones específicas del motor de base de datos. Según el tipo de motor de base de datos, el tamaño de la instancia y la arquitectura, también puede haber diferencias en los valores predeterminados de la configuración de los parámetros de la base de datos.

La comparativa puede ayudarte a comprender mejor las cargas de trabajo que se migrarán y contribuye a definir la arquitectura correcta del entorno de destino de la migración. Recopilar información sobre el rendimiento es importante para ayudar a estimar las necesidades de rendimiento del entorno de destino de Google Cloud . Los conceptos y las herramientas de comparativas se detallan en la fase Realiza pruebas y validaciones del proceso de migración, pero también se aplican a la etapa de creación del inventario.

Herramientas para evaluaciones

Para realizar una evaluación inicial de tu infraestructura actual, te recomendamos que uses Google Cloud Migration Center junto con otras herramientas especializadas de evaluación de bases de datos, como migVisor y Database Migration Assessment (DMA).

Con Migration Center, puedes realizar una evaluación completa de tu panorama de aplicaciones y bases de datos, incluida la idoneidad técnica para una migración de bases de datos a Google Cloud. Recibirás recomendaciones de tamaño y configuración para cada base de datos de origen y crearás un informe del costo total de propiedad (TCO) para los servidores y las bases de datos.

Para obtener más información sobre cómo evaluar tu entorno de AWS con Migration Center, consulta Importa datos de otros proveedores de servicios en la nube.

Además de Migration Center, puedes usar la herramienta especializada migVisor. migVisor admite una variedad de motores de bases de datos y es especialmente adecuado para migraciones heterogéneas. Para obtener una introducción a migVisor, consulta la descripción general de migVisor.

migVisor puede identificar artefactos y funciones de bases de datos de propiedad exclusiva incompatibles que pueden causar el incumplimiento de la migración y puede indicar soluciones alternativas. migVisor también puede recomendar una solución de Google Cloud de destino, incluidos el tamaño y la arquitectura iniciales.

El resultado de la evaluación de la base de datos de migVisor proporciona lo siguiente:

  • Descubrimiento y análisis integrales de las implementaciones de bases de datos actuales.
  • Informe detallado de la complejidad de la migración, según las funciones propias que usa tu base de datos.
  • Informe financiero con detalles sobre el ahorro de costos posterior a la migración, los costos de migración y el nuevo presupuesto operativo.
  • Plan de migración por fases para mover bases de datos y aplicaciones asociadas con una interrupción mínima para la empresa.

Para ver algunos ejemplos de resultados de la evaluación, consulta migVisor: Herramienta de evaluación de migración a la nube.

Ten en cuenta que migVisor aumenta temporalmente el uso del servidor de la base de datos. Por lo general, esta carga adicional es inferior al 3% y se puede ejecutar durante las horas no pico.

El resultado de la evaluación de migVisor te ayuda a crear un inventario completo de tus instancias de RDS. El informe incluye propiedades genéricas (versión y edición del motor de base de datos, CPUs y tamaño de la memoria), así como detalles sobre la topología de la base de datos, las políticas de copia de seguridad, la configuración de parámetros y las personalizaciones especiales en uso.

Si prefieres usar herramientas de código abierto, puedes usar secuencias de comandos de recopilador de datos con (o en lugar de) las herramientas mencionadas. Estas secuencias de comandos pueden ayudarte a recopilar información detallada (sobre cargas de trabajo, funciones, objetos de base de datos y código de base de datos) y crear tu inventario de bases de datos. Además, las secuencias de comandos suelen proporcionar una evaluación detallada de la migración de la base de datos, incluida una estimación del esfuerzo de migración.

Recomendamos la herramienta de código abierto DMA, que crearon los ingenieros de Google. Ofrece una evaluación completa y precisa de la base de datos, incluidas las funciones en uso, la lógica de la base de datos y los objetos de la base de datos (incluidos esquemas, tablas, vistas, funciones, activadores y procedimientos almacenados).

Para usar DMA, descarga las secuencias de comandos de recopilación para tu motor de base de datos desde el repositorio de Git y sigue las instrucciones. Envía los archivos de salida a Google Cloud para su análisis. Google Cloud crea y entrega una lectura de la evaluación de la base de datos, y proporciona los próximos pasos en el recorrido de migración.

Identificar y documentar el alcance de la migración y el tiempo de inactividad aceptable

En esta etapa, documentas la información esencial que influye en tu estrategia y herramientas de migración. A esta altura, ya puedes responder las siguientes preguntas:

  • ¿Tus bases de datos superan los 5 TB?
  • ¿Hay tablas grandes en tu base de datos? ¿Superan los 16 TB?
  • ¿Dónde se encuentran las bases de datos (regiones y zonas) y cuál es su proximidad a las aplicaciones?
  • ¿Con qué frecuencia cambian los datos?
  • ¿Cuál es tu modelo de coherencia de datos?
  • ¿Cuáles son las opciones para las bases de datos de destino?
  • ¿Qué tan compatibles son las bases de datos de origen y de destino?
  • ¿Los datos deben residir en algunas ubicaciones físicas?
  • ¿Hay datos que se puedan comprimir y archivar, o hay datos que no necesitan migración en absoluto?

Para definir el alcance de la migración, decide qué datos conservar y cuáles migrar. Migrar todas tus bases de datos puede requerir mucho tiempo y esfuerzo. Es posible que algunos datos permanezcan en las copias de seguridad de la base de datos de origen. Por ejemplo, es posible que no se necesiten tablas de registro antiguas o datos de archivo. Como alternativa, puedes decidir mover los datos después del proceso de migración, según tu estrategia y herramientas.

Establece referencias de migración de datos que te ayuden a comparar y evaluar tus resultados y efectos. Estas líneas de base son puntos de referencia que representan el estado de tus datos antes y después de la migración, y te ayudan a tomar decisiones. Es importante realizar mediciones en el entorno de origen que puedan ayudarte a evaluar el éxito de la migración de datos. Estas mediciones incluyen lo siguiente:

  • El tamaño y la estructura de tus datos
  • La integridad y coherencia de tus datos
  • La duración y el rendimiento de las transacciones y los procesos empresariales más importantes

Determina cuánto tiempo de inactividad puedes permitirte. ¿Cuáles son los impactos comerciales del tiempo de inactividad? ¿Hay períodos de baja actividad de la base de datos, durante los cuales hay menos usuarios afectados por el tiempo de inactividad? Si es así, ¿cuánto duran esos períodos y cuándo ocurren? Considera tener un tiempo de inactividad parcial solo de escritura, mientras se siguen entregando las solicitudes de solo lectura.

Evalúa tu proceso de implementación y administración

Después de crear los inventarios, evalúa los procesos operativos y de implementación de tu base de datos para determinar cómo debes adaptarlos para facilitar la migración. Estos procesos son fundamentales para la forma en que preparas y mantienes tu entorno de producción.

Considera cómo completar las siguientes tareas:

  • Define y aplica políticas de seguridad para tus instancias: Por ejemplo, es posible que debas reemplazar los grupos de seguridad de Amazon. Puedes usar roles de IAM de Google, reglas de firewall de VPC y Controles del servicio de VPC para controlar el acceso a tus instancias de Cloud SQL y restringir los datos dentro de una VPC.

  • Aplica parches y configura tus instancias: Es posible que debas actualizar tus herramientas de implementación existentes. Por ejemplo, es posible que uses parámetros de configuración personalizados en los grupos de parámetros o de opciones de Amazon. Es posible que tus herramientas de aprovisionamiento deban adaptarse para usar Google Cloud Storage o Secret Manager para leer esas listas de configuración personalizadas.

  • Administra la infraestructura de supervisión y alertas: Las categorías de métricas para tus instancias de base de datos de origen de Amazon proporcionan observabilidad durante el proceso de migración. Las categorías de métricas pueden incluir Amazon CloudWatch, Estadísticas de rendimiento, Enhanced Monitoring y listas de procesos del SO.

Completa la evaluación

Después de compilar los inventarios de tu entorno de Amazon RDS o Amazon Aurora, completa el resto de las actividades de la fase de evaluación como se describe en Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo.

Planifica y compila tu base

En la fase de planificación y compilación, aprovisionarás y configurarás la infraestructura para hacer lo siguiente:

  • Admitir tus cargas de trabajo en tu entorno de Google Cloud .
  • Conectar tu entorno de origen y tu entorno de Google Cloud para completar la migración

La fase de planificación y compilación se compone de las siguientes tareas:

  1. Compila una jerarquía de recursos.
  2. Configura Identity and Access Management (IAM) de Google Cloud.
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configurar el registro, la supervisión y las alertas

Para obtener más información sobre cada una de estas tareas, consulta Migra a Google Cloud: Planifica y compila tu base.

Si planeas usar Database Migration Service para la migración, consulta Métodos de herramientas de redes para MySQL para comprender las opciones de configuración de herramientas de redes disponibles para las situaciones de migración.

Supervisión y alertas

Usa Cloud Monitoring de Google, que incluye paneles predefinidos para varios productos de Google Cloud , incluido un panel de supervisión de Cloud SQL. Como alternativa, puedes considerar usar soluciones de supervisión de terceros que se integran en Google Cloud, como Datadog y Splunk. Para obtener más información, consulta Acerca de la observabilidad de la base de datos.

Migra instancias de Amazon RDS y Amazon Aurora para MySQL a Cloud SQL para MySQL

Para migrar tus instancias, haz lo siguiente:

  1. Elige la estrategia de migración: replicación continua o mantenimiento programado.

  2. Elige las herramientas de migración según la estrategia y los requisitos que hayas elegido.

  3. Define el plan y el cronograma de migración para cada base de datos, incluidas las tareas de preparación y ejecución.

  4. Define las tareas de preparación que se deben realizar para garantizar que la herramienta de migración pueda funcionar correctamente.

  5. Define las tareas de ejecución, que incluyen las actividades de trabajo que implementan la migración.

  6. Define situaciones de resguardo para cada tarea de ejecución.

  7. Realiza pruebas y validaciones, que se pueden hacer en un entorno de etapa de pruebas independiente.

  8. Realiza la migración.

  9. Realizar la migración de sistemas de producción.

  10. Limpiar el entorno de origen y configurar la instancia de destino

  11. Realizar ajustes y optimizaciones

Cada fase se describe en las siguientes secciones.

Elige tu estrategia de migración

En este paso, tienes suficiente información para evaluar y seleccionar una de las siguientes estrategias de migración que mejor se adapte a tu caso de uso para cada base de datos:

  • Mantenimiento programado (también llamado migración única o migración Big Bang): Este enfoque es ideal si puedes permitirte un tiempo de inactividad. Esta opción tiene un costo y una complejidad relativamente más bajos, ya que tus cargas de trabajo y servicios no requerirán mucha refactorización. Sin embargo, si la migración falla antes de completarse, debes reiniciar el proceso, lo que prolonga el tiempo de inactividad.

  • Replicación continua (también llamada migración en línea o migración por goteo): Para las bases de datos de misión crítica, esta opción ofrece un menor riesgo de pérdida de datos y un tiempo de inactividad casi nulo. Los esfuerzos se dividen en varias partes, por lo que, si se produce un error, la reversión y la repetición tardan menos tiempo. Sin embargo, la configuración es más compleja y requiere más planificación y tiempo. También se requiere un esfuerzo adicional para refactorizar las aplicaciones que se conectan a tus instancias de base de datos. Considera una de las siguientes variaciones:

    • Usa el enfoque Y (escritura y lectura), que es una forma de migración paralela, en la que se duplican los datos en las instancias de origen y destino durante la migración.
    • Usar un microservicio de acceso a los datos, que reduce el esfuerzo de refactorización que requiere el enfoque Y (escritura y lectura).

Para obtener más información sobre las estrategias de migración de datos, consulta Evalúa los enfoques de migración de datos.

En el siguiente diagrama de flujo, se muestran preguntas de ejemplo que podrías tener cuando decidas la estrategia de migración para una sola base de datos:

Diagrama de flujo para ayudarte a elegir la estrategia de migración.

En el diagrama de flujo anterior, se muestran los siguientes puntos de decisión:

  • ¿Puedes permitirte algún tiempo de inactividad?

    • De lo contrario, adopta la estrategia de migración de replicación continua.
    • Si es así, continúa con el siguiente punto de decisión.

  • ¿Puedes permitirte el tiempo de inactividad que representa el período de migración mientras migras los datos? La ventana de migración representa la cantidad de tiempo que se tarda en crear una copia de seguridad de la base de datos, transferirla a Cloud SQL, restablecerla y, luego, cambiar tus aplicaciones.

    • De lo contrario, adopta la estrategia de migración de replicación continua.
    • Si es así, adopta la estrategia de migración de mantenimiento programado.

Las estrategias pueden variar para diferentes bases de datos, incluso cuando se encuentran en la misma instancia. Una combinación de estrategias puede producir resultados óptimos. Por ejemplo, migra bases de datos pequeñas y de uso poco frecuente con el enfoque de mantenimiento programado, pero usa la replicación continua para las bases de datos de misión crítica en las que el tiempo de inactividad es costoso.

Por lo general, una migración se considera completada cuando se produce el cambio entre la instancia de origen inicial y la instancia de destino. Se detiene cualquier replicación (si se usa) y todas las lecturas y escrituras se realizan en la instancia de destino. Cambiar cuando ambas instancias están sincronizadas significa que no hay pérdida de datos y que el tiempo de inactividad es mínimo.

Para obtener más información sobre las estrategias y las implementaciones de migración de datos, consulta Clasificación de las migraciones de bases de datos.

Las configuraciones de migración que no proporcionan tiempo de inactividad de la aplicación requieren una configuración más complicada. Encuentra el equilibrio adecuado entre la complejidad de la configuración y el tiempo de inactividad programado durante el horario de atención de poco tráfico.

Cada estrategia de migración tiene una compensación y un impacto asociados con el proceso de migración. Por ejemplo, los procesos de replicación implican cierta carga adicional en tus instancias de origen, y tus aplicaciones podrían verse afectadas por el retraso de la replicación. Es posible que las aplicaciones (y los clientes) deban esperar durante el tiempo de inactividad de la aplicación, al menos mientras dure el retraso de replicación antes de usar la base de datos nueva. En la práctica, los siguientes factores podrían aumentar el tiempo de inactividad:

  • Las consultas a la base de datos pueden tardar unos segundos en completarse. En el momento de la migración, es posible que se anulen las consultas en curso.
  • La caché puede tardar un poco en llenarse si la base de datos es grande o tiene una memoria de búfer considerable.
  • Las aplicaciones detenidas en la fuente y reiniciadas en Google Cloud podrían tener un pequeño retraso hasta que se establezca la conexión con la instancia de la base de datos de Google Cloud.
  • Se deben volver a enrutar las rutas de red a las aplicaciones. Según cómo se configuren las entradas de DNS, esto puede tardar un poco. Cuando actualices los registros DNS, reduce el TTL antes de la migración.

Las siguientes prácticas comunes pueden ayudar a minimizar el tiempo de inactividad y el impacto:

  • Busca un período en el que el tiempo de inactividad tenga un impacto mínimo en tus cargas de trabajo. Por ejemplo, fuera del horario de atención habitual, durante los fines de semana o en otros períodos de mantenimiento programados.
  • Identifica las partes de tus cargas de trabajo que pueden someterse a la migración y al cambio de producción en diferentes etapas. Es posible que tus aplicaciones tengan diferentes componentes que se puedan aislar, adaptar y migrar sin impacto. Por ejemplo, frontends, módulos de CRM, servicios de backend y plataformas de informes. Estos módulos podrían tener sus propias bases de datos que se pueden programar para la migración antes o después en el proceso.
  • Si puedes permitirte cierta latencia en la base de datos de destino, considera implementar una migración gradual. Usa transferencias de datos incrementales y por lotes, y adapta parte de tus cargas de trabajo para que funcionen con los datos inactivos en la instancia de destino.
  • Considera refactorizar tus aplicaciones para que admitan un impacto mínimo en la migración. Por ejemplo, adapta tus aplicaciones para que escriban en las bases de datos de origen y de destino y, por lo tanto, implementa una replicación a nivel de la aplicación.

Elige tus herramientas de migración

El factor más importante para una migración exitosa es elegir la herramienta de migración adecuada. Una vez que se haya decidido la estrategia de migración, revisa y elige la herramienta de migración.

Hay muchas herramientas disponibles, cada una optimizada para ciertos casos de uso de migración. Los casos de uso pueden incluir lo siguiente:

  • Estrategia de migración (mantenimiento programado o replicación continua).
  • Motores de base de datos de origen y de destino, y versiones de los motores
  • Son los entornos en los que se encuentran las instancias de origen y de destino.
  • Tamaño de la base de datos. Cuanto más grande sea la base de datos, más tiempo llevará migrar la copia de seguridad inicial.
  • Frecuencia de los cambios en la base de datos.
  • Disponibilidad para usar servicios administrados para la migración.

Para garantizar una migración y una transición sin problemas, puedes usar patrones de implementación de aplicaciones, organización de la infraestructura y aplicaciones de migración personalizadas. Sin embargo, las herramientas especializadas llamadas servicios de migración administrados pueden facilitar el proceso de mover datos, aplicaciones o, incluso, infraestructuras completas de un entorno a otro. Ejecutan la extracción de datos de las bases de datos de origen, transportan los datos de forma segura a las bases de datos de destino y, de manera opcional, pueden modificar los datos durante el tránsito. Con estas capacidades, encapsulan la lógica compleja de la migración y ofrecen capacidades de supervisión de la migración.

Los servicios de migración administrados proporcionan las siguientes ventajas:

  • Minimiza el tiempo de inactividad: Los servicios usan las capacidades de replicación integradas de los motores de base de datos cuando están disponibles y realizan la promoción de réplicas.

  • Garantiza la integridad y la seguridad de los datos: Los datos se transfieren de forma segura y confiable de la base de datos de origen a la de destino.

  • Proporciona una experiencia de migración coherente: Las diferentes técnicas y patrones de migración se pueden consolidar en una interfaz coherente y común con ejecutables de migración de bases de datos, que puedes administrar y supervisar.

  • Ofrece modelos de migración resilientes y probados: Las migraciones de bases de datos son eventos poco frecuentes, pero fundamentales. Para evitar errores de principiante y problemas con las soluciones existentes, puedes usar herramientas de expertos con experiencia, en lugar de compilar una solución personalizada.

  • Optimiza los costos: Los servicios de migración administrados pueden ser más rentables que aprovisionar servidores y recursos adicionales para soluciones de migración personalizadas.

En las siguientes secciones, se describen las recomendaciones de herramientas de migración, que dependen de la estrategia de migración elegida.

Herramientas para migraciones de mantenimiento programadas

En el siguiente diagrama, se muestra un diagrama de flujo con preguntas que pueden ayudarte a elegir la herramienta de migración para una sola base de datos cuando usas una estrategia de migración de mantenimiento programado:

Diagrama de flujo para ayudarte a elegir una herramienta para las migraciones de mantenimiento programadas.

En el diagrama de flujo anterior, se muestran los siguientes puntos de decisión:

  • ¿Prefieres los servicios de migración administrados?
    • Si es así, te recomendamos que uses Database Migration Service.
    • De lo contrario, te recomendamos que migres con las copias de seguridad integradas del motor de base de datos.

El uso de un servicio de migración administrado proporciona algunas ventajas, que se analizan en la sección Elige tus herramientas de migración de este documento.

En las siguientes subsecciones, se describen las herramientas que se pueden usar para las migraciones únicas, junto con sus limitaciones y prácticas recomendadas.

Database Migration Service para la migración de mantenimiento programado

Database Migration Service administra la sincronización inicial y la replicación continua de la captura de datos modificados (CDC), y proporciona el estado de la operación de migración.

Con Database Migration Service, puedes crear trabajos de migración que puedes administrar y verificar. Te recomendamos que uses Database Migration Service, ya que admite migraciones a Cloud SQL para MySQL a través de trabajos de migración únicos. Para bases de datos grandes, puedes usar el paralelismo de volcado de datos en Database Migration Service.

Para obtener más información sobre la arquitectura de migración de bases de datos y sobre Database Migration Service, consulta Migra una base de datos a Cloud SQL para MySQL con Database Migration Service y Fidelidad de la migración para MySQL.

Para obtener más información sobre las limitaciones y los requisitos previos de Database Migration Service, consulta lo siguiente:

Copias de seguridad integradas del motor de base de datos

Cuando se acepta un tiempo de inactividad significativo y las bases de datos de origen son relativamente estáticas, puedes usar las capacidades integradas de volcado y carga (también llamadas a veces copia de seguridad y restablecimiento) del motor de base de datos.

Se requiere un poco de esfuerzo para la configuración y la sincronización, en especial para una gran cantidad de bases de datos, pero las copias de seguridad del motor de base de datos suelen estar disponibles y son fáciles de usar.

Las copias de seguridad del motor de base de datos tienen las siguientes limitaciones generales:

  • Las copias de seguridad pueden ser propensas a errores, en especial si se realizan de forma manual.
  • Los datos no están protegidos si las copias de seguridad no se administran correctamente.
  • Las copias de seguridad carecen de capacidades de supervisión adecuadas.
  • Se requiere esfuerzo para escalar si se migran muchas bases de datos con esta herramienta.

Si eliges este enfoque, ten en cuenta las siguientes limitaciones y prácticas recomendadas:

  • Si tu base de datos es relativamente pequeña (menos de 10 GB), te recomendamos que uses mysqldump. No hay un límite fijo, pero el tamaño ideal de la base de datos para mysqldump suele ser inferior a 10 GB.

  • Si importas bases de datos de más de 10 GB, es posible que necesites otras estrategias para minimizar el tiempo de inactividad de la base de datos. Algunas de estas estrategias son las siguientes:

    • Exporta el esquema y los datos en subsecciones, sin claves secundarias.
    • Aprovecha las marcas de tiempo. Si alguna de tus tablas usa columnas de marca de tiempo, puedes usar una función del comando mysqldump que te permite especificar una cláusula WHERE para filtrar por una columna de marca de tiempo.
    • Considera otros enfoques, como usar las herramientas mydumper y myloader.

Los volcados y las copias de seguridad de la base de datos no suelen incluir cuentas de usuario de MySQL. Cuando te preparas para migrar, revisa todas las cuentas de usuario en la instancia de origen. Por ejemplo, puedes ejecutar el comando SHOW GRANTS para que cada usuario revise el conjunto actual de privilegios y vea si hay alguno restringido en Cloud SQL. Del mismo modo, la herramienta pt-show-grants de Percona también puede mostrar los permisos.

Las restricciones de los privilegios de usuario en Cloud SQL pueden afectar las migraciones cuando se migran objetos de base de datos que tienen un atributo DEFINER. Por ejemplo, un procedimiento almacenado puede tener un definidor con privilegios de administrador para ejecutar comandos de SQL, como cambiar una variable global que no está permitida en Cloud SQL. En casos como este, es posible que debas reescribir el código del procedimiento almacenado o migrar objetos que no sean tablas, como procedimientos almacenados, como un paso aparte de migración. Para obtener más información, consulta Prácticas recomendadas para importar y exportar datos.

Para obtener más información sobre las limitaciones y las prácticas recomendadas, consulta lo siguiente:

Otros enfoques para la migración de mantenimiento programado

Como parte del uso de una importación administrada para configurar la replicación desde una base de datos externa de MySQL, hay una carga inicial de datos de la base de datos externa a la instancia de Cloud SQL. Este enfoque usa un servicio que extrae datos del servidor externo (la instancia de RDS en este caso) y los importa directamente a la instancia de Cloud SQL.

Para las bases de datos grandes (varios TB), una forma más rápida es usar una carga inicial de importación personalizada que use las herramientas mydumper y myloader.

Puedes exportar las tablas de tu base de datos de MySQL a archivos CSV, que luego se pueden importar a Cloud SQL para MySQL. Para exportar datos de tu instancia de RDS, puedes usar AWS Database Migration Service (AWS DMS) y un bucket de S3 como destino.

Para obtener información y pasos detallados, consulta Usa una importación administrada para configurar la replicación desde bases de datos externas.

Herramientas para migraciones de replicación continua

En el siguiente diagrama, se muestra un diagrama de flujo con preguntas que pueden ayudarte a elegir la herramienta de migración para una sola base de datos cuando usas una estrategia de migración de replicación continua:

Diagrama de flujo para ayudarte a elegir una herramienta para las migraciones de replicación continua.

En el diagrama de flujo anterior, se muestran los siguientes puntos de decisión:

  • ¿Prefieres usar servicios de migración administrados?

    • Si es así, ¿puedes permitirte unos segundos de tiempo de inactividad de escritura, según la cantidad de tablas de tu base de datos?

      • Si es así, usa Database Migration Service.
      • De lo contrario, explora otras opciones de migración.

    • De lo contrario, debes evaluar si se admite la replicación integrada del motor de base de datos:

      • Si es así, te recomendamos que uses la replicación integrada.
      • De lo contrario, te recomendamos que explores otras opciones de migración.

En las siguientes secciones, se describen las herramientas que se pueden usar para las migraciones continuas, junto con sus limitaciones y prácticas recomendadas.

Database Migration Service para la migración de replicación continua

Database Migration Service proporciona asistencia sin problemas para las migraciones continuas a través de su uso de tipos de trabajos de migración continua. Solo se pueden promover los trabajos de migración continuos, lo que indica que la replicación se detendrá.

Si eliges esta herramienta, ten en cuenta las siguientes restricciones y prácticas recomendadas:

  • Evita las transacciones de larga duración durante la migración. En esos casos, te recomendamos migrar desde una réplica de lectura si no migras desde AWS Aurora.
  • Para obtener una lista completa de las limitaciones, consulta Limitaciones conocidas.

Replicación integrada del motor de base de datos

La replicación integrada del motor de base de datos es una opción alternativa a Database Migration Service para una migración continua.

La replicación de bases de datos representa el proceso de copiar y distribuir datos de una base de datos llamada base de datos principal a otras bases de datos llamadas réplicas. Su objetivo es aumentar la accesibilidad de los datos y mejorar la tolerancia a errores y la confiabilidad de un sistema de base de datos. Aunque la migración de bases de datos no es el propósito principal de la replicación de bases de datos, se puede usar con éxito como una herramienta para alcanzar este objetivo. La replicación de bases de datos suele ser un proceso continuo que se produce en tiempo real a medida que se insertan, actualizan o borran datos en la base de datos principal. Se puede realizar como una operación única o como una secuencia de operaciones por lotes.

La mayoría de los motores de bases de datos modernos implementan diferentes formas de lograr la replicación de bases de datos. Un tipo de replicación se puede lograr copiando y enviando el registro de escritura anticipada o el registro de transacciones de la instancia principal a sus réplicas. Este enfoque se denomina replicación física o binaria. Otros tipos de replicación funcionan distribuyendo las sentencias de SQL sin procesar que recibe una base de datos principal, en lugar de replicar los cambios a nivel del sistema de archivos.

Cloud SQL admite la replicación para MySQL. Sin embargo, existen algunos requisitos previos y limitaciones.

Requisitos previos:

  • Asegúrate de usar MySQL 5.5, 5.6, 5.7 o 8.0 en tu instancia de Amazon RDS o Amazon Aurora.
  • Asegúrate de que los registros binarios estén habilitados.
  • Para acelerar la fase inicial de volcado completo, elige un nivel de máquina lo suficientemente grande desde la perspectiva del tamaño de la CPU y la memoria.
  • Si necesitas acelerar la fase de CDC, puedes intentar configurar la replicación paralela y habilitar el vaciado de alto rendimiento.
  • Si la réplica de Cloud SQL está habilitada con direcciones IP internas porque la dirección IP saliente no es estática, configura el firewall del servidor de Amazon RDS o Amazon Aurora para permitir el rango de IP internas asignadas para el acceso privado a servicios de la red de VPC que la réplica de Cloud SQL usa como su red privada. Para obtener más información, consulta Acerca de la replicación desde un servidor externo y Configura el acceso privado a servicios.

Limitaciones:

  • Si tienes tablas grandes individuales y muchos índices secundarios en tu base de datos, el volcado completo inicial podría tardar más.
  • Si el servidor externo contiene cláusulas DEFINER (vistas, eventos, activadores o procedimientos almacenados), según el orden en el que se ejecuten estas declaraciones, la replicación podría fallar. Obtén más información sobre el uso de DEFINER y las posibles soluciones alternativas en Cloud SQL.
  • InnoDB es el único motor de base de datos compatible con Cloud SQL. La migración de MyISAM puede causar incoherencia de datos y requerir una validación de datos. Consulta Cómo convertir tablas de MyISAM en InnoDB.

Otros enfoques para la migración de replicación continua

Otros enfoques de migración de replicación continua incluyen los siguientes:

  • Refactoriza tus aplicaciones para realizar Y (escritura y lectura) o usa un microservicio de acceso a datos.

    • Tus aplicaciones realizan la replicación continua.
    • El esfuerzo de migración se enfoca en la refactorización o el desarrollo de herramientas que se conectan a tus instancias de base de datos.
    • Luego, las aplicaciones de lectura se refactorizan y se implementan de forma gradual para usar la instancia de destino.

  • Replica los cambios casi en tiempo real de tu instancia de MySQL con Datastream.

    • Datastream es un servicio de replicación y CDC sin servidores que se puede usar con Amazon RDS o Amazon Aurora para replicar y sincronizar datos.
    • Usa Datastream para replicar los cambios de tu instancia de MySQL en BigQuery o Cloud Storage y, luego, usa Dataflow o Managed Service para Apache Spark para transferir los datos a tu instancia de Cloud SQL.

Para obtener más información sobre la replicación con Datastream, consulta los siguientes recursos:

Herramientas de terceros para la migración de replicación continua

En algunos casos, puede ser mejor usar una herramienta de terceros para la mayoría de los motores de base de datos. Estos casos pueden ser si prefieres usar un servicio de migración administrado y necesitas asegurarte de que la base de datos de destino siempre esté sincronizada casi en tiempo real con la fuente, o si necesitas transformaciones más complejas, como la limpieza, la reestructuración y la adaptación de datos durante el proceso de migración.

Si decides usar una herramienta de terceros, elige una de las siguientes recomendaciones, que puedes usar para la mayoría de los motores de bases de datos.

Striim es una plataforma en memoria de extremo a extremo para recopilar, filtrar, transformar, enriquecer, agregar, analizar y entregar datos en tiempo real:

  • Ventajas:

    • Maneja grandes volúmenes de datos y migraciones complejas.
    • Captura de datos modificados integrada para SQL Server.
    • Plantillas de conexión preconfiguradas y canalizaciones sin código.
    • Capaz de manejar bases de datos grandes y esenciales que operan con una carga transaccional pesada.
    • Entrega “exactamente una vez”

  • Desventajas:

Para obtener más información sobre Striim, consulta Ejecuta Striim en Google Cloud.

Debezium es una plataforma distribuida de código abierto para la CDC y puede transmitir cambios de datos a suscriptores externos:

  • Ventajas:

    • Es de código abierto.
    • Sólida asistencia de la comunidad
    • Es rentable.
    • Control detallado de filas, tablas o bases de datos.
    • Se especializa en la captura de cambios en tiempo real a partir de los registros de transacciones de la base de datos.

  • Desventajas:

    • Requiere experiencia específica con Kafka y ZooKeeper.
    • Entrega de cambios de datos al menos una vez, lo que significa que necesitas controlar los duplicados.
    • Configuración manual de la supervisión con Grafana y Prometheus
    • No se admite la replicación por lotes incremental.

Para obtener más información sobre las migraciones de Debezium, consulta Replicación de datos casi en tiempo real con Debezium.

Fivetran es una plataforma de transferencia de datos automatizada para mover datos fuera de las plataformas de datos en la nube y entre ellas.

  • Ventajas:

    • Plantillas de conexión preconfiguradas y canalizaciones sin código.
    • Propaga cualquier cambio de esquema de la base de datos de origen a la de destino.
    • Entrega de tipo "exactamente una vez" de los cambios en los datos, lo que significa que no necesitas controlar los duplicados.

  • Desventajas:

    • No es de código abierto.
    • La compatibilidad con la transformación de datos complejos es limitada.

Define el plan y el cronograma de migración

Para una migración de bases de datos y una transición de producción exitosas, te recomendamos que prepares un plan de migración integral y bien definido. Para ayudar a reducir el impacto en tu empresa, te recomendamos que crees una lista de todos los elementos de trabajo necesarios.

Definir el alcance de la migración revela las tareas de trabajo que debes realizar antes, durante y después del proceso de migración de la base de datos. Por ejemplo, si decides no migrar ciertas tablas de una base de datos, es posible que necesites tareas previas o posteriores a la migración para implementar este filtrado. También te aseguras de que la migración de la base de datos no afecte tu Acuerdo de Nivel de Servicio (ANS) existente ni el plan de continuidad empresarial.

Te recomendamos que la documentación de planificación de la migración incluya los siguientes documentos:

  • Documento de diseño técnico (TDD)
  • Matriz RACI
  • Cronograma (como un plan de cuenta regresiva)

Las migraciones de bases de datos son un proceso iterativo, y las primeras migraciones suelen ser más lentas que las posteriores. Por lo general, las migraciones bien planificadas se ejecutan sin problemas, pero pueden surgir problemas no planificados. Te recomendamos que siempre tengas un plan de reversión. Como práctica recomendada, sigue la guía de Migra a Google Cloud: Prácticas recomendadas para validar un plan de migración.

TDD

En el TDD, se documentan todas las decisiones técnicas que se tomarán para el proyecto. Incluye lo siguiente en el TDD:

  • Requisitos y nivel de importancia de la empresa
  • Objetivo de tiempo de recuperación (RTO)
  • Objetivo de punto de recuperación (RPO)
  • Detalles de la migración de la base de datos
  • Estimaciones del esfuerzo de migración
  • Recomendaciones para la validación de la migración

Matriz RACI

Algunos proyectos de migración requieren una matriz RACI, que es un documento común de administración de proyectos que define qué personas o grupos son responsables de las tareas y los entregables dentro del proyecto de migración.

Cronograma

Prepara un cronograma para cada base de datos que se deba migrar. Incluye todas las tareas de trabajo que se deben realizar, y define las fechas de inicio y las fechas de finalización estimadas.

Para cada entorno de migración, te recomendamos que crees un plan de cuenta regresiva. Un plan T-minus se estructura como un cronograma de cuenta regresiva y enumera todas las tareas necesarias para completar el proyecto de migración, junto con los grupos responsables y la duración estimada.

El cronograma debe tener en cuenta no solo la ejecución de las tareas de preparación previas a la migración, sino también las tareas de validación, auditoría o prueba que se realizan después de que se lleva a cabo la transferencia de datos.

La duración de las tareas de migración suele depender del tamaño de la base de datos, pero también hay otros aspectos que se deben tener en cuenta, como la complejidad de la lógica empresarial, el uso de la aplicación y la disponibilidad del equipo.

Un plan de cuenta regresiva podría verse de la siguiente manera:

Fecha Fase Categoría Tasks Rol T-minus Estado
1/11/2023 Antes de la migración Evaluación Crea un informe de evaluación Equipo de descubrimiento -21 Completado
7/11/2023 Antes de la migración Preparación del destino Diseñar el entorno de destino según lo descrito en el documento de diseño Equipo de migración -14 Completado
15/11/2023 Antes de la migración Administración de la empresa Fecha de migración y aprobación de T-Minus Directivos -6 Completado
18/11/2023 Migración Configura DMS Crea perfiles de conexión Ingeniero de migración a la nube -3 Completado
19/11/2023 Migración Configura DMS Compila y, luego, inicia trabajos de migración Ingeniero de migración a la nube -2 Sin iniciar
19/11/2023 Migración Supervisa DMS Supervisa los trabajos de DMS y los cambios de DDL en la instancia de origen Ingeniero de migración a la nube -2 Sin iniciar
21/11/2023 Migración Migración de sistemas de DMS Asciende la réplica de DMS Ingeniero de migración a la nube 0 Sin iniciar
21/11/2023 Migración Validación de la migración Validación de la migración de bases de datos Equipo de migración 0 Sin iniciar
21/11/2023 Migración Prueba de la aplicación Ejecuta pruebas de capacidades y rendimiento Equipo de migración 0 Sin iniciar
22/11/2023 Migración Administración de la empresa Validación de la migración: GO o NO GO Equipo de migración 1 Sin iniciar
23/11/2023 Después de la migración Valida la supervisión Configura la supervisión Equipo de infraestructura 2 Sin iniciar
25/11/2023 Después de la migración Seguridad Quita la cuenta de usuario de DMS Equipo de seguridad 4 Sin iniciar

Migraciones de varias bases de datos

Si tienes varias bases de datos para migrar, tu plan de migración debe contener tareas para todas las migraciones.

Te recomendamos que comiences el proceso migrando una base de datos más pequeña, idealmente no crítica para la misión. Este enfoque puede ayudarte a desarrollar tus conocimientos y confianza en el proceso de migración y las herramientas. También puedes detectar cualquier falla en el proceso en las etapas iniciales del programa de migración general.

Si tienes varias bases de datos para migrar, los cronogramas se pueden paralelizar. Por ejemplo, para acelerar el proceso de migración, puedes elegir migrar un grupo de bases de datos pequeñas, estáticas o menos críticas para la misión al mismo tiempo, como se muestra en el siguiente diagrama.

Tareas de migración de bases de datos paralelas.

En el ejemplo que se muestra en el diagrama, las bases de datos de la 1 a la 4 son un grupo de bases de datos pequeñas que se migran al mismo tiempo.

Define las tareas de preparación

Las tareas de preparación son todas las actividades que debes completar para cumplir con los requisitos previos de la migración. Sin las tareas de preparación, la migración no se puede realizar o la migración da como resultado que la base de datos migrada esté en un estado inutilizable.

Las tareas de preparación se pueden clasificar de la siguiente manera:

  • Preparativos y requisitos previos de la instancia de Amazon RDS o Amazon Aurora
  • Preparación y requisitos previos de la base de datos de origen
  • Configuración de Cloud SQL
  • Configuración específica de la migración

Preparación y requisitos previos de la instancia de Amazon RDS o Amazon Aurora

Considera las siguientes tareas comunes de configuración y requisitos previos:

  • Según tu ruta de migración, es posible que debas permitir conexiones remotas en tus instancias de RDS. Si tu instancia de RDS está configurada para ser privada en tu VPC, debe existir conectividad privada RFC 1918 entre Amazon y Google Cloud.

  • Es posible que debas configurar un grupo de seguridad nuevo para permitir conexiones remotas en los puertos requeridos.

    • De forma predeterminada, en AWS, el acceso a la red está desactivado para las instancias de base de datos.
    • Puedes especificar reglas en un grupo de seguridad que permitan el acceso desde un rango de direcciones IP, un puerto o un grupo de seguridad. Las mismas reglas se aplican a todas las instancias de base de datos asociadas con ese grupo de seguridad.

  • Asegúrate de tener suficiente espacio en el disco para almacenar en búfer los registros de WAL durante la operación de carga completa en tu instancia de Amazon RDS.

  • Para obtener resultados óptimos, considera migrar desde una réplica de lectura, a menos que migres desde Amazon Aurora. Además, te recomendamos que comiences el proceso de migración durante un período de actividad reducida de la base de datos.

  • MySQL limita el nombre de host a 60 caracteres. Los nombres de host de la base de datos de Amazon RDS suelen tener más de 60 caracteres. Si este es el caso de la base de datos que estás migrando, configura un redireccionamiento de DNS para crear un registro CNAME que asocie tu nombre de dominio con el nombre de dominio de tu instancia de base de datos de RDS.

  • Si usas la replicación integrada, debes configurar tu instancia de Amazon RDS o Amazon Aurora para la replicación. La replicación integrada o las herramientas que la usan necesitan que el registro binario para MySQL esté configurado en ROW.

  • Si usas herramientas de terceros, por lo general, se requieren parámetros de configuración iniciales antes de usar la herramienta. Consulta la documentación de la herramienta de terceros.

Para obtener más información sobre la preparación y los requisitos previos de la instancia, consulta Configura el servidor externo para la replicación de MySQL.

Preparación y requisitos previos de la base de datos de origen

  • Si eliges usar Database Migration Service, debes configurar tu base de datos de origen antes de conectarte a ella. Revisa los trabajos de migración antes de implementarlos. Para obtener más información, consulta Configura tu fuente para MySQL.
  • Según el motor de base de datos, es posible que debas cambiar ciertas funciones. Por ejemplo, Cloud SQL para MySQL solo admite el motor de base de datos InnoDB. Debes cambiar las tablas de MyISAM a InnoDB.
  • Algunas herramientas de migración de terceros requieren que todas las columnas LOB admitan valores nulos. Se debe quitar la restricción de las columnas LOB que sean NOT NULL durante la migración.

  • Toma mediciones de referencia en tu entorno de origen en uso de producción. Ten en cuenta lo siguiente:

    • Mide el tamaño de tus datos y el rendimiento de tu carga de trabajo. ¿Cuánto tiempo tardan las consultas o transacciones importantes, en promedio? ¿Cuánto tiempo durante los horarios pico?
    • Documenta las mediciones de referencia para compararlas más adelante y ayudarte a decidir si la fidelidad de la migración de la base de datos es satisfactoria. Decide si puedes cambiar tus cargas de trabajo de producción y retirar tu entorno de origen, o si aún lo necesitas para fines de resguardo.

Configuración de Cloud SQL

Elige con cuidado el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL para MySQL de destino para que coincida con la fuente para necesidades de rendimiento similares. Presta especial atención al tamaño del disco y a la capacidad de procesamiento, las IOPS y la cantidad de CPU virtuales. Un tamaño incorrecto puede generar tiempos de migración prolongados, problemas de rendimiento de la base de datos, errores de la base de datos y problemas de rendimiento de la aplicación.

Debes confirmar las siguientes propiedades y requisitos antes de crear tus instancias de Cloud SQL, ya que no se pueden cambiar más adelante sin volver a crearlas.

  • Elige con cuidado el proyecto y la región de tus instancias de Cloud SQL de destino. Las instancias de Cloud SQL no se pueden migrar entre proyectos y regiones de Google Cloud sin transferencia de datos.
  • Migra a una versión principal coincidente en Cloud SQL. Por ejemplo, si tu fuente usa MySQL 8.0.34 en Amazon RDS o Amazon Aurora, debes migrar a Cloud SQL para MySQL versión 8.0.34.
  • Replica la información del usuario por separado si usas copias de seguridad integradas del motor de base de datos o Database Migration Service. Cloud SQL administra los usuarios con la IAM de Google. Para obtener más detalles, revisa las limitaciones en la sección Copias de seguridad integradas del motor de base de datos.
  • Revisa las marcas de configuración del motor de base de datos y compara sus valores de instancia de origen y de destino. Asegúrate de comprender su impacto y si deben ser iguales o no. Por ejemplo, te recomendamos ejecutar el comando SHOW VARIABLES en tu base de datos de origen antes de la migración y, luego, volver a ejecutarlo en la base de datos de Cloud SQL. Actualiza la configuración de las marcas según sea necesario en la base de datos de Cloud SQL para replicar la configuración de origen. Ten en cuenta que no todas las marcas de MySQL están permitidas en una instancia de Cloud SQL.

Para obtener más información sobre la configuración de Cloud SQL, consulta los siguientes vínculos:

Configuración específica de la migración

Si importas archivos de volcado de SQL a Cloud SQL, es posible que debas crear un bucket de Cloud Storage. El bucket almacena el volcado de la base de datos.

Si usas la replicación, debes asegurarte de que la réplica de Cloud SQL tenga acceso a tu base de datos principal. Este acceso se puede lograr a través de las opciones de conectividad documentadas.

Según tu situación y nivel de importancia, es posible que debas implementar una situación de resguardo, que suele incluir invertir la dirección de la replicación. En este caso, es posible que necesites un mecanismo de replicación adicional de Cloud SQL a tu instancia de Amazon de origen.

Para la mayoría de las herramientas de terceros, debes aprovisionar recursos específicos de migración. Por ejemplo, para Striim, debes usar Google Cloud Marketplace para comenzar. Luego, para configurar tu entorno de migración en Striim, puedes usar Flow Designer para crear y cambiar aplicaciones, o puedes seleccionar una plantilla existente. Las aplicaciones también se pueden programar con el lenguaje de programación Tungsten Query Language (TQL). Con un panel de validación de datos, puedes obtener una representación visual de los datos que maneja tu aplicación de Striim.

Puedes retirar de servicio los recursos que conectan tu entorno de Amazon y Google Cloud después de que se complete y valide la migración.

Para obtener más información, consulta lo siguiente:

Define las tareas de ejecución

Las tareas de ejecución implementan el trabajo de migración en sí. Las tareas dependen de la herramienta de migración que elijas, como se describe en las siguientes subsecciones.

Copias de seguridad integradas del motor de base de datos

Para realizar una migración única, usa la utilidad mysqldump para crear una copia de seguridad, que copia los datos de Amazon RDS en tu computadora cliente local. Para obtener instrucciones, consulta Importa un archivo de volcado de SQL a Cloud SQL para MySQL.

Puedes verificar el estado de las operaciones de importación y exportación de tu instancia de Cloud SQL.

Trabajos de migración de Database Migration Service

Define y configura trabajos de migración en Database Migration Service para migrar datos de una instancia de origen a la base de datos de destino. Los trabajos de migración se conectan a la instancia de la base de datos de origen a través de perfiles de conexión definidos por el usuario.

Prueba todos los requisitos previos para asegurarte de que el trabajo se pueda ejecutar correctamente. Elige un momento en el que tus cargas de trabajo puedan tolerar un breve tiempo de inactividad para la migración y la transición a producción.

En Database Migration Service, la migración comienza con la copia de seguridad completa y la carga iniciales, seguidas de un flujo continuo de cambios de la instancia de base de datos de origen a la de destino.

Database Migration Service requiere unos segundos para obtener el bloqueo de lectura en todas las tablas de tu instancia de origen de Amazon RDS o Amazon Aurora que necesita para realizar el volcado completo inicial de forma coherente. Para lograr el bloqueo de lectura, es posible que se necesite un tiempo de inactividad de escritura de entre 1 y 49 segundos. Los tiempos de inactividad dependen de la cantidad de tablas de la base de datos: 1 segundo corresponde a 100 tablas y 9 segundos, a 10,000 tablas.

El proceso de migración con Database Migration Service finaliza con la operación de ascenso. Cuando se asciende una instancia de base de datos, se desconecta la base de datos de destino del flujo de cambios que provienen de la base de datos de origen y, luego, la instancia de destino, que ahora es independiente, se asciende a una instancia principal. Este enfoque también se denomina, a veces, cambio de producción.

Para obtener más información sobre los trabajos de migración en Database Migration Service, consulta los siguientes vínculos:

Para obtener un proceso detallado de configuración de la migración, consulta Migra una base de datos a Cloud SQL para MySQL con Database Migration Service. En Database Migration Service, la migración se realiza iniciando y ejecutando un trabajo de migración.

Replicación integrada del motor de base de datos

Puedes usar la replicación integrada de Amazon RDS en una instancia externa de Cloud SQL para MySQL.

En el caso de MySQL, primero debes comenzar con un volcado inicial que se pueda almacenar en un bucket de Cloud Storage y, luego, importar los datos a Cloud SQL para MySQL. Luego, inicias el proceso de replicación.

Supervisa la replicación y detén las operaciones de escritura en tu instancia de origen en el momento adecuado. Vuelve a verificar el estado de la replicación para asegurarte de que se hayan replicado todos los cambios y, luego, asciende la réplica de Cloud SQL para MySQL a una instancia independiente para completar la migración.

Para obtener instrucciones detalladas sobre cómo configurar la replicación integrada desde un servidor externo, como Amazon RDS o Amazon Aurora para MySQL, consulta Acerca de la replicación desde un servidor externo y Configura Cloud SQL y el servidor externo para la replicación.

Para obtener más información y orientación, consulta lo siguiente:

Herramientas de terceros

Define las tareas de ejecución para la herramienta de terceros que elegiste.

Esta sección se enfoca en Striim como ejemplo. Striim usa aplicaciones que adquieren datos de varias fuentes, los procesan y, luego, los entregan a otras aplicaciones o destinos.

Las aplicaciones se pueden crear de forma gráfica con el cliente web y contienen fuentes, destinos y otros componentes lógicos organizados en uno o más flujos.

Para configurar tu entorno de migración en Striim, puedes usar la función Flow Designer para crear y cambiar aplicaciones, o puedes seleccionar entre una serie de plantillas preexistentes. Las aplicaciones también se pueden programar con el lenguaje de programación TQL.

Puedes obtener una representación visual de los datos que controla tu aplicación de Striim con un panel de validación de datos.

Para comenzar rápidamente con Striim en Google Cloud, consulta Ejecuta Striim en Google Cloud. Para obtener más información sobre los conceptos básicos de Striim, consulta Conceptos de Striim. Asegúrate de leer también la guía de prácticas recomendadas para cambiar de una carga inicial a una replicación continua.

Ten en cuenta las siguientes prácticas recomendadas para la migración de datos:

  • Informa a los equipos involucrados cada vez que comience y finalice cada uno de los pasos del plan.
  • Si alguno de los pasos tarda más de lo esperado, compara el tiempo transcurrido con la cantidad máxima de tiempo asignada para cada paso. Cuando esto suceda, envía actualizaciones intermedias periódicas a los equipos involucrados.
  • Si el intervalo de tiempo es mayor que la cantidad máxima de tiempo reservada para cada paso del plan, considera revertir el proceso.
  • Toma decisiones de "continuar o no continuar" para cada paso del plan de migración y transición.
  • Considera acciones de reversión o situaciones alternativas para cada uno de los pasos.

Define situaciones de resguardo

Define elementos de acción de resguardo para cada tarea de ejecución de la migración, de modo que se proteja contra problemas imprevistos que puedan ocurrir durante el proceso de migración. Las tareas de resguardo suelen depender de la estrategia de migración y las herramientas que se usen.

La reversión puede requerir un esfuerzo significativo. Como práctica recomendada, no realices la transición a producción hasta que los resultados de las pruebas sean satisfactorios. Tanto la migración de la base de datos como la situación de resguardo deben probarse de forma adecuada para evitar una interrupción grave.

Define los criterios de éxito y asigna un tiempo límite a todas las tareas de ejecución de la migración. Realizar una ejecución de prueba de migración ayuda a recopilar información sobre los tiempos esperados para cada tarea. Por ejemplo, para una migración de mantenimiento programada, puedes permitirte el tiempo de inactividad que representa el período de migración. Sin embargo, es importante planificar tu próxima acción en caso de que el trabajo de migración único o el restablecimiento de la copia de seguridad falle a mitad de camino. Según el tiempo que haya transcurrido del tiempo de inactividad planificado, es posible que debas posponer la migración si la tarea de migración no finaliza en el tiempo esperado.

Un plan de resguardo suele referirse a revertir la migración después de realizar la transición a producción, si aparecen problemas en la instancia de destino. Si implementas un plan de resguardo, recuerda que se debe tratar como una migración completa de la base de datos, incluidas la planificación y las pruebas.

Si decides no tener un plan de resguardo, asegúrate de comprender las posibles consecuencias. No tener un plan de resguardo puede agregar un esfuerzo imprevisto y causar interrupciones evitables en tu proceso de migración.

Aunque un resguardo es un último recurso y la mayoría de las migraciones de bases de datos no terminan usándolo, te recomendamos que siempre tengas una estrategia de resguardo.

Resguardo simple

En esta estrategia de resguardo, vuelves a cambiar tus aplicaciones a la instancia de la base de datos de origen original. Adopta esta estrategia si puedes permitirte un tiempo de inactividad cuando reviertes o si no necesitas las transacciones confirmadas en el nuevo sistema de destino.

Si necesitas todos los datos escritos en tu base de datos de destino y puedes permitirte un tiempo de inactividad, puedes considerar detener las operaciones de escritura en tu instancia de base de datos de destino, realizar copias de seguridad integradas y restablecerlas en tu instancia de origen y, luego, volver a conectar tus aplicaciones a la instancia de base de datos de origen inicial. Según la naturaleza de tu carga de trabajo y la cantidad de datos escritos en la instancia de la base de datos de destino, podrías incorporarla a tu sistema de base de datos de origen inicial más adelante, en especial si tus cargas de trabajo no dependen de ningún momento específico de creación de registros ni de ninguna restricción de ordenamiento temporal.

Replicación inversa

En esta estrategia, replicas las operaciones de escritura que se producen en tu nueva base de datos de destino después de la transición de producción a tu base de datos de origen inicial. De esta manera, mantienes la fuente original sincronizada con la nueva base de datos de destino y las escrituras se realizan en la nueva instancia de la base de datos de destino. Su principal desventaja es que no puedes probar el flujo de replicación hasta después de realizar la migración de sistemas a la instancia de la base de datos de destino, por lo que no permite realizar pruebas de extremo a extremo y tiene un período breve sin resguardo.

Elige este enfoque cuando aún puedas conservar tu instancia de origen durante un tiempo y migres con la migración de replicación continua.

Replicación de reenvío

Esta estrategia es una variación de la replicación inversa. Replica las escrituras en tu nueva base de datos de destino en una tercera instancia de base de datos de tu elección. Puedes dirigir tus aplicaciones a esta tercera base de datos, que se conecta al servidor y ejecuta consultas de solo lectura mientras el servidor no está disponible. Puedes usar cualquier mecanismo de replicación, según tus necesidades. La ventaja de este enfoque es que se puede probar por completo de extremo a extremo.

Adopta este enfoque cuando quieras tener una alternativa de resguardo en todo momento o cuando debas descartar tu base de datos de origen inicial poco después de la transición a producción.

Escrituras duplicadas

Si eliges una estrategia de migración de microservicio de acceso a datos o Y (escritura y lectura), este plan de resguardo ya está configurado. Esta estrategia es más complicada, ya que debes refactorizar las aplicaciones o desarrollar herramientas que se conecten a tus instancias de base de datos.

Tus aplicaciones escriben en las instancias de base de datos de origen y de destino iniciales, lo que te permite realizar una transición gradual de producción hasta que uses solo tus instancias de base de datos de destino. Si hay algún problema, puedes volver a conectar tus aplicaciones a la fuente inicial sin tiempo de inactividad. Puedes descartar la fuente inicial y el mecanismo de escritura duplicado cuando consideres que la migración se realizó sin problemas.

Recomendamos este enfoque cuando es fundamental no tener tiempo de inactividad por migración, contar con un resguardo confiable y cuando tienes tiempo y recursos para realizar la refactorización de la aplicación.

Realizar pruebas y validaciones

Los objetivos de este paso son probar y validar lo siguiente:

  • Migración exitosa de los datos en la base de datos.
  • Integración con las aplicaciones existentes después de que se cambien para usar la nueva instancia de destino.

Define los factores clave de éxito, que son subjetivos para tu migración. A continuación, se incluyen ejemplos de factores subjetivos:

  • Qué datos migrar En algunas cargas de trabajo, es posible que no sea necesario migrar todos los datos. Es posible que no quieras migrar datos que ya están agregados, redundantes, archivados o antiguos. Puedes archivar esos datos en un bucket de Cloud Storage como copia de seguridad.
  • Un porcentaje aceptable de pérdida de datos. Esto se aplica, en particular, a los datos que se usan para las cargas de trabajo de análisis, en las que perder parte de los datos no afecta las tendencias generales ni el rendimiento de tus cargas de trabajo.
  • Criterios de calidad y cantidad de datos, que puedes aplicar a tu entorno de origen y comparar con el entorno de destino después de la migración.
  • Criterios de rendimiento Algunas transacciones comerciales pueden ser más lentas en el entorno de destino, pero el tiempo de procesamiento sigue estando dentro de las expectativas definidas.

Es posible que los parámetros de configuración de almacenamiento en tu entorno de origen no se asignen directamente a los destinos del entorno deGoogle Cloud . Por ejemplo, los parámetros de configuración de los volúmenes de SSD de uso general (gp2 y gp3) con rendimiento de ráfaga de IOPS o SSD de IOPS aprovisionadas. Para comparar y ajustar correctamente el tamaño de las instancias de destino, compara tus instancias de origen, tanto en la fase de evaluación como en la de validación.

En el proceso de comparativas, aplicas secuencias de operaciones similares a las de producción en las instancias de la base de datos. Durante este tiempo, capturas y procesas métricas para medir y comparar el rendimiento relativo de los sistemas de origen y de destino.

Para las configuraciones convencionales basadas en servidores, usa las mediciones pertinentes observadas durante las cargas máximas. Para los modelos de capacidad de recursos flexibles, como Aurora Serverless, considera consultar los datos de métricas históricos para observar tus necesidades de escalamiento.

Las siguientes herramientas se pueden usar para realizar pruebas, validaciones y comparativas de bases de datos:

  • HammerDB: Es una herramienta de código abierto para realizar comparativas y pruebas de carga de bases de datos. Admite cargas de trabajo transaccionales y analíticas complejas, según los estándares de la industria, en varios motores de base de datos (tanto TPROC-C como TPROC-H). HammerDB tiene documentación detallada y una amplia comunidad de usuarios. Puedes compartir y comparar los resultados en varios motores de base de datos y parámetros de configuración de almacenamiento. Para obtener más información, consulta Pruebas de carga de SQL Server con HammerDB y Compara el rendimiento de Amazon RDS SQL Server con HammerDB.
  • Herramienta de comparativas DBT2: Comparativas especializadas para MySQL. Un conjunto de kits de carga de trabajo de base de datos imita una aplicación para una empresa que posee almacenes y que implica una combinación de transacciones de lectura y escritura. Usa esta herramienta si quieres usar una prueba de carga de procesamiento de transacciones en línea (OLTP) lista para usar.
  • DbUnit: Es una herramienta de prueba de unidades de código abierto que se usa para probar las interacciones de base de datos relacional en Java. La configuración y el uso son sencillos, y admite varios motores de bases de datos (MySQL, PostgreSQL, SQL Server y otros). Sin embargo, la ejecución de la prueba puede ser lenta en ocasiones, según el tamaño y la complejidad de la base de datos. Recomendamos esta herramienta cuando la simplicidad es importante.
  • DbFit: un framework de pruebas de bases de datos de código abierto que admite el desarrollo de código basado en pruebas y las pruebas automatizadas. Usa una sintaxis básica para crear casos de prueba y ofrece pruebas basadas en datos, control de versión y generación de informes de resultados de pruebas. Sin embargo, la compatibilidad con consultas y transacciones complejas es limitada y no tiene una gran asistencia de la comunidad ni documentación extensa, en comparación con otras herramientas. Te recomendamos esta herramienta si tus consultas no son complejas y quieres realizar pruebas automatizadas y, luego, integrarlas en tu proceso de integración y entrega continuas.

Para ejecutar una prueba de extremo a extremo, incluida la prueba del plan de migración, siempre realiza un ejercicio de ejecución de prueba de migración. Una ejecución de prueba realiza la migración de la base de datos de alcance completo sin cambiar ninguna carga de trabajo de producción y ofrece las siguientes ventajas:

  • Te permite asegurarte de que todos los objetos y parámetros de configuración se migren correctamente.
  • Te ayuda a definir y ejecutar tus casos de prueba de migración.
  • Ofrece estadísticas sobre el tiempo necesario para la migración real, de modo que puedas calibrar tu cronograma.
  • Representa una oportunidad para probar, validar y adaptar el plan de migración. A veces, no puedes planificar todo con anticipación, por lo que esto te ayuda a detectar cualquier brecha.

Las pruebas de datos se pueden realizar en un conjunto pequeño de las bases de datos que se migrarán o en todo el conjunto. Según la cantidad total de bases de datos y las herramientas que se usen para implementar su migración, puedes decidir adoptar un enfoque basado en el riesgo. Con este enfoque, realizas la validación de datos en un subconjunto de bases de datos migradas a través de la misma herramienta, en especial si esta herramienta es un servicio de migración administrado.

Para realizar pruebas, debes tener acceso a las bases de datos de origen y de destino, y realizar las siguientes tareas:

  • Compara los esquemas de origen y destino. Verifica si existen todas las tablas y los ejecutables. Verifica los recuentos de filas y compara los datos a nivel de la base de datos.
  • Ejecutar secuencias de comandos de validación de datos personalizadas
  • Prueba que los datos migrados también sean visibles en las aplicaciones que cambiaron para usar la base de datos de destino (los datos migrados se leen a través de la aplicación).
  • Realiza pruebas de integración entre las aplicaciones cambiadas y la base de datos de destino probando varios casos de uso. Estas pruebas incluyen la lectura y la escritura de datos en las bases de datos de destino a través de las aplicaciones para que las cargas de trabajo admitan por completo los datos migrados junto con los datos recién creados.
  • Prueba el rendimiento de las consultas de base de datos más utilizadas para observar si hay alguna degradación debido a parámetros de configuración incorrectos o un tamaño incorrecto.

Lo ideal es que todos estos casos de prueba de migración estén automatizados y se puedan repetir en cualquier sistema de origen. El paquete de casos de prueba automatizados se adapta para ejecutarse en las aplicaciones cambiadas.

Si usas Database Migration Service como herramienta de migración, consulta Verifica una migración.

Herramienta de validación de datos

Para realizar la validación de datos, te recomendamos que uses la Herramienta de validación de datos (DVT). La DVT es una herramienta de código abierto de la CLI de Python, respaldada por Google, que proporciona una solución automatizada y repetible para la validación en diferentes entornos.

La DVT puede ayudar a optimizar el proceso de validación de datos, ya que ofrece funciones de validación multinivel personalizadas para comparar las tablas de origen y destino a nivel de tabla, columna y fila. También puedes agregar reglas de validación.

La DVT abarca muchas fuentes de datos de Google Cloud , incluidos AlloyDB para PostgreSQL, BigQuery, Cloud SQL, Spanner, JSON y archivos CSV en Cloud Storage. También se puede integrar en Cloud Run Functions y Cloud Run para la activación y organización basadas en eventos.

La DVT admite los siguientes tipos de validaciones:

  • Comparaciones a nivel del esquema
  • Columna (incluye "AVG", "COUNT", "SUM", "MIN", "MAX", "GROUP BY" y "STRING_AGG")
  • Fila (incluye el hash y la concordancia exacta en las comparaciones de campos)
  • Comparación de resultados de consultas personalizadas

Para obtener más información sobre la DVT, consulta el repositorio de Git y La validación de datos es fácil con la herramienta de validación de datos de Google Cloud.

Realice la migración

Las tareas de migración incluyen las actividades para admitir la transferencia de un sistema a otro.

Ten en cuenta las siguientes prácticas recomendadas para la migración de datos:

  • Informa a los equipos involucrados cada vez que comience y finalice un paso del plan.
  • Si alguno de los pasos tarda más de lo esperado, compara el tiempo transcurrido con la cantidad máxima de tiempo asignada para ese paso. Cuando esto suceda, envía actualizaciones intermedias periódicas a los equipos involucrados.
  • Si el intervalo de tiempo es mayor que la cantidad máxima de tiempo reservada para cada paso del plan, considera revertir el proceso.
  • Toma decisiones de "continuar o no continuar" para cada paso del plan de migración y transición.
  • Considera acciones de reversión o situaciones alternativas para cada uno de los pasos.

Realiza la migración siguiendo las tareas de ejecución definidas y consulta la documentación de la herramienta de migración que elegiste.

Realiza la transición a producción

El proceso de transición de producción de alto nivel puede variar según la estrategia de migración que elijas. Si puedes tener tiempo de inactividad en tus cargas de trabajo, la transición de la migración comienza con la detención de las operaciones de escritura en la base de datos de origen.

Para las migraciones de replicación continua, por lo general, debes seguir estos pasos de alto nivel en el proceso de transición:

  • Detén las operaciones de escritura en la base de datos de origen.
  • Desvía la fuente.
  • Detén el proceso de replicación.
  • Implementa las aplicaciones que apuntan a la nueva base de datos de destino.

Después de migrar los datos con la herramienta de migración elegida, debes validar los datos en la base de datos de destino. Confirmas que la base de datos de origen y las bases de datos de destino estén sincronizadas y que los datos de la instancia de destino cumplan con los estándares de éxito de la migración que elegiste.

Una vez que la validación de datos cumpla con tus criterios, puedes realizar la migración de sistemas a nivel de la aplicación. Implementa las cargas de trabajo que se refactorizaron para usar la nueva instancia de destino. Implementas las versiones de tus aplicaciones que apuntan a la nueva instancia de base de datos de destino. Las implementaciones se pueden realizar a través de actualizaciones progresivas, lanzamientos en etapas o con un patrón de implementación azul-verde. Es posible que se produzca un tiempo de inactividad de la aplicación.

Sigue las prácticas recomendadas para la transición a producción:

  • Supervisa las aplicaciones que funcionan con la base de datos de destino después de la transición.
  • Define un período de supervisión para considerar si necesitas implementar tu plan de resguardo o no.
  • Ten en cuenta que es posible que debas reiniciar tu instancia de Cloud SQL o AlloyDB para PostgreSQL si cambias algunas marcas de base de datos.
  • Ten en cuenta que el esfuerzo de revertir la migración puede ser mayor que el de solucionar los problemas que aparecen en el entorno de destino.

Limpia el entorno de origen y configura la instancia de Cloud SQL o AlloyDB para PostgreSQL

Una vez que se complete la migración de sistemas, podrás borrar las bases de datos de origen. Te recomendamos que realices las siguientes acciones importantes antes de limpiar la instancia de origen:

  • Crea una copia de seguridad final de cada base de datos de origen. Estas copias de seguridad te proporcionan un estado final de las bases de datos de origen. En algunos casos, también se pueden requerir las copias de seguridad para cumplir con algunas reglamentaciones de datos.

  • Recopila los parámetros de configuración de la base de datos de tu instancia de origen. Como alternativa, verifica que coincidan con los que recopilaste en la fase de creación del inventario. Ajusta los parámetros de la instancia de destino para que coincidan con los de la instancia de origen.

  • Recopila estadísticas de la base de datos de la instancia de origen y compáralas con las de la instancia de destino. Si las estadísticas son dispares, es difícil comparar el rendimiento de la instancia de origen y la de destino.

En una situación de resguardo, es posible que desees implementar la replicación de tus escrituras en la instancia de Cloud SQL de vuelta a tu base de datos de origen original. La configuración se parece al proceso de migración, pero se ejecutaría en sentido inverso: la base de datos de origen inicial se convertiría en el nuevo destino.

Como práctica recomendada para mantener actualizadas las instancias de origen después de la migración, replica las operaciones de escritura realizadas en las instancias de Cloud SQL de destino en la base de datos de origen. Si necesitas revertir, puedes volver a tus instancias de origen anteriores con una pérdida de datos mínima.

Además de la limpieza del entorno de origen, debes realizar las siguientes configuraciones críticas para tus instancias de Cloud SQL:

  • Configura un período de mantenimiento para tu instancia principal para controlar cuándo pueden ocurrir las actualizaciones disruptivas.
  • Configura el almacenamiento en la instancia para que tengas al menos un 20% de espacio disponible para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar. Para recibir una alerta si el espacio disponible en el disco es inferior al 20%, crea una política de alertas basada en métricas para la métrica de uso del disco.

No inicies una operación administrativa antes de que haya finalizado la operación anterior.

Para obtener más información sobre el mantenimiento y las prácticas recomendadas, consulta Acerca del mantenimiento de instancias de Cloud SQL.

Optimiza tu entorno después de la migración

La optimización es la última fase de la migración. En esta fase, iteras en tareas de optimización hasta que tu entorno de destino cumpla con tus requisitos de optimización. Los pasos de cada iteración son los siguientes:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza el entorno y los equipos.
  4. Ajustar el bucle de optimización

Repite esta secuencia hasta que hayas alcanzado tus objetivos de optimización.

Para obtener más información sobre cómo optimizar tu entorno de Google Cloud , consulta Migra a Google Cloud: Optimiza tu entorno y Google Cloud Well-Architected Framework: Optimización del rendimiento.

Establece tus requisitos de optimización

Revisa los siguientes requisitos de optimización para tu entorno de Google Cloud y elige los que mejor se adapten a tus cargas de trabajo:

Aumenta la confiabilidad y la disponibilidad de tu base de datos

Con Cloud SQL, puedes implementar una estrategia de alta disponibilidad y recuperación ante desastres que se alinee con tu objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO). Para aumentar la confiabilidad y la disponibilidad, ten en cuenta lo siguiente:

  • En los casos de cargas de trabajo con mucha lectura, agrega réplicas de lectura para descargar el tráfico de la instancia principal.
  • Para las cargas de trabajo esenciales, usa la configuración de alta disponibilidad, las réplicas para la conmutación por error regional y una configuración sólida de recuperación ante desastres.
  • Para cargas de trabajo menos críticas, las copias de seguridad automáticas y a pedido pueden ser suficientes.
  • Para evitar la eliminación accidental de instancias, usa la protección contra la eliminación de instancias.
  • Considera usar la edición Cloud SQL Enterprise Plus para beneficiarte de una mayor disponibilidad, retención de registros y mantenimiento planificado con un tiempo de inactividad cercano a cero. Para obtener más información sobre Cloud SQL Enterprise Plus, consulta Introducción a las ediciones de Cloud SQL y Mantenimiento planificado con tiempo de inactividad cercano a cero.

Para obtener más información sobre cómo aumentar la confiabilidad y la disponibilidad de tu base de datos, consulta los siguientes vínculos:

Aumenta la rentabilidad de tu infraestructura de bases de datos

Para tener un impacto económico positivo, tus cargas de trabajo deben usar los recursos y servicios disponibles de manera eficiente. Considera las siguientes opciones:

  • Proporciona a la base de datos la capacidad de almacenamiento mínima requerida. Para ello, haz lo siguiente:

    • Para escalar la capacidad de almacenamiento de forma automática a medida que los datos crecen, habilita los aumentos de almacenamiento automáticos. Sin embargo, asegúrate de configurar tus instancias para que tengan un búfer en las cargas de trabajo máximas. Recuerda que las cargas de trabajo de la base de datos tienden a aumentar con el tiempo.

  • Identifica los posibles recursos sobreestimados:

    • Cambiar el tamaño de tus instancias de Cloud SQL puede reducir el costo de la infraestructura sin agregar riesgos adicionales a la estrategia de administración de la capacidad.
    • Cloud Monitoring proporciona paneles predefinidos que ayudan a identificar el estado y el uso de la capacidad de muchos componentes de Google Cloud, incluido Cloud SQL. Para obtener más información, consulta Crea y administra paneles personalizados.

  • Identifica las instancias que no requieren parámetros de configuración de alta disponibilidad o recuperación ante desastres, y quítalas de tu infraestructura.

  • Quita las tablas y los objetos que ya no sean necesarios. Puedes almacenarlos en una copia de seguridad completa o en un bucket de Cloud Storage de archivo.

  • Evalúa el tipo de almacenamiento más rentable (SSD o HDD) para tu caso de uso.

    • Para la mayoría de los casos de uso, el almacenamiento SSD es la elección más eficiente y rentable.
    • Si tus conjuntos de datos son grandes (10 TB o más), no son sensibles a la latencia o se accede a ellos con poca frecuencia, el almacenamiento HDD podría ser más adecuado.
    • Para obtener más información, consulta Elige entre el almacenamiento SSD y HDD.

  • Compra descuentos por compromiso de uso para cargas de trabajo con necesidades de recursos predecibles.

  • Usa Active Assist para obtener estadísticas y recomendaciones de costos.

    Para obtener más información y opciones, consulta Haz más con menos: Presentamos las recomendaciones de optimización de costos de Cloud SQL con Active Assist.

Aumenta el rendimiento de la infraestructura de tu base de datos

Los problemas de rendimiento menores relacionados con la base de datos suelen tener el potencial de afectar toda la operación. Para mantener y aumentar el rendimiento de tu instancia de Cloud SQL, ten en cuenta los siguientes lineamientos:

  • Si tienes una gran cantidad de tablas de base de datos, estas pueden afectar el rendimiento y la disponibilidad de la instancia, y hacer que esta pierda su cobertura del ANS.

  • Asegúrate de que tu instancia no tenga restricciones de memoria ni de CPU.

    • Para cargas de trabajo de rendimiento intensivo, asegúrate de que tu instancia tenga al menos 60 GB de memoria.
    • En el caso de las inserciones, actualizaciones o eliminaciones lentas de la base de datos, verifica las ubicaciones del escritor y de la base de datos. El envío de datos a través de distancias largas genera latencia.

  • Mejora el rendimiento de las consultas con el panel predefinido de Estadísticas de consultas en Cloud Monitoring (o funciones integradas similares del motor de base de datos). Identifica los comandos más costosos y trata de optimizarlos.

  • Evita que los archivos de la base de datos se vuelvan demasiado grandes. Configura autogrow en MB, en lugar de como un porcentaje, con incrementos apropiados para el requisito.

  • Verifica la ubicación del lector y de la base de datos. La latencia afecta el rendimiento de lectura más que el de escritura.

  • Considera usar la edición Cloud SQL Enterprise Plus para beneficiarte de los límites de configuración de máquinas y la caché de datos aumentados. Para obtener más información, consulta Introducción a las ediciones de Cloud SQL.

Para obtener más información sobre cómo aumentar el rendimiento, consulta Rendimiento en "Diagnostica problemas".

Aumenta las capacidades de observabilidad de la base de datos

El diagnóstico y la solución de problemas en las aplicaciones que se conectan a instancias de bases de datos pueden ser difíciles y llevar mucho tiempo. Por este motivo, es fundamental contar con un lugar centralizado en el que todos los miembros del equipo puedan ver lo que sucede a nivel de la base de datos y de la instancia. Puedes supervisar las instancias de Cloud SQL de las siguientes maneras:

  • Cloud SQL usa agentes personalizados de memoria integrados para recopilar telemetría de consultas.

    • Usa Cloud Monitoring para recopilar mediciones de tu servicio y los recursos de Google Cloud que usas. Cloud Monitoring incluye paneles predefinidos para varios productos de Google Cloud , incluido un panel de supervisión de Cloud SQL.
    • Puedes crear paneles personalizados que te ayuden a supervisar las métricas y configurar políticas de alertas para que puedas recibir notificaciones oportunas.
    • Como alternativa, puedes considerar usar soluciones de supervisión de terceros que se integran en Google Cloud, como Datadog y Splunk.

  • Cloud Logging recopila datos de registro de componentes de la aplicación comunes.

  • Cloud Trace recopila datos de latencia y planes de consultas ejecutados de las aplicaciones para ayudarte a hacer un seguimiento de cómo se propagan las solicitudes a través de tus aplicaciones.

  • Database Center proporciona una descripción general centralizada de la flota de bases de datos asistida por IA. Puedes supervisar el estado de tus bases de datos, la configuración de disponibilidad, la protección de datos, la seguridad y el cumplimiento de la industria.

Prácticas recomendadas generales y lineamientos operativos de Cloud SQL

Aplica las prácticas recomendadas de Cloud SQL para configurar y ajustar la base de datos.

Estas son algunas recomendaciones generales importantes de Cloud SQL:

  • Si tienes instancias grandes, te recomendamos que las dividas en instancias más pequeñas, cuando sea posible.
  • Configura el almacenamiento para adaptar el mantenimiento fundamental de la base de datos. Asegúrate de tener al menos un 20% de espacio disponible para alojar cualquier operación crítica de mantenimiento de base de datos que Cloud SQL pueda realizar.
  • Tener demasiadas tablas de base de datos puede afectar el tiempo de actualización de la base de datos. Lo ideal es tener menos de 10,000 tablas por instancia.
  • Elige el tamaño adecuado para tus instancias para que se tome en cuenta la retención del registro de transacciones (binario), en especial para las instancias con mucha actividad de escritura.

Para poder controlar de manera eficiente cualquier problema de rendimiento de la base de datos que puedas encontrar, usa los siguientes lineamientos hasta que se resuelva el problema:

Escala verticalmente la infraestructura: Aumenta los recursos (como la capacidad de procesamiento del disco, la CPU virtual y la RAM). Según la urgencia y la disponibilidad y experiencia de tu equipo, escalar verticalmente tu instancia puede resolver la mayoría de los problemas de rendimiento. Más adelante, puedes investigar más a fondo la causa raíz del problema en un entorno de pruebas y considerar opciones para eliminarlo.

Realiza y programa operaciones de mantenimiento de la base de datos: Desfragmentación de índices, actualizaciones de estadísticas, análisis de limpieza y reindexación de tablas muy actualizadas. Verifica si estas operaciones de mantenimiento se realizaron por última vez y cuándo, en especial en los objetos afectados (tablas, índices). Descubre si hubo un cambio en las actividades normales de la base de datos. Por ejemplo, agregar una columna nueva recientemente o tener muchas actualizaciones en una tabla.

Ajusta y optimiza la base de datos: ¿Las tablas de tu base de datos están estructuradas correctamente? ¿Las columnas tienen los tipos de datos correctos? ¿Tu modelo de datos es adecuado para el tipo de carga de trabajo? Investiga tus consultas lentas y sus planes de ejecución. ¿Están usando los índices disponibles? Verifica si hay análisis de índices, bloqueos y esperas en otros recursos. Considera agregar índices para admitir tus consultas críticas. Elimina los índices y las claves externas no esenciales. Considera reescribir las consultas y uniones complejas. El tiempo que se tarda en resolver el problema depende de la experiencia y la disponibilidad de tu equipo, y puede variar de horas a días.

Escala horizontalmente tus lecturas: Considera tener réplicas de lectura. Cuando el escalamiento vertical no es suficiente para tus necesidades y las medidas de ajuste y optimización de la base de datos no ayudan, considera escalar de forma horizontal. Enrutar las consultas de lectura desde tus aplicaciones a una réplica de lectura mejora el rendimiento general de la carga de trabajo de tu base de datos. Sin embargo, es posible que se requiera un esfuerzo adicional para cambiar tus aplicaciones y conectarlas a la réplica de lectura.

Rediseño de la arquitectura de la base de datos: Considera particionar e indexar la base de datos. Esta operación requiere mucho más esfuerzo que el ajuste y la optimización de la base de datos, y puede implicar una migración de datos, pero puede ser una solución a largo plazo. A veces, un diseño deficiente del modelo de datos puede generar problemas de rendimiento, que se pueden compensar parcialmente con el escalamiento vertical. Sin embargo, un modelo de datos adecuado es una solución a largo plazo. Considera particionar tus tablas. Si es posible, archiva los datos que ya no se necesiten. Normaliza la estructura de tu base de datos, pero recuerda que la desnormalización también puede mejorar el rendimiento.

Fragmentación de bases de datos: Puedes escalar horizontalmente tus operaciones de escritura fragmentando tu base de datos. La fragmentación es una operación complicada que implica rediseñar la base de datos y las aplicaciones de una manera específica, y realizar la migración de datos. Dividirás la instancia de la base de datos en varias instancias más pequeñas con un criterio de partición específico. Los criterios pueden basarse en el cliente o el tema. Esta opción te permite escalar de forma horizontal tanto las operaciones de escritura como las de lectura. Sin embargo, aumenta la complejidad de las cargas de trabajo de tu base de datos y aplicación. También podría generar fragmentos desequilibrados llamados hotspots, lo que superaría el beneficio de la fragmentación. - Específicamente para Cloud SQL para MySQL, asegúrate de que tus tablas tengan una clave principal o única. Cloud SQL usa la replicación basada en filas, que funciona mejor en tablas con claves primarias o únicas.

Para obtener más detalles, consulta las Prácticas recomendadas generales y los Lineamientos operativos de Cloud SQL para MySQL.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: