Ir a

Prácticas recomendadas para migrar a Cloud SQL para MySQL

Hay que tener en cuenta muchas consideraciones a la hora de planificar y ejecutar una migración de bases de datos de MySQL a Cloud SQL para MySQL, como la complejidad de la base de datos que se migra, la cantidad de datos que necesita migrarse y el nivel de periodo de inactividad que se puede tolerar. Una de estas consideraciones es la instancia de origen de la base de datos de MySQL. La instancia de origen de MySQL se puede alojar de cualquiera de estas formas:

  • Instancia de MySQL alojada en otro proveedor de servicios en la nube, como AWS o Azure
  • Instancia de MySQL alojada en tu propio centro de datos o desde un servidor de tu oficina (lo que se conoce on-premise)

Este artículo se aplica a ambos casos.

Descripción general

Hay dos tipos principales de migraciones de bases de datos. Se considera que las migraciones de una instancia de origen que ejecuta MySQL o una base de datos con un MySQL como un frontend (por ejemplo, AWS Aurora para MySQL) a MySQL en la nube o Cloud SQL para MySQL son migraciones homogéneas. En los casos en que la instancia de origen ejecuta una base de datos diferente, como PostgreSQL, SQL Server, Oracle o cualquier otra base de datos que no sea el destino, se denomina "migración heterogénea".

En este artículo nos centraremos en las migraciones homogéneas, como suele ocurrir con Cloud SQL para MySQL. En este artículo, se tratarán formas de migrar a Cloud SQL para MySQL, consideraciones del motor de almacenamiento, privilegios de usuario y marcas de MySQL. Sin embargo, muchos de los consejos y de las prácticas también se pueden aplicar a migraciones heterogéneas.

Formas de migrar a Cloud SQL para MySQL

Hay varias formas de migrar a MySQL en Cloud SQL. La estrategia de migración para una fuente concreta depende de varios factores, como el tamaño de la base de datos, las expectativas de tiempo de inactividad y la experiencia de los ingenieros que realizan la migración. Veamos algunas de las estrategias de migración más comunes.

Importación de Cloud Storage

Si vas a migrar contenido a través de una pequeña base de datos de solo unos pocos gigabytes o que contiene datos estáticos, lo más fácil es tomar el volcado de la base de datos a través de la utilidad mysqldump. Sube el archivo de volcado a Cloud Storage e impórtalo a una instancia de Cloud SQL siguiendo las instrucciones del artículo sobre exportación e importación mediante volcado de SQL .

Puesto que los archivos de volcado contienen declaraciones SQL lógicas, una de las ventajas de este enfoque es que se pueden editar los archivos de volcado antes de cargarlos en Cloud Storage. Sin embargo, dado que algunas restricciones de Cloud SQL evitan cualquier elemento del archivo de volcado que pueda interrumpir una importación, tal como se indica en las prácticas recomendadas para importar y exportar datos.

Database Migration Service (DMS)

Si migras muchas instancias de MySQL o para migraciones de mayor tamaño, es mejor usar Database Migration Service (DMS). Este servicio proporciona diversas rutas de migración, incluidas rutas para migraciones homogéneas y heterogéneas a MySQL, así como compatibilidad con SQL Server y PostgreSQL como destinos de migración.

En la mayoría de las migraciones de bases de datos de tamaño mediano a grande, usar DMS debería ser suficiente. Entre las situaciones en las que el DMS no es adecuado se incluyen las bases de datos de gran tamaño (como varios TB) o si tienes ingenieros de MySQL con conocimientos de replicación y que prefieren tener un control más preciso del proceso de migración mediante la replicación nativa de MySQL.

Replicación de fuente externa

En este contexto, minimizar los periodos de inactividad es una prioridad durante la migración y has contado con ingenieros de MySQL en tu equipo, por lo que puedes replicar los datos de una fuente externa mediante réplicas nativas basadas en registros binarios. Este método utiliza la importación de una captura de referencia de tu base de datos mediante un método como la importación de Cloud Storage.

