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

Last reviewed 2024-08-16 UTC

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

Este documento está dirigido a administradores de bases de datos y de la nube que quieran planificar, implementar y validar un proyecto de migración de bases de datos. También está dirigido a los responsables de la toma de decisiones que están evaluando la oportunidad de migrar y quieren ver un ejemplo de cómo podría ser una migración.

Este documento se centra en la 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 forma parte de una serie de artículos sobre la migración de AWS aGoogle Cloud , que incluye los siguientes documentos:

Para llevar a cabo esta migración a Google Cloud, te recomendamos que sigas el framework de migración descrito en el artículo Migrar a Google Cloud: primeros pasos.

En el siguiente diagrama se muestra el 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 adelante. En cada iteración de migración independiente, debes seguir las fases del marco de migración general:

  1. Evalúa e identifica tus cargas de trabajo y datos.
  2. Planifica y construye una base sobre Google Cloud.
  3. Migra tus cargas de trabajo y datos a Google Cloud.
  4. Optimiza tu Google Cloud entorno.

Para obtener más información sobre las fases de este marco, consulta el artículo Migrar a Google Cloud: primeros pasos.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y que tengas una estrategia de restauración. Para validar tu plan de migración, consulta el artículo Migrar a Google Cloud: prácticas recomendadas para validar un plan de migración.

Evaluar el entorno de origen

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

La fase de evaluación es fundamental para que la migración se lleve a cabo correctamente. Debes conocer en profundidad las cargas de trabajo que quieres migrar, sus requisitos, sus dependencias y tu entorno actual. Para planificar y llevar a cabo una migración correctamente, debes conocer tu punto de partida. Google Cloud

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

  1. Crea un inventario completo de tus cargas de trabajo.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Forma y educa a tus equipos sobre Google Cloud.
  4. Crea experimentos y pruebas de concepto en Google Cloud.
  5. Calcula el coste total de propiedad (CTP) del entorno de destino.
  6. Elige la estrategia de migración de tus cargas de trabajo.
  7. Elige las herramientas de migración.
  8. Define el plan y la cronología de la 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 se adapten a la fuente para satisfacer necesidades de rendimiento similares. Presta especial atención al tamaño y al rendimiento del disco, a las IOPS y al número de vCPUs. Es posible que las migraciones tengan problemas o fallen debido a que el tamaño de la instancia de la base de datos de destino sea incorrecto. Si el tamaño no es el adecuado, la migración puede tardar mucho, y pueden producirse problemas de rendimiento de la base de datos, errores en la base de datos y problemas de rendimiento de la aplicación. Al elegir la instancia de Cloud SQL, ten en cuenta que el rendimiento del disco se basa en el tamaño del disco y en el número de vCPUs.

Las siguientes secciones se basan en el artículo Migración a Google Cloud: evaluar e identificar cargas de trabajo y se integran en él.

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

Para definir el ámbito de la migración, cree un inventario y recopile información sobre sus instancias de Amazon RDS o Amazon Aurora. Te recomendamos que automatices este proceso con herramientas especializadas, ya que los métodos manuales son propensos a errores y pueden llevar a conclusiones incorrectas.

Es posible que Amazon RDS o Amazon Aurora y Cloud SQL no tengan las mismas funciones, especificaciones de instancia u operaciones. Es posible que algunas funciones se implementen de forma diferente o no estén disponibles. Las diferencias pueden incluir la infraestructura, el almacenamiento, la autenticación y la seguridad, la replicación, la copia de seguridad, la alta disponibilidad, el modelo de capacidad de recursos y las integraciones y extensiones de funciones específicas del motor de base de datos. En función del 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 los ajustes de los parámetros de la base de datos.

Las comparativas pueden ayudarte a entender mejor las cargas de trabajo que se van a migrar y contribuyen a definir la arquitectura adecuada del entorno de destino de la migración. Recoger información sobre el rendimiento es importante para ayudar a estimar las necesidades de rendimiento del entorno de destino. Google Cloud Los conceptos y las herramientas de las comparativas se detallan en la fase Realizar pruebas y validaciones del proceso de migración, pero también se aplican a la fase de creación del inventario.

Herramientas para las evaluaciones

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

Con Migration Center, puedes realizar una evaluación completa de tu entorno de aplicaciones y bases de datos, incluida la idoneidad técnica para migrar una base de datos a Google Cloud. Recibes recomendaciones sobre el tamaño y la configuración de cada base de datos de origen, y creas un informe de coste total de propiedad (TCO) de 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 Importar datos de otros proveedores de servicios en la nube.

Además de Migration Center, puedes usar la herramienta especializada migVisor, que admite varios motores de bases de datos y es especialmente adecuada 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 propietarias incompatibles que pueden provocar que la migración se realice de forma predeterminada, así como sugerir soluciones alternativas. migVisor también puede recomendar una solución de destino, incluida la arquitectura y el tamaño iniciales. Google Cloud

Los resultados de la evaluación de la base de datos de migVisor proporcionan lo siguiente:

  • Descubrimiento y análisis exhaustivos de las implementaciones de bases de datos actuales.
  • Informe detallado de la complejidad de la migración, basado en las funciones propietarias que usa tu base de datos.
  • Informe financiero con detalles sobre los ahorros de costes tras la migración, los costes de la migración y el nuevo presupuesto operativo.
  • Plan de migración por fases para mover bases de datos y aplicaciones asociadas con las mínimas interrupciones posibles en la empresa.

Para ver algunos ejemplos de resultados de la evaluación, consulta migVisor - Cloud migration assessment tool (migVisor: herramienta de evaluación de la migración a la nube).

Ten en cuenta que migVisor aumenta temporalmente la utilización del servidor de bases de datos. Normalmente, esta carga adicional es inferior al 3 % y se puede ejecutar durante las horas de menor actividad.

