Migrar MySQL 8.0 a 8.4 LTS en un VPS: guía paso a paso

Por qué migrar ahora: fin de vida y exposición a CVE

Cambios incompatibles que debes conocer antes de la migración

• mysql_native_password eliminado: el plugin de autenticación mysql_native_password ha sido eliminado definitivamente en MySQL 8.4 (solo estaba deprecado en 8.0). Cualquier cuenta de usuario que dependa de este plugin fallará al conectarse de inmediato tras la actualización. Aplicaciones PHP anteriores a PHP 8.1, WordPress sin PDO configurado correctamente y clientes JDBC heredados son los casos más habituales.
• Cambio del parámetro authentication_policy: el valor por defecto pasa a caching_sha2_password, y cualquier línea default_authentication_plugin en my.cnf es ignorada con una advertencia. Debe reemplazarse por authentication_policy.
• Eliminación de innodb_file_format: la variable innodb_file_format se ha eliminado. Las tablas creadas con ROW_FORMAT=COMPRESSED siguen funcionando, pero cualquier intento de establecer innodb_file_format en tiempo de ejecución produce un error.
• Cambios en el tipo JSON: MySQL 8.4 refuerza la conformidad JSON/SQL. Funciones como JSON_TABLE() y JSON_VALUE() pueden comportarse de manera diferente. Valida las tablas con columnas JSON grandes en un entorno de prueba antes de pasar a producción.
• Juego de caracteres y cotejamiento: utf8mb4 y utf8mb4_0900_ai_ci siguen siendo los valores por defecto, pero MySQL 8.4 rechaza con más rigor las columnas declaradas como utf8 (alias de utf8mb3). Puede ser necesaria una migración de cotejamiento para bases de datos históricas creadas bajo MySQL 5.7.
• Variables de sistema eliminadas o renombradas: varias variables presentes en 8.0 y marcadas como deprecadas han sido eliminadas en 8.4 — especialmente innodb_undo_tablespaces, slave_* (reemplazadas por replica_* ) y query_cache_*.
• Replicación: los nombres de variables relacionadas con la replicación han pasado definitivamente a la terminología source/replica. Cualquier script o herramienta de monitoreo que llame a SHOW SLAVE STATUS debe actualizarse a SHOW REPLICA STATUS.

Requisitos previos antes de comenzar

• Copia de seguridad completa y verificada: ejecuta mysqldump --all-databases --single-transaction --routines --events > backup_pre_migration.sql y verifica que el archivo sea legible. Una copia de seguridad no verificada no es una copia de seguridad.
• Versión actual y motores de tablas: ejecuta SELECT VERSION(); y lista las tablas no InnoDB desde information_schema.tables. Cualquier tabla MyISAM o MEMORY debe evaluarse antes de la actualización.
• Compatibilidad de la aplicación: identifica el plugin de autenticación de cada cuenta con SELECT user, host, plugin FROM mysql.user;. Cualquier usuario en mysql_native_password debe migrarse a caching_sha2_password.
• Espacio en disco disponible: una actualización in-place puede duplicar temporalmente el espacio ocupado por los archivos ibdata. Verifica que haya al menos un 20% de espacio libre en la partición /var.

Procedimiento de migración MySQL 8.0 → 8.4 LTS en un VPS

1. 01

   Copia de seguridad completa con verificación

   Ejecuta mysqldump --all-databases --single-transaction --routines --events --triggers > /root/backup_mysql80_$(date +%Y%m%d).sql. Verifica el final del archivo con tail -5 /root/backup_mysql80_*.sql: la última línea debe ser -- Dump completed on …. Almacena el archivo fuera del VPS antes de continuar.

2. 02

   Auditoría de cuentas y plugins de autenticación

   Ejecuta SELECT user, host, plugin FROM mysql.user ORDER BY plugin;. Para cada usuario en mysql_native_password, ejecuta ALTER USER 'nombre'@'host' IDENTIFIED WITH caching_sha2_password BY 'contraseña';. Actualiza la cadena de conexión de cada aplicación afectada antes de la actualización.