Después, configuras la replicación de MySQL desde la instancia de origen a la de Cloud SQL de destino mediante un conjunto de procedimientos almacenados previamente creados que ya están disponibles en la instancia de Cloud SQL. Puedes encontrar las instrucciones completas en el artículo titulado Utilizar una importación personalizada para configurar la replicación a partir de grandes bases de datos externas.

Un detalle clave al utilizar la replicación basada en registros binarios para la migración es que los registros binarios en la instancia de origen están disponibles hasta que la instancia de Cloud SQL de destino ya no los necesita. Al ejecutar MySQL on‐premise o autogestionado, parámetros como expire_logs_days se pueden configurar para controlar la purga de registros binarios. Sin embargo, otros servicios gestionados por el proveedor de servicios en la nube tienen su propia restricción sobre la conservación de registros binarios.

Por ejemplo, Amazon Relational Database Service (RDS) permite configurar la conservación de registros binarios mediante un nombre de procedimiento almacenado mysql.rds_set_configuration. De esta forma, se pueden conservar hasta 7 días. En la mayoría de los casos, basta con siete días para la mayoría de las migraciones de pequeñas a medianas empresas de RDS a Cloud SQL. En estas situaciones, los usuarios pueden aprovechar un proceso bien documentado que implica crear una réplica de RDS gestionada. A continuación, haz algo para "romper" la replicación, como hacer que la réplica se pueda escribir y eliminar una fila, o inyectar algún tipo de transacción de "píldora envenenada" en el principal que llegue a los registros binarios y no se consiga replicar. La automatización de RDS no purgará los registros binarios mientras la réplica aún los necesite (aunque parezca que hay un límite general de 30 días antes de que RDS "cancele" una emisión de replicación rota).

Otra solución alternativa es usar el cliente mysqlbinlog para descargar registros binarios en otra instancia de MySQL intermediaria para evitar la purga prematura de registros binarios. Por ejemplo, en RDS hay un procedimiento almacenado llamado mysql.rds_set_configuration que permite definir un periodo de conservación en horas para garantizar que los registros binarios permanezcan en el host durante tiempo suficiente para descargarlos. En este caso, no necesitas hacer frente a una instancia de MySQL como intermediario, ya que cualquier servidor, como un servidor binario, que parece una instancia de MySQL, está almacenando y reenviando registros binarios.

Consideraciones sobre el motor de almacenamiento

MySQL es único entre los sistemas de bases de datos relacionales más populares, ya que admite varios buscadores que se pueden conectar. Originalmente, MySQL era compatible con un solo motor de almacenamiento conocido como MyISAM y, hasta la versión 8.0 de MySQL, la mayoría de las tablas del sistema usaba este motor de almacenamiento. Sin embargo, MyISAM no admitía las transacciones y no era segura frente a un fallo repentino en el sistema o de la base de datos.

Desde entonces, InnoDB se ha convertido en el motor de almacenamiento de hecho para la mayoría de las tablas de usuarios de MySQL, debido a su arquitectura segura y a la compatibilidad con las transacciones. Hay otros buscadores habituales que se suelen ver en la comunidad de MySQL, tanto on‐premise como en otros proveedores de servicios en la nube, como los siguientes:

  • ARCHIVO: almacena los datos en un formato muy comprimido para fines de archivo.
  • CSV: almacena datos en un formato de valores separados por comas (CSV) y se utiliza para registrar tablas de registro de consultas generales y lentas.
  • MEMORY: almacena tablas en la memoria.

En el caso de Cloud SQL, se necesita un motor de almacenamiento que sea transaccional y seguro para fallos, ya que es compatible con funciones de valor añadido, como la replicación y la recuperación a un momento dado. Por tanto, todas las tablas de usuarios que se migren a Cloud SQL deben utilizar el motor de almacenamiento InnoDB o convertirse en InnoDB durante el proceso de migración.

