Existen varias formas de migrar a MySQL en Cloud SQL. La estrategia de migración para una fuente determinada depende de varios factores, incluidos 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. Repasemos algunas de las estrategias de migración más comunes.

Si migras a una base de datos pequeña que tiene un tamaño de unos pocos gigabytes o que contiene datos estáticos, el enfoque más fácil es tomar un volcado de la base de datos a través de la utilidad mysqldump. Sube el archivo de volcado a Cloud Storage e impórtalo en una instancia de Cloud SQL mediante las instrucciones del artículo sobre cómo exportar e importar con archivos de volcado de SQL.

Debido a que los archivos de volcado contienen instrucciones lógicas de SQL, una ventaja de este enfoque es que permite editar los archivos de volcado antes de cargarlos en Cloud Storage. Sin embargo, dadas ciertas restricciones de Cloud SQL, evita incluir cualquier información en el archivo de volcado que pueda interrumpir una importación, como se detalla en las prácticas recomendadas para importar y exportar datos.

Cuando se migran muchas instancias de MySQL o para realizar migraciones más grandes, una mejor opción es usar Database Migration Service (DMS). Este es un servicio que proporciona una variedad de rutas de migración, incluidas las rutas para migraciones homogéneas y heterogéneas a MySQL, y también admite SQL Server y PostgreSQL como destinos de migración.

Para la mayoría de las migraciones de bases de datos de tamaño mediano a grande, usar DMS debería ser suficiente. Algunas situaciones en las que DMS podría no ser adecuado incluyen el uso de bases de datos muy grandes (de varios TB de tamaño) o si tienes ingenieros de MySQL con conocimientos de replicación y que prefieren un control más detallado del proceso de migración mediante la replicación nativa de MySQL.

Si minimizar el tiempo de inactividad es una prioridad durante la migración y tienes ingenieros experimentados en MySQL en tu equipo, entonces replicar desde una fuente externa (ES, por sus siglas en inglés) mediante la replicación nativa basada en registros binarios es una opción. Este método aprovecha la importación de una instantánea de referencia de la base de datos con un método como una importación de Cloud Storage.

Luego, debes configurar la replicación de MySQL de la instancia de origen a la instancia de Cloud SQL de destino mediante un conjunto de procedimientos almacenados y creados previamente que ya están disponibles en la instancia de Cloud SQL. Las instrucciones completas se encuentran en el artículo Usa una importación personalizada para configurar la replicación desde bases de datos externas grandes.

Un detalle clave cuando se usa la replicación basada en registros binarios para la migración es que los registros binarios de la instancia de origen permanecen disponibles hasta que la instancia de Cloud SQL de destino ya no los necesita. Cuando se ejecuta MySQL local o autoadministrado, se pueden configurar parámetros como expire_logs_days para controlar la eliminación definitiva de registros binarios. Sin embargo, otros servicios administrados de proveedores de servicios en la nube tienen su propia restricción sobre la retención de registros binarios.

Por ejemplo, Amazon Relational Database Service (RDS) permite configurar la retención de registros binarios a través del nombre de un procedimiento almacenado mysql.rds_set_configuration. Esto permite una retención de hasta siete días. En la mayoría de los casos, siete días es suficiente para gran parte de las migraciones de tamaño pequeño a mediano desde RDS a Cloud SQL. En esas situaciones, los usuarios pueden aprovechar un proceso bien documentado que implica crear una réplica de RDS administrada. Luego, haz algo para "romper" la replicación, como permitir la escritura en la réplica y borrar una fila, o insertar una transacción que funcione como "píldora venenosa" en la instancia principal que se abra paso en el registro binario e interrumpa la replicación. La automatización de RDS no borrará definitivamente los registros binarios, siempre que la réplica los necesite (aunque parece que hay un límite general de 30 días antes de que RDS “finalice” una transmisión de replicación interrumpida).

Otra solución alternativa es usar el cliente mysqlbinlog para descargar registros binarios en otra instancia intermedia de MySQL a fin de evitar la eliminación prematura de registros binarios. Por ejemplo, en RDS, hay un procedimiento almacenado llamado mysql.rds_set_configuration que permite establecer un período de retención en horas para garantizar que los registros binarios permanezcan en el host por un tiempo suficiente para descargarlos. En este caso, no necesitas poner en funcionamiento una instancia de MySQL como intermediaria, ya que cualquier servidor, como un “Binlog Server”, que parece una instancia de MySQL, está allí para almacenar y reenviar registros binarios.

MySQL es único entre los sistemas de bases de datos relacionales más populares, ya que admite varios motores de almacenamiento conectables. Originalmente, MySQL admitía un único motor de almacenamiento conocido como MyISAM y, hasta MySQL 8.0, la mayoría de las tablas del sistema usaban este motor de almacenamiento. Sin embargo, MyISAM no tenía compatibilidad con transacciones y no fue seguro contra fallas en caso de un cierre repentino del sistema o una falla de la base de datos.

Desde entonces, InnoDB se convirtió en el motor de almacenamiento de facto para la mayoría de las tablas de usuarios de MySQL debido a su arquitectura segura ante fallas y a la compatibilidad con transacciones. Sin embargo, hay otros motores de almacenamiento que se ven comúnmente en la comunidad de MySQL, tanto a nivel local como en otros proveedores de servicios en la nube, incluidos los siguientes:

