MySQL 5.7 se lanzó ya hace nueve años, y la última versión, que solo incluía correcciones menores, salió hace casi dos años. La siguiente versión disponible es MySQL 8, lo que parece un gran salto. ¿Hay que preocuparse por este cambio? Esto es especialmente relevante para los proyectos alojados en Acquia porque va a comenzar a cambiar su versión de MySQL a la 8 este mismo septiembre, es decir, ya mismo.
Entonces, ¿debería ser una preocupación? Lo más probable es que no. En primer lugar, MySQL se saltó las versiones 6 y 7, que nunca se publicaron. Es parecido a PHP, que se saltó la versión 6 y lanzó directamente PHP 7 después de PHP 5. Pasar de MySQL 5.7 a 8 es simplemente pasar a la siguiente versión estable, sin saltar versiones.
En segundo lugar, el core de Drupal y los módulos que incluye son compatibles con MySQL 8 en todas las versiones soportadas desde aproximadamente cuatro años. Por versiones soportadas me refiero a Drupal 10 y 11. Comento el caso de Drupal 7 más abajo.
¡Perfecto! Entonces, ¿eso es todo? ¿Es la migración completamente segura? En realidad no; hay más cosas que considerar además del core.
El diablo está en los detalles
Aunque el core de Drupal es compatible con MySQL 8, es probable que un sitio utilice muchos módulos contribuidos. No se puede asumir que todos los módulos de Drupal disponibles sean compatibles, hay demasiados, más de 7.000 con una versión estable, y muchos más si tenemos en cuenta las versiones de desarrollo, alpha y beta.
Sin embargo, la mayoría de los módulos más usados, si no todos, son compatibles con cualquier versión de Drupal actualmente soportada. Actualmente, no hay issues de módulos que entren en conflicto con MySQL 8. También es poco probable que un módulo de uso generalizado no se haya utilizado ya en un servidor MySQL reciente. No hay de qué preocuparse aquí.
¿Qué hay del el código custom, del código personalizado? Hic sunt dracones, como los antiguos mapas medievales con ilustraciones de dragones que se utilizaban para indicar territorios peligrosos o inexplorados. Como el código personalizado es, bueno, personalizado, no es probado excepto por el propio proyecto que requirió su desarrollo. Cualquier proyecto con código personalizado es potencialmente incompatible con MySQL 8.
Por suerte, las probabilidades son muy bajas. Los principales problemas son palabras que MySQL antes permitía usar para nombres de tablas y otros objetos y que ahora están reservadas. Una de estas palabras es 'groups'. Como cabría de esperar, el módulo 'Groups' utiliza este nombre para una de sus tablas. Pero incluso en estos casos, el core lo corrige de forma automáticas, por lo que en circunstancias estándar, la migración es segura.
Otra posible fuente de problemas son los proyectos de larga duración creados hace tiempo. Esos proyectos pueden tener algunas configuraciones peculiares de MySQL y datos de tabla exóticos que pueden entrar en conflicto con MySQL 8. De nuevo, esto no es probable, pero es posible.
De acuerdo, lo más probable es que un proyecto Drupal sea compatbile con MySQL 8, pero ¿cómo se puede estar 100% seguro?
Red de seguridad
Lo que hace falta es una red seguridad para poder saltar sin caer al vacío.
¿Y cómo consigues tener esa red de seguridad? La idea es desplegar el proyecto en un entorno de desarrollo y comprobar que todo funciona correctamente. Esto se puede hacer de forma manual, pero no es recomendable. En Metadrop confíamos y dependemos completamente en las pruebas automáticas para asegurarnos de que los proyectos no se rompen inesperadamente. No solo comprobamos que los caso de uso de los usuarios se funcionan sin problemas, sino que también realizamos pruebas de regresión visual, accesibilidad o rendimiento. Si tu sitio no está cubierto por tests, deberías pensar en empezar a hacerlo ya mismo. Un sitio cubierto de tests es un sitio con red de seguridad. Es la diferencia está entre desplegar con miedo a que algo se rompa y desplegar rutinariamente con tranquilidad
Un entorno de desarrollo puede ser una máquina de desarrollo local de alguien de desarrollo, o un entorno remoto completo. Por lo general, se empieza probando en un entorno local, donde alguien de desarrollo puede revisar directamente cualquier posible error. Nosotros usamos Aljibe para nuestros entornos locales, una extensión de DDEV, el entorno de desarrollo local de facto oficial para Drupal (y otros CMS). Ofrece varios tipos de tests automáticos y, lo que es más importante, te permite cambiar la versión de la base de datos muy fácilmente, que es exactamente lo que necesitamos para probar un proyecto con MySQL 8.
Después, el proyecto normalmente se pasa a un sistema CI/CD que utilice MySQL 8 para las pruebas finales.
Acquia
Tomemos como ejemplo el upgrade que hará Acquia este mes de septiembre. Automáticamente desplegarán MySQL 8 en algún momento de este mes en sus entornos de desarrollo. Después, los clientes tendrán unas dos semanas para probarlo, lo cual es tiempo suficiente para detectar cualquier fallo importante.
El procedimiento sería:
- Copiar el entorno de producción a un entorno de pruebas. Si es posible, haciendo la menor sanitización de datos posible, ya que algunos problemas con MySQL 8 solo surgen con ciertos datos. Por razones de privacidad, esto se puede hacer automáticamente en un sistema CI/CD para evitar que nadie de desarrollo acceda a esos datos reales.
- Desplegar MySQL 8 en el entorno.
- Ejecutar los tests automáticos. (No me gusta repetirme, pero no puedo dejar de insistir que lo recomendable que es tener tests automáticos).
- Realizar cualquier comprobación manual, por ejemplo, permitir que el personal editorial pruebe a realizar sus tareas diarias en este entorno.
Una vez que no se detectan errores, el sitio está listo para la actualización. Solo hay que esperar a que Acquia despliegue la nueva versión de MySQL. El proceso es bastante rápido y no se espera ninguna interrupción del servicio. Sin embargo, la base de datos estará en modo de solo lectura durante parte del proceso, por lo que durante unos minutos no se podrán realizar ediciones. Para los visitantes, esto pasará probablemente desapercibido, ya que se les mostrará páginas en caché.
¿Qué pasa si el sitio no es compatible y no es posible solucionar todos los errores antes de que Acquia actualice MySQL este mes? Hay una opción: el módulo MySQL 5.7 and MariaDB 10.3 database driver. Añade una capa de compatibilidad, por lo que incluso si un sitio Drupal 10 u 11 tiene problemas con MySQL 8, aún puede usarlo gracias a este módulo. Ha sido desarrollado por Acquia y tiene muchas instalaciones, por lo que se puede estar bastante seguro de que funcionará correctamente.
¿Qué hay de otros proveedores?
Con Platform.sh, Pantheon, Amazee.io, o la plataforma en la nube de Amazon, AWS, que son los típicos proveedores de alojamiento para Drupal, se seguiría un procedimiento similar.
Platform.sh ofrece MySQL 8 desde hace tiempo. Si todavía estás usando MySQL 5.7, puedes seguir el mismo procedimiento con Acquia, excepto que puedes decidir cuándo se realiza la actualización. Esto se debe a que proporcionan mucha flexibilidad y control, permitiendo cambiar las versiones del software que usa el proyecto, como la versión de la base de datos. Hay que tener en cuenta que cuando MySQL 8 se ejecuta por primera vez, necesita ejecutar un proceso de conversión en los archivos de datos de MySQL 5.7 para convertirlos al formato de datos de MySQL 8. Esto puede ser lento si la base de datos es lo suficientemente grande.
El procedimiento sería (después de haberlo probado en tu entorno de desarrollo):
- Hacer una copia de seguridad de la base de datos.
- Desplegar MySQL 8.
- Comprobar que todo funciona correctamente.
Amazee.io y Pantheon están más orientados a PaaS, y es probable que ya hayan actualizado MySQL hace tiempo. Si el proyecto no fuese compatible con MySQL 8 probablemente ya se habría puesto de manifiesto.
Con AWS puede ser ambas opciones, desde de un enfoque PaaS, probablemente usando una base de datos Aurora compatible con MySQL, a controlar completamente todas las versiones de software que se utilizan. En el primer caso, asumiendo que se puede seleccionar cuándo usar MySQL 8 o un Aurora compatible, el enfoque es similar al anterior. En el segundo caso, probablemente ya se dispone de un equipo dedicado para manejar la infraestructura, y seguramente ya tienen claro cómo gestionar la migración, si es que no lo han hecho ya.
Drupal 7
El fin del soporte de Drupal 7 se fue este enero, hace nueve meses. Aún así, hay muchos proyectos que todavía funcionan con Drupal 7, y es por eso que aún ofrecemos servicios de migración de Drupal 7 a Drupal 11.
El core de Drupal 7 es también compatible con MySQL 8, pero los módulos pueden no serlo. Algunos mantenedores de módulos pueden haber decidido que el esfuerzo no valía la pena y no han trabajado en esa compatibilidad. Además, los módulos personalizados son más propensos a errores, simplemente porque pasan por menos comprobaciones y pruebas.
Por todo esto, con Drupal 7 es muy importante probar a fondo el sitio. Ejecuta pruebas, edita contenido, ejecuta cualquier pesado y estrésalo tanto como puedas. Porque si todavía estás usando Drupal 7, es probable que sea porque el proyecto es antiguo, grande, complejo y requiere muchos recursos para migrar. Es este tipo de escenarios donde es más probable encontrar problemas con MySQL 8.
En resumen
Drupal es compatible con MySQL 8 desde hace tiempo. Sin embargo, el código custom y ciertas circunstancias peculiares pueden causar problemas. Para asegurarse, hay desplegar y probar el sitio con datos reales en un entorno de desarrollo. Los datos reales son importantes porque algunos problemas están relacionados con la forma en que MySQL almacena los datos. Si usas datos de prueba o datos muy sanitizados, puedes pasar por alto el problema.
Es muy poco probable que tu sitio no sea compatible, pero es mejor invertir algo de tiempo y estar seguro que tener una desagradable sorpresa en producción.
Quiero los sucios detalles técnicos
Este artículo intenta evitar los detalles técnicos, pero si insistes, permíteme que dé algunos.
MySQL 8 tiene funcionalidades nuevas y remozadas como el optimizador de consultas, la parte que decide la forma más eficiente de ejecutar una consulta. Si bien se espera que tenga un mejor criterio, es posible que en ciertas situaciones pueda llevar a un rendimiento más lento. Es por ello que es importante comprobar el rendimiento.
Otro cambio es la variable tx_isolation. Ha sido eliminada y reemplazada por transaction_isolation. Hay más detalles en la página Setting the MySQL transaction isolation level de la documentación oficial de Drupal. El resumen es que si se está usando la variable tx_isolation, basta con cambiarla por transaction_isolation. Es realmente la misma variable, solo que con un nombre diferente.
Además, como se ha dicho antes, algunas palabras ahora están reservadas: groups, grouping, cube, o empty, por ejemplo. Si alguna de las tablas u objetos en la base de datos usan estas palabras como nombres, hay que que asegurarse de que se usen comillas al hacer referencia a ellas. De lo contrario, el motor de la base de datos las tomará como parte de la sentencia y fallará. Hasta donde yo sé, las comillas las añade el core de Drupal, así que si usas la API de Base de Datos —y esto es casi siempre el caso—, de nuevo, el proyecto está cubierto.
Otro cambio está relacionado con los conjuntos de caracteres y la collation. En MySQL, la implementación utf8 significaba utf8mb3, que no admite todos los caracteres Unicode. Específicamente, los emojis no están incluidos porque usan 4 bytes, pero utf8mb3 solo usa 3. Esto no debería ser un problema, es bueno saber que con MySQL 8 un sitio puede estar plagado de emojis por todas partes, si eso es lo que quieres. No te juzgaré. No demasiado, al menos.
Para más detalles técnico se puede profundizar en la issue de MySQL 8, donde se coordinó la compatibilidad con MySQL 8 y Drupal.
La actualización a MySQL 8 debería ser fácil y sin problemas. El proceso general y las aristas principales se tratan de cubrir en este artículo, pero si todavía tienes dudas o necesitas ayuda con esta actualización no dudes en ponerte en contacto con nosotros
