Bug MySQL 8.0.38 en cPanel: qué hacer ahora

Un bug en MySQL 8.0.38 desencadenó actualizaciones automáticas en servidores cPanel que dejaron bases de datos offline sin previo aviso. La versión fue retirada por Oracle el 1 de julio de 2024 después de confirmarse que impedía el reinicio del servicio en instancias con más de 8.000 tablas, pero muchos servidores ya la habían recibido antes de la intervención.

Qué es el bug de actualización automática de MySQL en cPanel

cPanel es el panel de administración de hosting más usado en servidores compartidos y VPS de toda Latinoamérica. Entre sus funciones incluye la gestión del motor de base de datos (MySQL o MariaDB), y aplica parches de seguridad y actualizaciones menores de forma automática sin requerir intervención del administrador.

El problema apareció con MySQL 8.0.38: según las notas de release de Oracle, esta versión introdujo un bug que impide que el servicio MySQL se reinicie correctamente cuando la instancia contiene más de 8.001 tablas. En muchos entornos de producción con años de datos acumulados, eso no es un caso extremo. Muchos servidores de hosting con múltiples sitios activos superan ese umbral fácilmente.

Lo que terminó pasando: cPanel descargó e instaló 8.0.38, reinició el servicio de base de datos como parte del proceso estándar, y el servicio no volvió a levantarse. Sin MySQL operativo, todos los sitios del servidor cayeron al mismo tiempo.

Síntomas: Cómo saber si tu servidor fue afectado

Ponele que abrís WordPress a la mañana y en vez del sitio aparece “Error establishing a database connection”. El primer instinto es pensar que rompiste algo la noche anterior. Pero si no tocaste nada, probablemente fue el upgrade nocturno.

Los síntomas más comunes de este problema:

• WordPress muestra “Error establishing a database connection” en todos los sitios del servidor.
• phpMyAdmin no carga o devuelve error de conexión.
• En WHM, el servicio MySQL aparece como “offline” o “failed”.
• Los logs de aplicación muestran “Can’t connect to MySQL server” o “Access denied for user”.
• El problema aparece de repente, sin cambios previos de tu parte, típicamente entre las 2 y las 6 de la mañana (horario habitual de los cron de mantenimiento de cPanel).

¿Y cómo confirmás que el culpable es el upgrade? Revisás la versión instalada. Si dice 8.0.38, ya sabés lo que pasó.

Por qué ocurren estos problemas de actualización

Hay tres causas que se repiten en los casos reportados.

La primera es la más obvia: bugs en la versión nueva. MySQL 8.0.38 es el ejemplo exacto. Oracle publica una versión, cPanel la incorpora a su sistema de actualización automática, y antes de que los reportes de error lleguen en cantidad suficiente para detener la distribución, miles de servidores ya la instalaron.

La segunda causa es la incompatibilidad entre versiones de motor. Algunos proveedores de hosting corren MariaDB en vez de MySQL (son motores distintos aunque compatibles en gran parte de la sintaxis), y un upgrade de MariaDB 10.2.x a 10.3.x puede cambiar comportamientos internos que ciertos plugins de WordPress no esperan. La documentación oficial de cPanel advierte explícitamente sobre esto, pero no todo el mundo la lee antes de que el servidor se caiga.

La tercera: cambios en el plugin de autenticación. MySQL 8.0 cambió el método de autenticación por defecto de `mysql_native_password` a `caching_sha2_password`. Eso rompe conexiones de código antiguo que no soporta el nuevo método (spoiler: muchos plugins de WordPress de hace 5 años o más entran en esa categoría).

Versiones afectadas: MySQL 8.0.38 y casos conocidos

MySQL 8.0.38 fue retirada por Oracle el 1 de julio de 2024 después de confirmar el bug de reinicio. El parche llegó con 8.0.39, publicada poco después. Si en tu servidor figura 8.0.38 y nunca hiciste nada al respecto, es posible que hayas tenido un período de inestabilidad sin darte cuenta si la BD no necesitó reiniciarse en ese intervalo.

Las versiones 8.4.1 y 9.0.0 también presentaron problemas en sus lanzamientos iniciales, según reportes de Percona, que directamente recomendó no actualizar a ninguna versión posterior a 8.0.37 hasta nuevo aviso en ese período. Percona es uno de los referentes más serios en administración de MySQL en producción, así que esa advertencia no es menor.

Un caso adicional que circuló en foros de administración: MariaDB 10.2.35 y 10.3.26 en algunos entornos cPanel mostraban MySQL como offline en WHM incluso cuando el servicio estaba corriendo. Un problema de detección del estado del servicio que generaba pánico innecesario pero también dificultaba el diagnóstico real.

Soluciones: Cómo reparar la base de datos y restaurar el servicio

El procedimiento varía según qué tan grave quedó la situación.

Si MySQL no inicia en absoluto

Primero, entrá a WHM y verificá la versión instalada en “SQL Services > MySQL/MariaDB Upgrade”. Si figura 8.0.38, intentá actualizar directamente a 8.0.39 o superior desde esa misma pantalla. cPanel debería permitirte hacer el upgrade sin necesidad de que el servicio esté activo. Sobre eso hablamos en nuestra guía de solución de problemas de hosting.

Si el upgrade desde WHM falla, conectate por SSH y revisá el log de errores de MySQL:

• Ubicación habitual: /var/log/mysql/error.log o /var/lib/mysql/hostname.err
• Buscá mensajes que mencionen “InnoDB”, “table space”, o “Can’t start server”
• Si ves “Table ‘mysql.user’ doesn’t exist”, el problema es más grave y necesitás restaurar desde backup

Si MySQL inicia pero algunos sitios siguen caídos

Puede haber tablas corruptas del proceso de upgrade interrumpido. Desde phpMyAdmin, seleccioná la base de datos afectada y ejecutá “Reparar tabla” sobre las tablas que muestran error. Alternativamente, desde línea de comandos: mysqlcheck -u root -p --auto-repair --all-databases.

¿Alguien verificó que esto alcanza siempre? No, no alcanza. Si la corrupción llegó al nivel de InnoDB, vas a necesitar el backup.

Si nada funciona: restaurar backup

En cPanel, desde “Backup Wizard” o “Jetbackup” si el proveedor lo tiene habilitado, restaurá el snapshot anterior al upgrade. La mayoría de los hosts tienen backups diarios automáticos. El flujo de recuperación para WordPress es siempre: restaurar BD, verificar que wp-config.php tenga las credenciales correctas, limpiar caché.

Prevención: Evitar problemas futuros de actualización

Seis cosas concretas que podés hacer para que esto no te vuelva a pasar:

• Backups automáticos antes de cada parche: configurá un snapshot de la BD cada vez que cPanel aplica actualizaciones. Algunos proveedores ofrecen esto como opción en WHM.
• Pausar actualizaciones automáticas de MySQL: en /etc/yum.conf podés excluir paquetes de MySQL de las actualizaciones automáticas. El riesgo es quedarte sin parches de seguridad, así que hacé actualizaciones manuales revisadas.
• Monitorear los logs nocturnos: si tenés un sistema de alertas (Nagios, Zabbix, o algo más simple como UptimeRobot), configuralo para notificarte si MySQL cae. No te enteres porque un cliente llama a las 9 de la mañana.
• Usar staging para validar upgrades: si administrás varios servidores, aplicá el upgrade en el de menor tráfico primero y esperá 24 horas antes de propagarlo.
• Ventanas de mantenimiento en horario bajo: si podés controlar cuándo se aplican los upgrades, elegí un horario con poco tráfico y con alguien disponible para intervenir si algo falla.
• Mantener compatibilidad WordPress + MySQL: WordPress requiere MySQL 8.0 o MariaDB 10.4 como mínimo en versiones recientes. Antes de un upgrade de motor, verificá que todos tus plugins estén actualizados también.

Si usás hosting en donweb.com, podés consultar directamente con soporte qué política de upgrades aplican y si ofrecen notificación previa o ventanas de mantenimiento configurables.

Impacto en WordPress y plugins: Incompatibilidades comunes

El cambio de autenticación de MySQL 8.0 es el que más rompe cosas en WordPress. El método `caching_sha2_password` que MySQL 8.0 usa por defecto requiere que el cliente MySQL soporte cifrado SHA-256. Muchas versiones antiguas de PHP y del cliente MySQL de WordPress no lo hacían.

El resultado práctico: el upgrade funciona, MySQL levanta bien, pero WordPress no puede conectarse porque el usuario de la BD sigue configurado con el método viejo. La solución técnica es ejecutar en MySQL: ALTER USER 'usuario'@'localhost' IDENTIFIED WITH mysql_native_password BY 'contraseña';

Los plugins más propensos a romperse son los que incluyen su propia librería de conexión a base de datos (algunos plugins de backup, de ecommerce custom, o de migración). Los plugins que usan la API estándar de WordPress no tienen este problema porque WordPress maneja la conexión.

Código personalizado o themes con queries directas a MySQL son otro punto de falla. Si alguien escribió queries con sintaxis de MySQL 5.7 o funciones deprecadas en 8.0, el upgrade las va a romper (que no es poco si ese código lleva años sin mantenimiento).

Matriz de compatibilidad: MySQL, MariaDB y WordPress

Un dato que vale remarcar: no podés hacer downgrade de MySQL a una versión anterior una vez que los datos fueron procesados por una versión más nueva. Si instalaste 8.0.38 y querés volver a 8.0.37, necesitás restaurar un backup previo. MySQL y MariaDB tampoco son intercambiables en un upgrade directo: no existe un camino de “migrar de MySQL 8.0 a MariaDB 10.6” sin exportar e importar los datos manualmente.

Qué está confirmado / Qué no

Errores comunes al intentar resolverlo

Error 1: Reiniciar MySQL desde cPanel sin revisar los logs primero. Si MySQL no inicia por el bug de 8.0.38, reiniciarlo repetidas veces no cambia nada. El servicio no va a levantar hasta que actualicés la versión o restaures el backup. Cada intento de reinicio solo agrega entradas de error al log y consume tiempo. Lo explicamos a fondo en una auditoría de seguridad completa tras el problema.

Error 2: Creer que el problema es de WordPress y reinstalar el core. Cualquiera que haya visto “Error establishing a database connection” sabe que el reflejo inmediato es tocar el wp-config.php o reinstalar WordPress. Pero si MySQL está caído, el problema no está en WordPress. Confirmá primero que el servicio de base de datos está corriendo antes de tocar cualquier archivo.

Error 3: Intentar hacer downgrade de MySQL directamente. No existe un proceso de downgrade seguro en MySQL. Si instalaste 8.0.38, la única salida limpia es actualizar a 8.0.39+. Si querés volver a 8.0.37, necesitás el backup de antes del upgrade. Intentar un downgrade forzado puede dejar los datos en un estado inconsistente.

Preguntas Frecuentes

¿Qué pasa si falla la actualización automática de MySQL en cPanel?

Si el upgrade falla a mitad de proceso, MySQL puede quedar en un estado inconsistente y no iniciar. El servicio aparece como “offline” en WHM y todos los sitios del servidor pierden acceso a la base de datos. La recuperación depende de si el proceso de upgrade dejó los datos intactos: si sí, actualizar a la versión siguiente desde WHM suele resolver el problema; si los datos se corrompieron, necesitás restaurar desde backup.

¿Cómo reparo el error de conexión a la base de datos en WordPress después de actualizar MySQL?

Primero verificá que el servicio MySQL esté corriendo desde WHM. Si está online, el problema suele ser el método de autenticación: MySQL 8.0 usa `caching_sha2_password` por defecto, que algunos clientes antiguos no soportan. La solución es modificar el usuario de la BD para que use `mysql_native_password` ejecutando el comando ALTER USER en MySQL, o actualizar el cliente MySQL de PHP en el servidor.

¿Se pueden desactivar las actualizaciones automáticas de MySQL en cPanel?

Sí, pero con restricciones. En servidores con acceso root, podés modificar `/etc/yum.conf` para excluir paquetes de MySQL de las actualizaciones automáticas. Algunos proveedores de hosting compartido no dan acceso a esa configuración. La alternativa es contactar al soporte del proveedor para solicitar control sobre las ventanas de mantenimiento.

¿Qué versión de MySQL es compatible con WordPress y mis plugins?

WordPress 6.5 (versión actual en 2026) requiere MySQL 8.0 o MariaDB 10.4 como mínimo. La versión recomendada es MySQL 8.0.39 o superior (que corrige el bug de 8.0.38), o MariaDB 10.6+. Los plugins con código anterior a 2020 pueden tener incompatibilidades con el método de autenticación de MySQL 8.0 y requerir ajustes adicionales.

¿Cómo restaurar una base de datos si se rompió con la actualización?

Desde WHM, accedé a “Backup Wizard” y buscá el snapshot anterior a la fecha del upgrade (generalmente el día anterior). Si el proveedor usa JetBackup, el proceso es similar desde el panel de backups. Restaurá solo la base de datos, no los archivos, salvo que los archivos también estén comprometidos. Después verificá que wp-config.php tenga las credenciales correctas y limpiá el caché de WordPress.

Conclusión

El caso de MySQL 8.0.38 ilustra un problema estructural: las actualizaciones automáticas son cómodas hasta que no lo son. cPanel toma decisiones de upgrade en nombre del administrador del servidor, y cuando Oracle publica una versión con un bug crítico, el daño puede estar hecho antes de que llegue el aviso de retiro.

Lo concreto: si encontrás MySQL 8.0.38 en tu servidor, actualizá a 8.0.39 o superior desde WHM cuanto antes. Si ya tenés el servicio caído, revisá los logs antes de cualquier otra acción. Y si no tenés backups automáticos configurados, ese es el problema que necesitás resolver hoy, no mañana.

Fuentes

• Oracle – Release Notes MySQL 8.0.38 (versión retirada)
• Percona Blog – Advertencia sobre upgrades de MySQL post 8.0.37
• cPanel Docs – MySQL/MariaDB Upgrade en WHM
• Raiolanetworks – Error de conexión a base de datos en WordPress