• ARCHIVE: almacena datos en un formato muy comprimido para fines de archivo
• CSV: almacena datos en un formato separado por comas (CSV) y se usa para las tablas de registro del registro de consultas general y de consultas lentas
• MEMORY: almacena tablas en la memoria

En el caso de Cloud SQL, se requiere un motor de almacenamiento que sea transaccional y seguro ante fallas a fin de admitir funciones de valor agregado, como la replicación y la recuperación de un momento determinado. Por lo tanto, todas las tablas de usuario que se migran a Cloud SQL deben usar el motor de almacenamiento InnoDB o convertirse a InnoDB durante el proceso de migración.

Esto es muy importante si realizas la replicación nativa de MySQL de una fuente externa a Cloud SQL. Si bien Cloud SQL no permite que los usuarios creen una tabla MyISAM directamente en una instancia de Cloud SQL a través de comandos de lenguaje de definición de datos (DDL) como CREATE TABLE, en este momento, es posible replicar las tablas MyISAM desde una fuente externa a Cloud SQL.

Sin embargo, estas tablas MyISAM importadas en Cloud SQL pueden generar problemas de estabilidad y confiabilidad más adelante durante operaciones como la replicación, la recuperación de un momento determinado y la conmutación por error. Por este motivo, se recomienda convertir todas las tablas de usuario de MyISAM a InnoDB antes de realizar una migración. 

En la siguiente consulta, se mostrarán todas las tablas MyISAM que no sean del sistema.

Dado que MySQL es un servicio administrado para Cloud SQL, no se otorga el privilegio SUPER a las cuentas de usuario. Esta es una diferencia con la mayoría de las instalaciones locales de MySQL que permiten un usuario raíz con ese privilegio. Del mismo modo, la mayoría de los proveedores de servicios en la nube no proporcionan este privilegio SUPER en un entorno de MySQL administrado.

Cualquiera sea el caso, en Cloud SQL los usuarios reciben un usuario de MySQL predeterminado llamado “root’@’%” que tiene la mayoría de los privilegios proporcionados por MySQL, excepto aquellos que afectan la capacidad de Google para administrar el servicio, como SUPER mencionado anteriormente, junto con FILE y SHUTDOWN. Para obtener más detalles sobre los privilegios de uso que se proporcionan en Cloud SQL, consulta la documentación sobre usuarios de MySQL.

Cuando te preparas para migrar, revisa todas las cuentas de usuario en la instancia de origen. Por ejemplo, ejecuta el comando SHOW GRANTS para que cada usuario revise el conjunto actual de privilegios y vea si hay alguno restringido en Cloud SQL. Del mismo modo, la herramienta pt-show-grants de Percona también puede mostrar las becas.

Las restricciones de los privilegios de usuario en Cloud SQL pueden afectar las migraciones cuando se migran objetos de base de datos que tienen un atributo DEFINER. Este 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 no compatible con Cloud SQL, esto puede ser un problema durante la migración o después de ella.

Por ejemplo, un procedimiento almacenado puede tener un definidor privilegiado para ejecutar comandos de SQL, como cambiar una variable global que no está 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 aparte de migración.

Nuestra documentación tiene una sección llamada Trabajos de importación y migración de MySQL que contienen metadatos con la cláusula DEFINER en la que se explica un poco más sobre otros problemas relacionados con la cláusula de definición para los objetos de base de datos.

Debido a las restricciones de privilegios de usuario que se mencionaron antes, los usuarios no pueden llamar de forma nativa al comando SET GLOBAL para cambiar los parámetros de la base de datos. En cambio, Cloud SQL ofrece un conjunto predefinido de “marcas” que se pueden modificar a través de la consola de IU, GCloud CLI y la API de REST para modificar los parámetros.

La lista completa de marcas de Cloud SQL compatibles con MySQL se encuentra en nuestra documentación pública en la sección titulada Marcas compatibles. Antes de migrar a Cloud SQL, revisa la lista de marcas compatibles en comparación con las marcas que se usan actualmente en tu entorno de origen. Por ejemplo, se recomienda 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 la instancia de origen como en la de Cloud SQL y comparar las diferencias.

Estas son algunas marcas comunes que pueden tener diferentes opciones de configuración locales o en un proveedor de servicios en la nube en comparación con Cloud SQL para MySQL:

• La configuración de caracteres e intercalación, como character_set_server y collation_server. Los valores predeterminados pueden diferir entre las instalaciones y generar diferencias de almacenamiento y rendimiento. Por ejemplo, latin1 frente a utf8.
• Configuración de registro binario, como binlog_format. En la actualidad, Cloud SQL solo admite el registro basado en filas en el registro binario.
• Configuración de replicación avanzada. Por ejemplo, Cloud SQL no admite parámetros de filtro de replicación, 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 de InnoDB mediante el cambio de innodb_buffer_pool_size. Sin embargo, puede haber algunas configuraciones de InnoDB más detalladas que no se pueden modificar en Cloud SQL o con valores predeterminados diferentes de los locales o de otros proveedores de servicios en la nube.