Hay varias formas de migrar a MySQL en Cloud SQL. La estrategia de migración de 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.

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 archivos de 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, dadas algunas restricciones de Cloud SQL, evita incluir 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.

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 las 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 o 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.

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 creados previamente 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 y 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 en la réplica se pueda escribir y eliminar una fila, o inyectar algún tipo de transacción conocida como "píldora envenenada" en el nivel principal que llegue a los registros binarios e interrumpa la replicación. 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 mysqlbinlog client 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 retención en horas para garantizar que los registros binarios permanezcan en el host durante el tiempo suficiente para descargarlos. En este caso, no necesitas definir una instancia de MySQL como intermediario, ya que cualquier servidor, como un servidor binario, que parece una instancia de MySQL, ya está almacenando y reenviando registros binarios.

MySQL es único entre los sistemas de bases de datos relacionales más populares, ya que admite varios motores de almacenamiento 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 usaban este motor de almacenamiento. Sin embargo, MyISAM no admitía las transacciones y no era seguro 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 facto 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 motores de almacenamiento 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:

• ARCHIVE: 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 frente a fallos, para que sea 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 a 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 CREATE TABLE, 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.

Al ser un servicio gestionado, MySQL para Cloud SQL no permite el privilegio SUPER en las cuentas de usuario. Esto constituye un cambio con respecto a 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 dispone de la mayoría de los privilegios proporcionados por MySQL, excepto los que puedan impedir que Google gestione el servicio, como el privilegio SUPER mencionado anteriormente junto con FILE y SHUTDOWN. 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 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. 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 suponer 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 DEFINER, en la que se explica un poco más sobre otros problemas relacionados con la cláusula definidora de objetos de base de datos.

Debido a las restricciones de privilegio de usuario mencionadas anteriormente, los usuarios no pueden llamar de forma nativa el comando SET 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, gcloud CLI 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 SHOW GLOBAL VARIABLES 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:

• Ajustes de conjunto de caracteres y de recopilación de datos como character_set_server y collation_server. Los valores predeterminados pueden variar entre instalaciones y dar lugar a diferencias de almacenamiento y rendimiento. Por ejemplo, "latin1" frente a "utf8".
• Configuración del registro binario, como binlog_format. Actualmente, Cloud SQL solo admite registros basados en filas en el registro binario.
• Configuración de replicación avanzada. Por ejemplo, Cloud SQL no admite parámetros de filtro de réplicas como replicate-do-table y replicate-do-db.
• Configuración avanzada de InnoDB. Cloud SQL permite modificar la mayoría de los parámetros relacionados con InnoDB, como cambiar el tamaño del grupo de búferes InnoDB modificando innodb_buffer_pool_size. Sin embargo, puede que algunos ajustes de InnoDB más detallados no se puedan modificar en Cloud SQL o con valores predeterminados diferentes a los de los entornos on‐premise u otros proveedores de la nube.