Esto es especialmente importante si se hace una replicación nativa de MySQL desde una fuente externa a Cloud SQL. Aunque Cloud SQL no permite que los usuarios creen una tabla MyISAM directamente en una instancia de Cloud SQL mediante comandos de lenguaje de definición de datos (DDL), como CREAR TABLA, actualmente, las tablas de MyISAM se pueden replicar desde una fuente externa a Cloud SQL.

Sin embargo, estas tablas de MyISAM importadas en Cloud SQL pueden ocasionar problemas de estabilidad y fiabilidad más adelante, durante operaciones como la replicación, la recuperación a un momento dado y la conmutación por error. Por este motivo, es recomendable convertir todas las tablas de usuarios de MyISAM en InnoDB antes de hacer una migración.

La siguiente consulta mostrará todas las tablas de MyISAM que no son del sistema.

Consulta para extraer todas las tablas de MyISAM que no son del sistema

Privilegios de usuario

Al ser un servicio gestionado, MySQL para Cloud SQL no permite el privilegio SUPER en las cuentas de usuario. Es la salida de la mayoría de las instalaciones on‐premise de MySQL que permiten que un usuario raíz tenga ese privilegio. Del mismo modo, la mayoría de los demás proveedores de la nube no proporcionan este privilegio SUPER en un entorno MySQL gestionado.

En cualquier caso, los usuarios de Cloud SQL reciben un usuario de MySQL predeterminado llamado "root"@'%', que ha concedido más privilegios proporcionados por MySQL excepto los que puedan impedir que Google gestione el servicio, como el SUPER anterior junto con ARCHIVO yCERRADO. Para obtener más información sobre los privilegios de uso proporcionados en Cloud SQL, consulta la documentación sobre los usuarios de MySQL.

Antes de hacer la migración, revisa todas las cuentas de usuario de la instancia de origen. Por ejemplo, ejecuta el comando MOSTRAR 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 permisos.

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 DEFINIDOR. Suele ser el caso de los procedimientos almacenados, los activadores, las funciones definidas por el usuario y las vistas. Si el definidor de un objeto de base de datos en la instancia de origen es un usuario con un privilegio que no se admite en Cloud SQL, puede tratarse de un problema durante la migración o después de ella.

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.

En nuestra documentación hay una sección llamada Tareas de importación y migración de MySQL que contiene metadatos con la cláusula DEFINIDOR, en la que se explica un poco más sobre otros problemas relacionados con la cláusula definidor de objetos de base de datos.

Marcas

Debido a las restricciones de privilegio de usuario mencionadas anteriormente, los usuarios no pueden llamar de forma nativa el comando CONFIGURACIÓN GLOBAL para cambiar los parámetros de la base de datos. En vez de eso, Cloud SQL ofrece un conjunto predefinido de "marcas" que se pueden modificar mediante la consola de UI, la CLI de Cloud y la API REST para modificar parámetros.

Puedes consultar la lista completa de marcas compatibles de Cloud SQL para MySQL en la sección sobre marcas admitidas de la documentación pública. Antes de migrar a Cloud SQL, revisa la lista de marcas admitidas y las marcas que se están usando en tu entorno de origen. Por ejemplo, una buena práctica es crear una instancia de Cloud SQL de prueba con una configuración de CPU y memoria similar a la de tu instancia de origen y ejecutar MOSTRAR VARIABLES GLOBALES tanto en el origen como en la instancia de Cloud SQL y comparar las diferencias.

Estas son algunas de las marcas más habituales de configuraciones on‐premise o en un proveedor de la nube y Cloud SQL para MySQL:

Google Cloud ofrece una base de datos MySQL gestionada que se adapta a las necesidades de tu negocio, desde la retirada de tu centro de datos on‑premise, la ejecución de aplicaciones de software como servicio o la migración de sistemas empresariales fundamentales.