3. 03

   Verificación de variables deprecadas en my.cnf

   Abre /etc/mysql/mysql.conf.d/mysqld.cnf y elimina o reemplaza: default_authentication_plugin → authentication_policy = caching_sha2_password, slave_* → replica_*, innodb_undo_tablespaces, query_cache_size, query_cache_type. Cualquier variable desconocida impide que MySQL 8.4 arranque.

4. 04

   Parada limpia del servicio y snapshot

   En un VPS Proxmox o KVM, toma un snapshot antes de tocar los paquetes. Luego: systemctl stop mysql y verifica que el servicio está detenido con systemctl status mysql.

5. 05

   Añadir el repositorio MySQL 8.4 y actualizar paquetes

   En Debian 12 / Ubuntu 22.04: descarga el paquete de configuración del repositorio MySQL desde dev.mysql.com/downloads/repo/apt/, instálalo con dpkg -i mysql-apt-config_*.deb, selecciona MySQL 8.4 LTS en el menú, luego ejecuta apt-get update && apt-get install mysql-server.

6. 06

   Actualización de tablas del sistema

   En el primer arranque de MySQL 8.4, el motor actualiza las tablas del sistema automáticamente. Verifica en los logs: journalctl -u mysql -n 50 | grep -i 'upgrade\|error'. Si la actualización automática no se ejecutó, lanza manualmente mysql_upgrade --user=root --password.

7. 07

   Verificación post-actualización

   Conéctate y verifica la versión: SELECT VERSION(); debe devolver 8.4.x. Luego ejecuta mysqlcheck --all-databases --auto-repair --user=root --password. Revisa el log de errores /var/log/mysql/error.log.

8. 08

   Test funcional de la aplicación

   Reinicia tu aplicación y verifica los puntos sensibles: conexión a la base de datos, autenticación de usuarios, consultas en columnas JSON, procedimientos almacenados. El error The server requested authentication method unknown to the client indica una cuenta aún en mysql_native_password no migrada.

9. 09

   Limpieza y activación de la monitorización

   Elimina el archivo de copia de seguridad local una vez confirmada la copia externa. Verifica tu herramienta de monitorización: algunos nombres de métricas cambiaron entre 8.0 y 8.4. Programa una revisión del log de errores MySQL a las 24h y 72h post-migración.

MariaDB 11.x: cuándo preferir esta alternativa

MySQL 8.0 vs MySQL 8.4 LTS vs MariaDB 11.x

Desplace la tabla

Resolución de problemas: errores comunes tras la migración

• ERROR 1045 (28000): Access denied tras la actualización: verifica el plugin de autenticación de la cuenta con SELECT plugin FROM mysql.user WHERE user='nombre';. Si sigue siendo mysql_native_password, ejecuta ALTER USER … IDENTIFIED WITH caching_sha2_password BY '…';.
• Unknown system variable 'default_authentication_plugin': esta variable ya no se reconoce en 8.4. Retírala de my.cnf y reemplázala por authentication_policy = caching_sha2_password.
• MySQL no arranca tras la actualización: consulta /var/log/mysql/error.log. El error más frecuente es una variable de sistema desconocida en my.cnf. Comenta las variables una a una hasta identificar el origen.
• Rendimiento degradado en consultas de ordenación: MySQL 8.4 aplica el orden de los índices con más rigor. Ejecuta EXPLAIN en las consultas lentas y verifica que los índices cubrientes siguen utilizándose. ANALYZE TABLE nombre_tabla; fuerza la actualización de estadísticas.
• Tabla performance_schema.replication_applier_status no encontrada: algunas tablas de performance_schema fueron renombradas. Actualiza las consultas de monitorización usando los nuevos nombres documentados en dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

Pasar a MySQL 8.4 LTS: lo esencial