Los resultados de la evaluación de migVisor le ayudan a crear un inventario completo de sus instancias de RDS. El informe incluye propiedades genéricas (versión y edición del motor de la 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 los parámetros y las personalizaciones especiales en uso.

Si prefieres usar herramientas de código abierto, puedes usar secuencias de comandos de recogida de datos con las herramientas mencionadas (o en lugar de ellas). Estas secuencias de comandos pueden ayudarle a recopilar información detallada (sobre cargas de trabajo, funciones, objetos de base de datos y código de base de datos) y a crear su 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.

Te recomendamos la herramienta de código abierto DMA, que han creado 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 (como esquemas, tablas, vistas, funciones, activadores y procedimientos almacenados).

Para usar DMA, descarga las secuencias de comandos de recogida de 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 que los analice. Google Cloud crea y envía un informe de evaluación de la base de datos, y proporciona los pasos siguientes en el proceso de migración.

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

En esta fase, se documenta la información esencial que influye en la estrategia y las herramientas de migración. Ahora puedes responder a las siguientes preguntas:

  • ¿Tus bases de datos ocupan más de 5 TB?
  • ¿Hay alguna tabla grande en tu base de datos? ¿Tienen un tamaño superior a 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?
  • ¿Qué opciones hay para las bases de datos de destino?
  • ¿Cómo de compatibles son las bases de datos de origen y de destino?
  • ¿Los datos deben residir en alguna ubicación física?
  • ¿Hay datos que se puedan comprimir y archivar o datos que no sea necesario migrar?

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

Establece valores de referencia de la migración de datos que te ayuden a comparar y evaluar los resultados y los impactos. Estas líneas de base son puntos de referencia que representan el estado de sus datos antes y después de la migración, y le ayudan a tomar decisiones. Es importante tomar medidas en el entorno de origen que puedan ayudarte a evaluar el éxito de la migración de datos. Entre estas mediciones se incluyen las siguientes:

  • El tamaño y la estructura de sus datos.
  • La integridad y la 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. ¿Qué repercusiones tiene el tiempo de inactividad en las empresas? ¿Hay periodos de poca actividad en la base de datos durante los cuales se ven afectados menos usuarios por el tiempo de inactividad? Si es así, ¿cuánto duran esos periodos y cuándo se producen? Considera la posibilidad de tener un tiempo de inactividad de escritura parcial, mientras se siguen atendiendo las solicitudes de solo lectura.

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

Una vez que hayas creado los inventarios, evalúa los procesos operativos y de implementación de tu base de datos para determinar cómo debes adaptarlos y facilitar la migración. Estos procesos son fundamentales para preparar y mantener tu entorno de producción.

Piensa en cómo completas las siguientes tareas:

  • Define y aplica políticas de seguridad para tus instancias: por ejemplo, puede que tengas que sustituir los grupos de seguridad de Amazon. Puedes usar los roles de Gestión de Identidades y Accesos (IAM) de Google, las reglas de cortafuegos de VPC y los Controles de Servicio de VPC para controlar el acceso a tus instancias de Cloud SQL y acotar los datos en una VPC.

  • Aplica parches y configura tus instancias: es posible que tengas que actualizar tus herramientas de implementación. Por ejemplo, puede que estés usando ajustes de configuración personalizados en grupos de parámetros o grupos de opciones de Amazon. Es posible que tengas que adaptar tus herramientas de aprovisionamiento para usar Google Cloud Storage o Secret Manager y leer esas listas de configuración personalizadas.

  • Gestionar la infraestructura de monitorización y alertas: las categorías de métricas de las instancias de la 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, Performance Insights, monitorización mejorada y listas de procesos del SO.

Completa la evaluación

Después de crear los inventarios a partir de tu entorno de Amazon RDS o Amazon Aurora, completa el resto de las actividades de la fase de evaluación tal como se describe en Migrar a Google Cloud: evaluar y descubrir las cargas de trabajo.

Planifica y construye tu base

En la fase de planificación y creación, aprovisionas y configuras la infraestructura para hacer lo siguiente:

  • Compatibilidad con tus cargas de trabajo en tu Google Cloud entorno.
  • Conecta tu entorno de origen y tu entorno de Google Cloud para completar la migración.

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

  1. Crea una jerarquía de recursos.
  2. Configura la gestión de identidades y accesos (IAM) de Google Cloud.
  3. Configura la facturación
  4. Configura la conectividad de red.
  5. Refuerza tu seguridad.
  6. Configura el almacenamiento de registros, la monitorización y las alertas.

Para obtener más información sobre cada una de estas tareas, consulta el artículo Migrar a Google Cloud: planificar y crear la base.

Si tienes previsto usar Database Migration Service para la migración, consulta Métodos de redes para MySQL para conocer las configuraciones de red disponibles en los escenarios de migración.

Monitorización y alertas

Usa Cloud Monitoring de Google, que incluye paneles de control predefinidos para varios productos de Google Cloud , incluido un panel de control de monitorización de Cloud SQL. También puedes usar soluciones de monitorización de terceros integradas conGoogle Cloud, como Datadog y Splunk. Para obtener más información, consulta Información sobre la observabilidad de las bases de datos.

Migrar 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 en función de la estrategia y los requisitos que hayas seleccionado.

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

  4. Define las tareas de preparación que deben realizarse para que la herramienta de migración funcione correctamente.

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

  6. Define escenarios alternativos para cada tarea de ejecución.

  7. Realiza pruebas y validaciones, que se pueden llevar a cabo en un entorno de staging independiente.

  8. Realiza la migración.

  9. Realiza el cambio a producción.

  10. Limpia el entorno de origen y configura la instancia de destino.

  11. Realiza ajustes y optimizaciones.

Cada fase se describe en las siguientes secciones.

Elegir una 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 práctico 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 coste y una complejidad relativamente 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, tendrás que reiniciar el proceso, lo que prolongará el tiempo de inactividad.

  • Replicación continua (también llamada migración online o migración gradual): en el caso de las bases de datos esenciales, esta opción ofrece un menor riesgo de pérdida de datos y un tiempo de inactividad casi nulo. Los esfuerzos se dividen en varios fragmentos, por lo que, si se produce un fallo, 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. Considere una de las siguientes variaciones:

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

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

En el siguiente diagrama de flujo se muestran algunas preguntas que puedes hacerte a la hora de decidir la estrategia de migración de 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?

    • Si no es así, 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 la ventana de cambio mientras migras los datos? La ventana de cambio representa el tiempo necesario para crear una copia de seguridad de la base de datos, transferirla a Cloud SQL, restaurarla y, a continuación, cambiar tus aplicaciones.

    • Si no es así, 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 en función de la base de datos, aunque estén ubicadas en la misma instancia. Una combinación de estrategias puede dar resultados óptimos. Por ejemplo, puedes migrar bases de datos pequeñas y que no se usen con frecuencia mediante el mantenimiento programado, pero usar la replicación continua para las bases de datos esenciales 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 de destino. Se detiene cualquier replicación (si se usa) y todas las lecturas y escrituras se realizan en la instancia de destino. Si cambias cuando ambas instancias están sincronizadas, no se perderán datos y el tiempo de inactividad será 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 provocan tiempos de inactividad de las aplicaciones requieren una configuración más compleja. Encuentra el equilibrio adecuado entre la complejidad de la configuración y el tiempo de inactividad programado durante las horas de menor tráfico.

Cada estrategia de migración tiene ventajas e inconvenientes, así como un impacto asociado al proceso de migración. Por ejemplo, los procesos de replicación implican una carga adicional en las instancias de origen y las aplicaciones pueden verse afectadas por la latencia de replicación. Es posible que las aplicaciones (y los clientes) tengan que esperar durante el tiempo de inactividad de la aplicación, al menos mientras dure el retraso de la replicación, antes de usar la nueva base de datos. En la práctica, los siguientes factores pueden aumentar el tiempo de inactividad:

  • Las consultas de bases de datos pueden tardar unos segundos en completarse. En el momento de la migración, es posible que se cancelen las consultas en curso.
  • La caché puede tardar un tiempo en llenarse si la base de datos es grande o tiene una memoria de búfer considerable.
  • Las aplicaciones que se hayan detenido en la fuente y se hayan reiniciado en Google Cloudpueden tener un pequeño retraso hasta que se establezca la conexión con la instancia de la base de datos de Google Cloud.
  • Las rutas de red a las aplicaciones deben redirigirse. En función de cómo se hayan configurado las entradas DNS, este proceso puede tardar un poco. Cuando actualices los registros DNS, reduce el TTL antes de la migración.

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

  • Busca un periodo en el que el tiempo de inactividad tenga un impacto mínimo en tus cargas de trabajo. Por ejemplo, fuera del horario de apertura habitual, durante los fines de semana o en otras ventanas de mantenimiento programadas.
  • Identifica las partes de tus cargas de trabajo que se pueden migrar y cambiar a producción en diferentes fases. Es posible que tus aplicaciones tengan diferentes componentes que se puedan aislar, adaptar y migrar sin que esto suponga ningún problema. Por ejemplo, front-ends, módulos de CRM, servicios de backend y plataformas de informes. Estos módulos pueden tener sus propias bases de datos, cuya migración se puede programar para antes o después en el proceso.
  • Si puedes permitirte cierta latencia en la base de datos de destino, considera la posibilidad de implementar una migración gradual. Usa transferencias de datos incrementales por lotes y adapta parte de tus cargas de trabajo para que funcionen con los datos obsoletos de la instancia de destino.
  • Te recomendamos que refactorices tus aplicaciones para que la migración tenga el menor impacto posible. Por ejemplo, adapta tus aplicaciones para que escriban en las bases de datos de origen y de destino, e implementa una replicación a nivel de aplicación.

Elige tus herramientas de migración

El factor más importante para que una migración tenga éxito 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 de ellas optimizada para determinados casos prácticos de migración. Estos son algunos de los usos:

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

Para garantizar una migración y un cambio sin problemas, puedes usar patrones de implementación de aplicaciones, orquestación de infraestructuras y aplicaciones de migración personalizadas. Sin embargo, hay herramientas especializadas llamadas servicios de migración gestionados que 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, opcionalmente, pueden modificar los datos durante el tránsito. Gracias a estas funciones, encapsulan la lógica compleja de la migración y ofrecen funciones de monitorización de la migración.

Los servicios de migración gestionados ofrecen las siguientes ventajas:

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

  • Garantizar la integridad y la seguridad de los datos: los datos se transfieren de forma segura y fiable de la base de datos de origen a la de destino.

  • Ofrecer una experiencia de migración coherente: las diferentes técnicas y patrones de migración se pueden consolidar en una interfaz común y coherente mediante el uso de ejecutables de migración de bases de datos, que puede gestionar y monitorizar.

  • Ofrecer modelos de migración resistentes y probados: las migraciones de bases de datos son eventos poco frecuentes, pero críticos. Para evitar errores de principiante y problemas con las soluciones actuales, puedes usar herramientas de expertos en lugar de crear una solución personalizada.

  • Optimizar los costes: los servicios de migración gestionados 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 la herramienta de migración, que dependen de la estrategia de migración elegida.

Herramientas para migraciones de mantenimiento programadas

En el siguiente diagrama de flujo se muestran las 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 programado.

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

  • ¿Prefieres los servicios de migración gestionados?
    • Si es así, te recomendamos que uses Database Migration Service.
    • Si no es así, le recomendamos que haga la migración mediante las copias de seguridad integradas del motor de la base de datos.

Usar un servicio de migración gestionado ofrece algunas ventajas, que se describen 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 migraciones únicas, así como sus limitaciones y prácticas recomendadas.

Database Migration Service para la migración de mantenimiento programado

Database Migration Service gestiona tanto la sincronización inicial como la replicación continua de la captura de datos de cambios (CDC) y proporciona el estado de la operación de migración.

Con el servicio de migración de bases de datos, puedes crear tareas de migración que puedes gestionar y verificar. Te recomendamos que uses Database Migration Service, ya que admite migraciones a Cloud SQL para MySQL mediante trabajos de migración únicos. En el caso de las 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 los artículos Migrar 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, consulte los siguientes artículos:

Copias de seguridad de motores de bases de datos integradas

Si se puede tolerar un tiempo de inactividad significativo y las bases de datos de origen son relativamente estáticas, puede usar las funciones de volcado y carga integradas del motor de base de datos (también llamadas a veces de copia de seguridad y restauración).

Se requiere cierto esfuerzo para la configuración y la sincronización, sobre todo si se trata de un gran número 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 dar lugar a errores, sobre todo si se realizan manualmente.
  • Los datos no están protegidos si las copias de seguridad no se gestionan correctamente.
  • Las copias de seguridad no tienen las funciones de monitorización adecuadas.
  • Se requiere esfuerzo para escalar si se migran muchas bases de datos con esta herramienta.

Si eliges este método, 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. Estas son algunas de esas estrategias:

    • 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.
    • Valora otras opciones, como usar las herramientas mydumper y myloader.

Las volcados y las copias de seguridad de bases de datos no suelen incluir cuentas de usuario de MySQL. Antes de hacer la migración, revisa todas las cuentas de usuario de la instancia de origen. Por ejemplo, puedes ejecutar el comando SHOW GRANTS para cada usuario para revisar el conjunto de privilegios actual y comprobar si hay alguno restringido en Cloud SQL. Del mismo modo, la herramienta pt-show-grants de Percona también puede mostrar los privilegios.

Las restricciones de los privilegios de usuario en Cloud SQL pueden afectar a 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 para ejecutar comandos de SQL, como cambiar una variable global no permitida en Cloud SQL. En casos como este, puede que sea necesario reescribir el código de procedimiento almacenado o migrar objetos que no sean tablas, como procedimientos almacenados, como un paso de migración independiente. Para obtener más información, consulta las prácticas recomendadas para importar y exportar datos.

Para obtener más información sobre las limitaciones y las prácticas recomendadas, consulta los siguientes artículos:

Otros enfoques para la migración de mantenimiento programado

Al usar una importación gestionada para configurar la replicación desde una base de datos MySQL externa, se realiza una carga inicial de datos desde la base de datos externa a la instancia de Cloud SQL. Este método usa un servicio que extrae datos del servidor externo (en este caso, la instancia de RDS) y los importa directamente a la instancia de Cloud SQL.

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

Puedes exportar las tablas de tu base de datos MySQL a archivos CSV, que 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 segmento de S3 como destino.

Para obtener información detallada y los pasos que debes seguir, consulta el artículo Usar una importación gestionada para configurar la replicación desde bases de datos externas.

Herramientas para migraciones de replicación continua

En el siguiente diagrama de flujo se muestran las 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 gestionados?

    • Si es así, ¿puedes permitirte unos segundos de inactividad de escritura, en función del número de tablas de tu base de datos?

      • Si es así, usa el servicio de migración de bases de datos.
      • Si no es así, consulta otras opciones de migración.

    • Si no es así, debe evaluar si se admite la replicación integrada del motor de la base de datos:

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

En las siguientes secciones se describen las herramientas que se pueden usar para realizar migraciones continuas, así como sus limitaciones y prácticas recomendadas.

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

El servicio de migración de bases de datos ofrece asistencia integral para las migraciones continuas mediante el uso de tipos de tareas de migración continua. Solo se pueden promover las tareas de migración continua, lo que indica que la replicación debe detenerse.

Si elige esta herramienta, tenga en cuenta las siguientes restricciones y prácticas recomendadas:

  • Evita las transacciones de larga duración durante la migración. En estos casos, te recomendamos que migres desde una réplica de lectura si no lo haces desde AWS Aurora.
  • Para ver la lista completa de 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 alternativa a Database Migration Service para realizar una migración continua.

La replicación de bases de datos es el proceso de copiar y distribuir datos de una 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 fallos y la fiabilidad de un sistema de base de datos. Aunque la migración de bases de datos no es el objetivo principal de la replicación de bases de datos, se puede usar como herramienta para conseguirlo. 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 eliminan datos en la base de datos principal. Puede hacerse 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 conseguir la replicación de bases de datos. Un tipo de replicación se puede conseguir copiando y enviando el registro de escritura anticipada o el registro de transacciones de la réplica principal a sus réplicas. Este enfoque se denomina replicación física o binaria. Otros tipos de replicación funcionan distribuyendo las instrucciones 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 de MySQL. Sin embargo, hay algunos requisitos y limitaciones.

Requisitos previos:

  • Asegúrate de usar MySQL 5.5, 5.6, 5.7 u 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 de volcado completo inicial, elige un nivel de máquina lo suficientemente grande desde el punto de vista del tamaño de la CPU y la memoria.
  • Si necesitas acelerar la fase de CDC, puedes intentar configurar la replicación en paralelo y habilitar el vaciado de alto rendimiento.
  • Si la réplica de Cloud SQL tiene habilitadas las direcciones IP internas porque la dirección IP saliente no es estática, configura el cortafuegos del servidor de Amazon RDS o Amazon Aurora para que permita el intervalo de IP internas asignado al acceso a servicios privados de la red VPC que la réplica de Cloud SQL usa como red privada. Para obtener más información, consulta los artículos Información sobre la replicación desde un servidor externo y Configurar el acceso a servicios privados.

Limitaciones:

  • Si tienes tablas grandes y muchos índices secundarios en tu base de datos, la volcado completo inicial puede tardar más.
  • Si tu servidor externo contiene cláusulas DEFINER (vistas, eventos, activadores o procedimientos almacenados), es posible que la replicación falle en función del orden en el que se ejecuten estas instrucciones. Consulta más información sobre el DEFINERuso y las posibles soluciones alternativas en Cloud SQL.
  • InnoDB es el único motor de base de datos compatible con Cloud SQL. Migrar MyISAM puede provocar incoherencias en los datos y requerir la validación de los datos. Consulta Convertir tablas de MyISAM a InnoDB.

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

Otros enfoques de migración con replicación continua son los siguientes:

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

    • Tus aplicaciones realizan la replicación continua.
    • La migración se centra en la refactorización o el desarrollo de herramientas que se conectan a tus instancias de bases de datos.
    • Las aplicaciones de lectura se refactorizan y se implementan gradualmente para usar la instancia de destino.

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

    • Datastream es un servicio de replicación y CDC sin servidor 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, a continuación, usa Dataflow o Dataproc 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 artículos:

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 bases de datos. Esto puede ocurrir si prefieres usar un servicio de migración gestionado y necesitas asegurarte de que la base de datos de destino esté siempre sincronizada con la de origen en tiempo casi real, o si necesitas transformaciones más complejas, como la limpieza, la reestructuración y la adaptación de los datos durante el proceso de migración.

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

Striim es una plataforma integral en memoria para recoger, filtrar, transformar, enriquecer, agregar, analizar y enviar datos en tiempo real:

  • Ventajas:

    • Gestiona grandes volúmenes de datos y migraciones complejas.
    • Captura de datos de cambios integrada para SQL Server.
    • Plantillas de conexión preconfiguradas y flujos de trabajo sin código.
    • Puede gestionar bases de datos grandes y esenciales que operan con una carga transaccional elevada.
    • Entrega una sola vez.

  • Inconvenientes:

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

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

  • Ventajas:

    • De código abierto.
    • Gran apoyo de la comunidad.
    • Rentable.
    • Control pormenorizado de filas, tablas o bases de datos.
    • Especializada en la captura de cambios en tiempo real de los registros de transacciones de bases de datos.

  • Inconvenientes:

    • Se requiere experiencia específica con Kafka y ZooKeeper.
    • Las entregas de cambios de datos se realizan al menos una vez, lo que significa que debe gestionar los duplicados.
    • Configuración manual de la monitorización con Grafana y Prometheus.
    • No se admite la replicación incremental por lotes.

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 que permite mover datos desde y entre plataformas de datos en la nube.

  • Ventajas:

    • Plantillas de conexión preconfiguradas y flujos de trabajo sin código.
    • Propaga los cambios de esquema del origen a la base de datos de destino.
    • Entrega de los cambios de datos exactamente una vez, lo que significa que no es necesario gestionar los duplicados.

  • Inconvenientes:

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

Definir el plan y la cronología de la migración

Para que la migración de la base de datos y el cambio a producción se lleven a cabo correctamente, te recomendamos que prepares un plan de migración completo y bien definido. Para reducir el impacto en tu empresa, te recomendamos que crees una lista con todos los elementos de trabajo necesarios.

Definir el ámbito de la migración revela las tareas que debes realizar antes, durante y después del proceso de migración de la base de datos. Por ejemplo, si decides no migrar determinadas tablas de una base de datos, es posible que tengas que realizar tareas previas o posteriores a la migración para implementar este filtrado. También debes asegurarte de que la migración de la base de datos no afecte al acuerdo de nivel de servicio ni al plan de continuidad de negocio que tengas.

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

  • Documento de diseño técnico (DDT)
  • Matriz RACI
  • Cronología (por ejemplo, un plan de cuenta atrás)

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 imprevistos. Te recomendamos que siempre tengas un plan de reversión. Como práctica recomendada, sigue las directrices de Migrar a: prácticas recomendadas para validar un plan de migración Google Cloud.

TDD

El documento de diseño técnico recoge todas las decisiones técnicas que se deben tomar en el proyecto. Incluye lo siguiente en el TDD:

  • Requisitos y criticidad de la empresa
  • Objetivo de tiempo de recuperación (RTO)
  • Objetivo de punto de recuperación (RPO)
  • Detalles de la migración de bases de datos
  • Estimaciones del esfuerzo de migración
  • Recomendaciones para validar la migración

Matriz RACI

Algunos proyectos de migración requieren una matriz RACI, que es un documento de gestión de proyectos habitual que define qué personas o grupos son responsables de las tareas y los resultados del proyecto de migración.

Cronología

Prepara una cronología para cada base de datos que deba migrarse. Incluye todas las tareas de trabajo que se deben realizar, así como las fechas de inicio y de finalización estimadas.

Te recomendamos que crees un plan de cuenta atrás para cada entorno de migración. Un plan de cuenta atrás se estructura como una programación de cuenta atrás y enumera todas las tareas necesarias para completar el proyecto de migración, junto con los grupos responsables y la duración estimada.

La cronología debe tener en cuenta no solo las tareas de preparación previas a la migración, sino también las tareas de validación, auditoría o prueba que se lleven a cabo después de 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 atrás podría tener este aspecto:

Fecha Fase Categoría Tasks Rol T menos Estado
01/11/2023 Antes de la migración Evaluación Crear un informe de evaluación Equipo de Discovery -21 Completado
7/11/2023 Antes de la migración Preparación de los objetivos Diseñar el entorno de destino tal como se describe en el documento de diseño Equipo de migración -14 Completado
15/11/2023 Antes de la migración Gobierno de la empresa Fecha de migración y aprobación de T-Minus Liderazgo -6 Completado
18/11/2023 Migración Configurar DMS Crear perfiles de conexión Ingeniero de migración a la nube -3 Completado
19/11/2023 Migración Configurar DMS Crear e iniciar tareas de migración Ingeniero de migración a la nube -2 No iniciado
19/11/2023 Migración Monitorizar DMS Monitorizar los trabajos de DMS y los cambios de DDL en la instancia de origen Ingeniero de migración a la nube -2 No iniciado
21/11/2023 Migración Migración de DMS Promocionar réplica de DMS Ingeniero de migración a la nube 0 No iniciado
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 No iniciado
21/11/2023 Migración Prueba de aplicación Realizar pruebas de rendimiento y funciones Equipo de migración 0 No iniciado
22/11/2023 Migración Gobierno de la empresa Validación de la migración: OK o NO Equipo de migración 1 No iniciado
23/11/2023 Después de la migración Validar la monitorización Configurar supervisión Equipo de infraestructura 2 No iniciado
25/11/2023 Después de la migración Seguridad Quitar una cuenta de usuario de DMS Equipo de seguridad 4 No iniciado

Migraciones de varias bases de datos

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

Te recomendamos que empieces el proceso migrando una base de datos más pequeña y, a ser posible, que no sea crítica. Este enfoque puede ayudarte a adquirir conocimientos y confianza en el proceso de migración y en las herramientas. También puedes detectar cualquier fallo en el proceso en las primeras fases de la programación general de la migración.

Si tienes varias bases de datos que migrar, las cronologías se pueden paralelizar. Por ejemplo, para acelerar el proceso de migración, puedes migrar un grupo de bases de datos pequeñas, estáticas o menos importantes 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 del 1 al 4 son un grupo de bases de datos pequeñas que se migran al mismo tiempo.

Definir las tareas de preparación

Las tareas de preparación son todas las actividades que debes completar para cumplir los requisitos previos de la migración. Si no se realizan las tareas de preparación, la migración no se podrá llevar a cabo o la base de datos migrada no se podrá usar.

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

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

Preparación de instancias de Amazon RDS o Amazon Aurora y requisitos previos

Ten en cuenta las siguientes tareas de configuración y requisitos previos habituales:

  • En función de la ruta de migración, es posible que tengas que permitir las conexiones remotas en tus instancias de RDS. Si tu instancia de RDS está configurada como privada en tu VPC, debe haber conectividad privada RFC 1918 entre Amazon y Google Cloud.

  • Es posible que tengas que configurar un nuevo grupo de seguridad para permitir las conexiones remotas en los puertos necesarios.

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

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

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

  • MySQL limita el nombre de host a 60 caracteres. Los nombres de host de las bases de datos de Amazon RDS suelen tener más de 60 caracteres. Si este es el caso de la base de datos que vas a migrar, configura una redirección 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 utilizas 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 de MySQL esté configurado en ROW.

  • Si usas herramientas de terceros, normalmente se requieren ajustes y configuraciones 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 de instancias y los requisitos previos, consulta Configurar el servidor externo para la replicación de MySQL.

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

  • Si decides usar Database Migration Service, debes configurar tu base de datos de origen antes de conectarte a ella. Revisa las tareas de migración antes de implementarlas. Para obtener más información, consulta el artículo sobre cómo configurar el origen de MySQL.
  • En función del motor de la base de datos, es posible que tengas que cambiar algunas funciones. Por ejemplo, Cloud SQL para MySQL solo admite el motor de base de datos InnoDB. Debes cambiar las tablas MyISAM a InnoDB.
  • Algunas herramientas de migración de terceros requieren que todas las columnas LOB sean anulables. Las columnas LOB que sean NOT NULL deben tener esa restricción eliminada durante la migración.

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

    • Mide el tamaño de tus datos, así como el rendimiento de tu carga de trabajo. ¿Cuánto tiempo tardan de media las consultas o transacciones importantes? ¿Cuánto tiempo durante las horas punta?
    • Documenta las mediciones de referencia para compararlas más adelante y así decidir si la fidelidad de la migración de tu 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 casos de fallo.

Configuración de Cloud SQL

Elige cuidadosamente el tamaño y las especificaciones de la instancia de base de datos de Cloud SQL para MySQL de destino para que coincidan con la fuente y así satisfacer las necesidades de rendimiento. Presta especial atención al tamaño y al rendimiento del disco, a las IOPS y al número de vCPUs. Si el tamaño es incorrecto, los tiempos de migración pueden ser largos y pueden producirse 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 las instancias de Cloud SQL de destino. Las instancias de Cloud SQL no se pueden migrar entre proyectos y regiones sin transferir datos. Google Cloud
  • Migra a una versión principal coincidente en Cloud SQL. Por ejemplo, si tu origen usa MySQL 8.0.34 en Amazon RDS o Amazon Aurora, debes migrar a Cloud SQL para MySQL 8.0.34.
  • Replica la información de los usuarios por separado si usas copias de seguridad del motor de base de datos integrado o Database Migration Service. Cloud SQL gestiona los usuarios mediante la gestión de identidades y accesos de Google. Para obtener más información, consulta las limitaciones de la sección Copias de seguridad del motor de base de datos integrado.
  • Revisa las marcas de configuración del motor de base de datos y compara los valores de las instancias de origen y de destino. Asegúrate de entender su impacto y si deben ser iguales o no. Por ejemplo, te recomendamos que ejecutes el comando SHOW VARIABLES en tu base de datos de origen antes de la migración y, a continuación, lo vuelvas a ejecutar 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 se permiten todas las marcas de MySQL en una instancia de Cloud SQL.

Para obtener más información sobre la configuración de Cloud SQL, consulta lo siguiente:

Configuración específica de la migración

Si importas archivos de volcado de SQL a Cloud SQL, es posible que tengas que crear un segmento de Cloud Storage. El segmento 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 conseguir mediante las opciones de conectividad documentadas.

En función de tu situación y de la criticidad, es posible que tengas que implementar un escenario de respaldo, que suele incluir la inversión de 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.

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

Puedes retirar los recursos que conectan tu entorno de Amazon y Google Cloud una vez que se haya completado y validado la migración.

Para obtener más información, consulta las siguientes secciones:

Definir las tareas de ejecución

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

Copias de seguridad de motores de bases de datos integradas

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

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

Tareas de migración de Database Migration Service

Define y configura tareas de migración en Database Migration Service para migrar datos de una instancia de origen a la base de datos de destino. Las tareas de migración se conectan a la instancia de 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 puede ejecutar correctamente. Elige un momento en el que tus cargas de trabajo puedan permitirse un breve tiempo de inactividad para la migración y el cambio a producción.

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

El servicio de migración de bases de datos necesita unos segundos para obtener el bloqueo de lectura de 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 conseguir el bloqueo de lectura, puede que se necesite un tiempo de inactividad de escritura de entre 1 y 49 segundos. El tiempo de inactividad depende del número de tablas de tu base de datos. Por ejemplo, 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 promoción. Al promover una instancia de base de datos, se desconecta la base de datos de destino del flujo de cambios procedentes de la base de datos de origen. A continuación, la instancia de destino, que ahora es independiente, se convierte en una instancia principal. Este enfoque también se denomina a veces "cambio a producción".

Para obtener más información sobre las tareas de migración en Database Migration Service, consulta los siguientes artículos:

Para obtener información detallada sobre el proceso de configuración de la migración, consulta el artículo Migrar 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 una tarea 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 empezar con un volcado inicial que se pueda almacenar en un segmento de Cloud Storage y, a continuación, importar los datos a Cloud SQL para MySQL. A continuación, inicia el proceso de replicación.

Monitoriza la replicación y detén las escrituras en la instancia de origen en el momento oportuno. Vuelve a comprobar el estado de la replicación para asegurarte de que se han replicado todos los cambios y, a continuación, convierte la réplica de Cloud SQL para MySQL en 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 los artículos Información sobre la replicación desde un servidor externo y Configurar Cloud SQL y el servidor externo para la replicación.

Para obtener más información y orientación, consulta los siguientes recursos:

Herramientas de terceros

Define las tareas de ejecución de la herramienta de terceros que hayas elegido.

En esta sección, nos centraremos en Striim como ejemplo. Striim usa aplicaciones que adquieren datos de varias fuentes, los procesan y, a continuación, los envían a otras aplicaciones u objetivos.

Las aplicaciones se pueden crear gráficamente mediante el cliente web y contienen fuentes, destinos y otros componentes lógicos organizados en uno o varios flujos.

Para configurar tu entorno de migración en Striim, puedes usar la función Diseñador de flujo para crear y cambiar aplicaciones, o bien seleccionar una de las plantillas predefinidas. Las aplicaciones también se pueden codificar mediante el lenguaje de programación TQL.

Puedes obtener una representación visual de los datos que gestiona tu aplicación de Striim mediante un panel de control de validación de datos.

Para empezar a usar Striim en Google Cloudrápidamente, consulta el artículo Ejecutar Striim en Google Cloud. Para obtener más información sobre los conceptos básicos de Striim, consulta Conceptos de Striim. También debes leer la guía de prácticas recomendadas para pasar de una carga inicial a una replicación continua.

Ten en cuenta las siguientes prácticas recomendadas para migrar tus datos:

  • Informa a los equipos implicados cada vez que empiece y termine cada uno de los pasos del plan.
  • Si alguno de los pasos tarda más de lo previsto, compara el tiempo transcurrido con el tiempo máximo asignado a cada paso. Publica actualizaciones intermedias periódicas a los equipos implicados cuando esto ocurra.
  • Si el intervalo de tiempo es superior al tiempo máximo reservado para cada paso del plan, considera la posibilidad de volver a la versión anterior.
  • Toma decisiones sobre si se puede continuar o no en cada paso del plan de migración y cambio.
  • Ten en cuenta las acciones de reversión o los escenarios alternativos para cada uno de los pasos.

Definir escenarios de respaldo

Define tareas alternativas para cada tarea de ejecución de la migración, de modo que se puedan llevar a cabo si surgen problemas imprevistos durante el proceso de migración. Las tareas de reserva suelen depender de la estrategia de migración y de las herramientas que se utilicen.

La alternativa puede requerir un esfuerzo considerable. Como práctica recomendada, no hagas el cambio a producción hasta que los resultados de las pruebas sean satisfactorios. Tanto la migración de la base de datos como el escenario de respaldo deben probarse correctamente para evitar una interrupción grave.

Define los criterios de éxito y limita el tiempo de todas las tareas de ejecución de la migración. Hacer una prueba de migración le ayuda a recoger información sobre los tiempos previstos de cada tarea. Por ejemplo, en una migración de mantenimiento programado, puedes permitirte el tiempo de inactividad representado por la ventana de cambio. Sin embargo, es importante que planifiques tu próxima acción por si la tarea de migración única o la restauración de la copia de seguridad falla a mitad de proceso. En función del tiempo de inactividad planificado que haya transcurrido, es posible que tengas que posponer la migración si la tarea no finaliza en el tiempo previsto.

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

Si decides no tener un plan de respaldo, asegúrate de que entiendes las posibles consecuencias. No tener un plan de respaldo puede suponer un esfuerzo imprevisto y provocar interrupciones evitables en el proceso de migración.

Aunque la opción de recuperación es el último recurso y la mayoría de las migraciones de bases de datos no la utilizan, te recomendamos que siempre tengas una estrategia de recuperación.

Respaldo sencillo

En esta estrategia de respaldo, vuelves a cambiar tus aplicaciones a la instancia de base de datos de origen. Adopta esta estrategia si puedes permitirte un tiempo de inactividad cuando vuelvas a la versión anterior o si no necesitas que las transacciones se confirmen 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 detener las escrituras en tu instancia de base de datos de destino, crear copias de seguridad integradas y restaurarlas en tu instancia de origen. Después, vuelve a conectar tus aplicaciones a la instancia de base de datos de origen inicial. En función de la naturaleza de tu carga de trabajo y de la cantidad de datos escritos en la instancia de base de datos de destino, puedes incorporarla a tu sistema de base de datos de origen inicial más adelante, sobre todo si tus cargas de trabajo no dependen de ninguna hora de creación de registros específica ni de ninguna restricción de orden cronológico.

Replicación inversa

En esta estrategia, se replican las escrituras que se producen en la nueva base de datos de destino después de la puesta en marcha de la producción en la base de datos de origen inicial. De esta forma, mantienes la fuente original sincronizada con la nueva base de datos de destino y las escrituras se realizan en la nueva instancia de base de datos de destino. Su principal desventaja es que no puedes probar el flujo de replicación hasta que cambies a la instancia de base de datos de destino, por lo que no permite realizar pruebas integrales y tiene un breve periodo sin opción de revertir los cambios.

Elige este método si puedes conservar la instancia de origen durante un tiempo y vas a migrar mediante la migración de replicación continua.

Replicación directa

Esta estrategia es una variación de la replicación inversa. Replicas las escrituras de 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, en función de tus necesidades. La ventaja de este enfoque es que se puede probar de principio a fin.

Adopta esta estrategia si quieres que haya una alternativa en todo momento o si debes descartar la base de datos de origen inicial poco después de la puesta en marcha.

Operaciones de escritura duplicadas

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

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

Recomendamos este enfoque cuando sea fundamental que no haya tiempo de inactividad durante la migración, cuando tengas una alternativa fiable y cuando tengas tiempo y recursos para refactorizar la aplicación.

Realizar pruebas y validaciones

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

  • Migración correcta de los datos de la base de datos.
  • Integración con aplicaciones que ya existen después de que se cambien para usar la nueva instancia de destino.

Define los factores de éxito clave, que son subjetivos en tu migración. Estos son algunos ejemplos de factores subjetivos:

  • Qué datos quieres migrar. En algunas cargas de trabajo, puede que no sea necesario migrar todos los datos. Puede que no quieras migrar datos que ya estén agregados, que sean redundantes, que estén archivados o que sean antiguos. Puedes archivar esos datos en un segmento de Cloud Storage como copia de seguridad.
  • Un porcentaje aceptable de pérdida de datos. Esto se aplica especialmente a los datos utilizados en cargas de trabajo de analíticas, en las que la pérdida de una parte de los datos no afecta a las tendencias generales ni al rendimiento de las 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. Es posible que algunas transacciones empresariales sean más lentas en el entorno de destino, pero el tiempo de procesamiento sigue estando dentro de los límites definidos.

Es posible que las configuraciones de almacenamiento de tu entorno de origen no se correspondan directamente con losGoogle Cloud entornos de destino. Por ejemplo, las configuraciones de los volúmenes SSD de uso general (gp2 y gp3) con rendimiento de ráfaga de IOPS o SSD de IOPS aprovisionadas. Para comparar y dimensionar correctamente las instancias de destino, compara las instancias de origen en las fases de evaluación y validación.

En el proceso de creación de comparativas, se aplican secuencias de operaciones similares a las de producción a las instancias de la base de datos. Durante este tiempo, se recogen y procesan métricas para medir y comparar el rendimiento relativo de los sistemas de origen y de destino.

En las configuraciones convencionales basadas en servidores, utilice las mediciones pertinentes observadas durante las cargas máximas. En el caso de los modelos de capacidad de recursos flexibles, como Aurora Serverless, te recomendamos que consultes el historial de datos de métricas para observar tus necesidades de escalado.

Puedes usar las siguientes herramientas para probar, validar y comparar bases de datos:

  • HammerDB una herramienta de código abierto para realizar pruebas de carga y comparativas de bases de datos. Admite cargas de trabajo analíticas y transaccionales complejas basadas en estándares del sector en varios motores de bases de datos (tanto TPROC-C como TPROC-H). HammerDB tiene documentación detallada y una amplia comunidad de usuarios. Puede compartir y comparar resultados en varios motores de bases de datos y configuraciones de almacenamiento. Para obtener más información, consulta Pruebas de carga de SQL Server con HammerDB y Comparar el rendimiento de Amazon RDS SQL Server con HammerDB.
  • Herramienta de evaluación comparativa DBT2: evaluación comparativa especializada para MySQL. Un conjunto de kits de carga de trabajo de bases de datos imita una aplicación de una empresa que tiene 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 online (OLTP) prediseñada.
  • DbUnit una herramienta de prueba unitaria de código abierto que se usa para probar las interacciones de bases de datos relacionales 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, en función del tamaño y la complejidad de la base de datos. Recomendamos esta herramienta cuando la sencillez 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. Utiliza una sintaxis básica para crear casos de prueba y ofrece pruebas basadas en datos, control de versiones e informes de resultados de pruebas. Sin embargo, la compatibilidad con consultas y transacciones complejas es limitada y no cuenta con una gran comunidad ni con documentación extensa, en comparación con otras herramientas. Recomendamos esta herramienta si tus consultas no son complejas y quieres realizar pruebas automatizadas e integrarlas en tu proceso de integración y entrega continuas.

Para realizar una prueba integral, incluida la del plan de migración, siempre debes hacer una prueba de migración. Una prueba de ejecución realiza la migración de la base de datos a gran escala sin cambiar ninguna carga de trabajo de producción y ofrece las siguientes ventajas:

  • Te permite asegurarte de que todos los objetos y configuraciones se migren correctamente.
  • Te ayuda a definir y ejecutar tus casos de prueba de migración.
  • Ofrece información valiosa sobre el tiempo necesario para la migración real, de modo que puedas ajustar tu cronología.
  • Representa una oportunidad para probar, validar y adaptar el plan de migración. A veces no puedes planificar todo con antelación, por lo que esta función te ayuda a detectar cualquier laguna.

Las pruebas de datos se pueden realizar en un pequeño conjunto de las bases de datos que se van a migrar o en todo el conjunto. En función del número total de bases de datos y de las herramientas que se utilicen para implementar su migración, puedes adoptar un enfoque basado en el riesgo. Con este método, se valida un subconjunto de bases de datos migradas con la misma herramienta, sobre todo si se trata de un servicio de migración gestionado.

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

  • Comparar los esquemas de origen y de destino. Comprueba si existen todas las tablas y los ejecutables. Comprueba el número de filas y compara los datos a nivel de base de datos.
  • Ejecuta secuencias de comandos de validación de datos personalizadas.
  • Comprueba que los datos migrados también se vean en las aplicaciones que hayan cambiado a 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 prácticos. 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 bases de datos más usadas para observar si hay alguna degradación debido a configuraciones incorrectas o a un tamaño inadecuado.

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 conjunto de casos de prueba automatizados se adapta para realizar pruebas en las aplicaciones cambiadas.

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

Herramienta de validación de datos

Para validar los datos, le recomendamos que utilice la herramienta de validación de datos (DVT). DVT es una herramienta de CLI de Python de código abierto respaldada por Google que proporciona una solución automatizada y repetible para la validación en diferentes entornos.

La herramienta de validación de datos puede ayudar a agilizar el proceso de validación de datos ofreciendo funciones de validación multinivel personalizadas para comparar tablas de origen y de destino a nivel de tabla, columna y fila. También puedes añadir reglas de validación.

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

La herramienta de validación de datos admite los siguientes tipos de validaciones:

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

Para obtener más información sobre la herramienta de validación de datos, consulte el repositorio de Git y el artículo Validar datos es fácil con la herramienta de validación de datos de Google Cloud.

Realizar la migración

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

Ten en cuenta las siguientes prácticas recomendadas para migrar tus datos:

  • Informa a los equipos implicados cada vez que empiece y termine un paso del plan.
  • Si alguno de los pasos tarda más de lo previsto, compara el tiempo transcurrido con el tiempo máximo asignado a ese paso. Publica actualizaciones intermedias periódicas a los equipos implicados cuando esto ocurra.
  • Si el intervalo de tiempo es superior al tiempo máximo reservado para cada paso del plan, considera la posibilidad de volver a la versión anterior.
  • Toma decisiones sobre si se puede continuar o no en cada paso del plan de migración y cambio.
  • Ten en cuenta las acciones de reversión o los escenarios alternativos 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 hayas seleccionado.

Realizar el cambio a producción

El proceso de cambio a producción de alto nivel puede variar en función de la estrategia de migración que elijas. Si puedes permitir que tus cargas de trabajo tengan un tiempo de inactividad, la migración comienza deteniendo las escrituras en tu base de datos de origen.

En las migraciones de replicación continua, normalmente se siguen estos pasos generales en el proceso de cambio:

  • Dejar de escribir en la base de datos de origen.
  • Agotar la fuente.
  • Detén el proceso de replicación.
  • Implementa las aplicaciones que apuntan a la nueva base de datos de destino.

Una vez que se hayan migrado los datos con la herramienta de migración elegida, valide 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 cumplen los estándares de éxito de la migración que has elegido.

Una vez que la validación de datos cumpla tus criterios, podrás realizar el cambio a nivel de aplicación. Despliega las cargas de trabajo que se han refactorizado para usar la nueva instancia de destino. Despliega las versiones de tus aplicaciones que apuntan a la nueva instancia de base de datos de destino. Los despliegues se pueden llevar a cabo mediante actualizaciones continuas, lanzamientos progresivos o con un patrón de despliegue azul-verde. Es posible que se produzca un tiempo de inactividad de la aplicación.

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

  • Monitoriza las aplicaciones que funcionan con la base de datos de destino después del cambio.
  • Define un periodo de monitorización para determinar si necesitas implementar tu plan de respaldo.
  • Ten en cuenta que es posible que tengas que reiniciar tu instancia de Cloud SQL o AlloyDB para PostgreSQL si cambias algunas marcas de base de datos.
  • Ten en cuenta que el esfuerzo necesario para revertir la migración puede ser mayor que el que se requiere para solucionar los problemas que aparecen en el entorno de destino.

Limpiar el entorno de origen y configurar la instancia de Cloud SQL o AlloyDB para PostgreSQL

Una vez completado el cambio, puedes eliminar las bases de datos de origen. Te recomendamos que realices las siguientes acciones importantes antes de limpiar tu instancia de origen:

  • Crea una copia de seguridad final de cada base de datos de origen. Estas copias de seguridad te proporcionan el estado final de las bases de datos de origen. También es posible que se necesiten copias de seguridad en algunos casos para cumplir determinadas normativas sobre datos.

  • Recoge los ajustes de los parámetros de la base de datos de tu instancia de origen. También puedes comprobar que coincidan con los que has recogido 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.

  • Recoge 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 un escenario de fallback, puede que quieras implementar la replicación de tus escrituras en la instancia de Cloud SQL en tu base de datos de origen original. La configuración se parece al proceso de migración, pero se ejecutaría al revés: 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 del cambio, replica las escrituras realizadas en las instancias de Cloud SQL de destino en la base de datos de origen. Si necesitas revertir el proceso, puedes volver a tus instancias de origen antiguas con una pérdida de datos mínima.

Además de limpiar el entorno de origen, debe realizar las siguientes configuraciones críticas en sus instancias de Cloud SQL:

  • Configura una ventana de mantenimiento para tu instancia principal y controla cuándo se pueden producir actualizaciones disruptivas.
  • Configura el almacenamiento de la instancia para que tengas al menos un 20 % de espacio disponible para las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL. Para recibir una alerta si el espacio en disco disponible es inferior al 20%, crea una política de alertas basada en métricas para la métrica de utilización del disco.

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

Para obtener más información sobre el mantenimiento y las prácticas recomendadas, consulta el artículo Mantenimiento de las instancias de Cloud SQL.

Optimizar el entorno después de la migración

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

  1. Evalúa tu entorno, tus equipos y tu bucle de optimización actuales.
  2. Establezca sus requisitos y objetivos de optimización.
  3. Optimiza tu entorno y tus equipos.
  4. Ajusta 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, consulta los artículos Migrar a Google Cloud: optimizar tu entorno y Google Cloud Well-Architected Framework: optimización del rendimiento. Google Cloud

Establecer los requisitos de optimización

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

Aumentar la fiabilidad y la disponibilidad de tu base de datos

Con Cloud SQL, puedes implementar una estrategia de alta disponibilidad y recuperación tras fallos que se ajuste a tu objetivo de tiempo de recuperación (RTO) y a tu objetivo de punto de recuperación (RPO). Para aumentar la fiabilidad y la disponibilidad, ten en cuenta lo siguiente:

  • En el caso de cargas de trabajo con muchas lecturas, añade réplicas de lectura para descargar el tráfico de la instancia principal.
  • Para las cargas de trabajo de misión crítica, usa la configuración de alta disponibilidad, las réplicas para la conmutación por error regional y una configuración de recuperación tras fallos sólida.
  • Para las cargas de trabajo menos críticas, las copias de seguridad automáticas y bajo demanda pueden ser suficientes.
  • Para evitar que se eliminen instancias por error, usa la protección contra eliminación de instancias.
  • Puedes usar la edición Enterprise Plus de Cloud SQL para disfrutar de una mayor disponibilidad, retención de registros y un tiempo de inactividad casi nulo durante el mantenimiento programado. Para obtener más información sobre Cloud SQL Enterprise Plus, consulta los artículos Introducción a las ediciones de Cloud SQL y Mantenimiento programado con un tiempo de inactividad casi nulo.

Para obtener más información sobre cómo aumentar la fiabilidad y la disponibilidad de tu base de datos, consulta lo siguiente:

Aumentar la rentabilidad de tu infraestructura de base de datos

Para que tus cargas de trabajo tengan un impacto económico positivo, deben usar los recursos y servicios disponibles de forma eficiente. Dispone de estas opciones:

  • Proporciona a la base de datos la capacidad de almacenamiento mínima necesaria haciendo lo siguiente:

    • Para escalar la capacidad de almacenamiento automáticamente a medida que aumentan los datos, habilita los aumentos automáticos de almacenamiento. Sin embargo, asegúrate de configurar tus instancias para que tengan algo de margen en las cargas de trabajo máximas. Recuerda que las cargas de trabajo de las bases de datos suelen aumentar con el tiempo.

  • Identifica los recursos que se hayan sobreestimado:

    • Si ajustas el tamaño de tus instancias de Cloud SQL, puedes reducir el coste de la infraestructura sin añadir riesgos adicionales a la estrategia de gestión de la capacidad.
    • Cloud Monitoring proporciona paneles de control predefinidos que ayudan a identificar el estado y la utilización de la capacidad de muchos Google Cloud componentes, incluido Cloud SQL. Para obtener más información, consulta el artículo Crear y gestionar paneles de control personalizados.

  • Identifica las instancias que no requieren configuraciones de alta disponibilidad o recuperación tras desastres y elimínalas de tu infraestructura.

  • Elimina las tablas y los objetos que ya no necesites. Puedes almacenarlos en una copia de seguridad completa o en un segmento de Cloud Storage de archivo.

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

    • En la mayoría de los casos prácticos, las unidades SSD son la opción más eficiente y rentable.
    • Si sus conjuntos de datos son grandes (10 TB o más), no son sensibles a la latencia o se accede a ellos con poca frecuencia, puede que los discos duros sean más adecuados.
    • Para obtener más información, consulta el artículo Elegir entre almacenamiento SSD y HDD.

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

  • Usa Active Assist para obtener estadísticas y recomendaciones sobre los costes.

    Para obtener más información y opciones, consulta el artículo Aprovecha al máximo tus recursos: presentamos las recomendaciones de optimización de costes de Cloud SQL con Active Assist.

Aumentar el rendimiento de la infraestructura de tu base de datos

Los problemas de rendimiento leves relacionados con las bases de datos suelen tener el potencial de afectar a toda la operación. Para mantener y mejorar el rendimiento de tu instancia de Cloud SQL, ten en cuenta las siguientes directrices:

  • Si tienes un gran número de tablas de bases de datos, pueden afectar al rendimiento y la disponibilidad de la instancia, así como provocar que la instancia pierda la cobertura de su acuerdo de nivel de servicio.

  • Asegúrate de que tu instancia no tenga limitaciones de memoria o CPU.

    • En el caso de las cargas de trabajo que requieren un alto rendimiento, asegúrate de que tu instancia tenga al menos 60 GB de memoria.
    • Si las inserciones, actualizaciones o eliminaciones de la base de datos son lentas, compruebe las ubicaciones del escritor y de la base de datos. El envío de datos a largas distancias introduce latencia.

  • Mejora el rendimiento de las consultas mediante el panel de control predefinido de Query Insights en Cloud Monitoring (o funciones integradas similares del motor de base de datos). Identifica los comandos más caros e intenta optimizarlos.

  • Evita que los archivos de la base de datos sean innecesariamente grandes. Defina autogrow en MB en lugar de como porcentaje, con incrementos adecuados al requisito.

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

  • Te recomendamos que uses la edición Enterprise Plus de Cloud SQL para beneficiarte de los límites de configuración de las máquinas y de la caché de datos. Para obtener más información, consulta el artículo Introducción a las ediciones de Cloud SQL.

Para obtener más información sobre cómo mejorar el rendimiento, consulta la sección Rendimiento del artículo "Diagnosticar problemas".

Aumentar las funciones de observabilidad de bases de datos

Diagnosticar y solucionar problemas en aplicaciones que se conectan a instancias de bases de datos puede ser difícil y llevar mucho tiempo. Por este motivo, es fundamental contar con un lugar centralizado donde todos los miembros del equipo puedan ver lo que ocurre a nivel de base de datos e instancia. Puede monitorizar las instancias de Cloud SQL de las siguientes formas:

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

    • Usa Cloud Monitoring para recoger mediciones de tu servicio y de los Google Cloudrecursos que utilices. Cloud Monitoring incluye paneles de control predefinidos para varios productos de Google Cloud , incluido un panel de control de monitorización de Cloud SQL.
    • Puedes crear paneles de control personalizados que te ayuden a monitorizar métricas y configurar políticas de alertas para recibir notificaciones oportunas.
    • También puedes usar soluciones de monitorización de terceros integradas con Google Cloud, como Datadog y Splunk.

  • Cloud Logging recoge datos de registro de componentes de aplicaciones comunes.

  • Cloud Trace recoge datos de latencia y planes de consulta ejecutados de las aplicaciones para ayudarte a monitorizar cómo se propagan las solicitudes por tu aplicación.

  • Database Center proporciona una vista general centralizada de la flota de bases de datos asistida por IA. Puedes monitorizar el estado de tus bases de datos, la configuración de la disponibilidad, la protección de datos, la seguridad y el cumplimiento de normativas del sector.

Prácticas recomendadas y directrices operativas generales de Cloud SQL

Aplica las prácticas recomendadas de Cloud SQL para configurar y optimizar 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 siempre que sea posible.
  • Configura el almacenamiento para que se adapte al mantenimiento crítico de la base de datos. Asegúrate de tener al menos un 20% de espacio disponible para las operaciones de mantenimiento críticas de la base de datos que pueda realizar Cloud SQL.
  • Si hay demasiadas tablas de bases de datos, el tiempo de actualización de la base de datos puede verse afectado. Lo ideal es que haya menos de 10.000 tablas por instancia.
  • Elige el tamaño adecuado para tus instancias para tener en cuenta la conservación de los registros de transacciones (binarios), sobre todo en el caso de las instancias con una alta actividad de escritura.

Para poder gestionar de forma eficiente cualquier problema de rendimiento de la base de datos que pueda surgir, siga estas directrices hasta que se resuelva el problema:

Escalar verticalmente la infraestructura: aumenta los recursos (como el rendimiento del disco, la vCPU y la RAM). En función de la urgencia, la disponibilidad y la experiencia de tu equipo, puedes resolver la mayoría de los problemas de rendimiento escalando verticalmente tu instancia. Más adelante, puedes investigar más a fondo la causa principal del problema en un entorno de prueba y plantearte opciones para eliminarlo.

Realizar y programar operaciones de mantenimiento de bases de datos: desfragmentación de índices, actualizaciones de estadísticas, análisis de vacío y reindexación de tablas que se hayan actualizado mucho. Comprueba si se han realizado estas operaciones de mantenimiento y cuándo, sobre todo en los objetos afectados (tablas e índices). Descubre si ha habido algún cambio en las actividades normales de la base de datos. Por ejemplo, si has añadido una columna recientemente o si una tabla tiene muchas actualizaciones.

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

Escala horizontalmente las lecturas: considera la posibilidad de tener réplicas de lectura. Si el escalado vertical no es suficiente para tus necesidades y las medidas de ajuste y optimización de la base de datos no te ayudan, considera la posibilidad de usar el escalado horizontal. Dirigir las consultas de lectura de tus aplicaciones a una réplica de lectura mejora el rendimiento general de la carga de trabajo de tu base de datos. Sin embargo, puede que tengas que hacer más ajustes para que tus aplicaciones se conecten a la réplica de lectura.

Reestructuración de la base de datos: plantéate particionar e indexar la base de datos. Esta operación requiere mucho más esfuerzo que 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 provocar problemas de rendimiento, que se pueden compensar parcialmente con un escalado vertical. Sin embargo, un modelo de datos adecuado es una solución a largo plazo. Considera la posibilidad de crear particiones en tus tablas. Archiva los datos que ya no necesites, si es posible. Normaliza la estructura de tu base de datos, pero recuerda que la desnormalización también puede mejorar el rendimiento.

Partición de bases de datos: puedes escalar las escrituras particionando tu base de datos. El particionado es una operación compleja que implica rediseñar la arquitectura de tu base de datos y tus aplicaciones de una forma específica, así como migrar los datos. Divide tu instancia de base de datos en varias instancias más pequeñas mediante un criterio de partición específico. Los criterios pueden basarse en el cliente o en el asunto. Esta opción te permite escalar horizontalmente tanto las escrituras como las lecturas. Sin embargo, aumenta la complejidad de las cargas de trabajo de la base de datos y de las aplicaciones. También puede provocar que se creen particiones desequilibradas, llamadas puntos de acceso, que superen las ventajas de la partición. - En el caso de 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 principales o únicas.

Para obtener más información, consulta las prácticas recomendadas generales y las directrices operativas de Cloud SQL para MySQL.

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: