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 desactivado: el plugin de autenticación mysql_native_password, deprecado desde MySQL 8.0.34, ya no se carga por defecto en MySQL 8.4 (se elimina en 9.0). Puede reactivarse temporalmente con mysql_native_password=ON en la sección [mysqld] mientras se migran las cuentas. Cualquier cuenta de usuario que dependa de este plugin fallará al conectarse de inmediato tras la actualización. Aplicaciones PHP anteriores a PHP 7.4, WordPress sin PDO configurado correctamente y clientes JDBC heredados son los casos más habituales.
• Cambio del parámetro authentication_policy: la variable default_authentication_plugin, deprecada desde 8.0.27, se elimina en 8.4: una línea que quede en my.cnf impide que el servidor arranque. authentication_policy la sustituye; su valor por defecto (*,,) ya usa caching_sha2_password para el primer factor. Debe reemplazarse por authentication_policy.
• Opciones de servidor eliminadas: expire_logs_days (sustituida por binlog_expire_logs_seconds), --skip-host-cache (sustituida por host_cache_size = 0), --ssl y --admin-ssl (sustituidas por --tls-version y --admin-tls-version), binlog_transaction_dependency_tracking, avoid_temporal_upgrade y show_old_temporals ya no existen en 8.4: definirlas, en tiempo de ejecución o en my.cnf, produce un error.
• Columnas JSON: como en toda actualización de versión mayor, las consultas que dependen de JSON_TABLE(), JSON_VALUE() o de rutas JSON complejas deben repetirse antes del cambio. 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, y el juego utf8mb3 (del que utf8 es el alias) está deprecado: sigue aceptado durante toda la serie 8.4, pero Oracle anuncia su eliminación en una futura versión mayor. Conviene planificar una migración a utf8mb4 para bases de datos históricas creadas bajo MySQL 5.7.
• Variables de sistema eliminadas o renombradas: varias opciones de replicación deprecadas en 8.0 se eliminan en 8.4 — especialmente master_info_repository y relay_log_info_repository (solo quedan las tablas de metadatos, resistentes a fallos), slave_rows_search_algorithms y log_bin_use_v1_events; las variables slave_* restantes están deprecadas en favor de replica_*, y las variables query_cache_* desaparecieron ya en 8.0 con la caché de consultas. El Upgrade Checker de MySQL Shell (util.checkForServerUpgrade()) señala estos puntos antes del cambio.
• Replicación: los nombres de variables relacionadas con la replicación han pasado definitivamente a la terminología source/replica. Las instrucciones antiguas se eliminan en 8.4: cualquier script o herramienta de monitoreo que llame a SHOW SLAVE STATUS debe actualizarse a SHOW REPLICA STATUS, igual que START SLAVE → START REPLICA, CHANGE MASTER TO → CHANGE REPLICATION SOURCE TO y SHOW MASTER STATUS → SHOW BINARY LOG 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: el dump de copia de seguridad y la actualización del diccionario de datos ocupan espacio en el disco del servidor. 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, expire_logs_days → binlog_expire_logs_seconds, skip-host-cache → host_cache_size = 0, slave_* → replica_*, master_info_repository, relay_log_info_repository. 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ó, no busques mysql_upgrade: la herramienta se eliminó en 8.4. Reinicia el servidor una vez con la opción --upgrade=FORCE (por ejemplo upgrade = FORCE en la sección [mysqld], que se retira después).

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. Una cuenta que sigue en mysql_native_password sin migrar falla con ERROR 1045 (28000): Access denied y deja una traza en el log del servidor; el error The server requested authentication method unknown to the client indica en cambio un cliente demasiado antiguo para caching_sha2_password (PHP anterior a 7.4, por ejemplo).

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, la cuenta no se migró (la actualización no cambia el plugin de ninguna cuenta): 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: el optimizador de MySQL 8.4 puede elegir planes de ejecución distintos de los de la 8.0 en algunas consultas. 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.
• Scripts de monitorización con errores tras la actualización: los contadores Com_slave_* y Com_show_master_status se eliminan en 8.4 en favor de Com_replica_* y Com_show_binary_log_status, y las instrucciones SLAVE/MASTER ya no existen. Actualiza las consultas de monitorización usando los nombres documentados en dev.mysql.com/doc/refman/8.4/en/performance-schema.html.

Pasar a MySQL 8.4 LTS: lo esencial