Error 'Failed to connect to MySQL' en PrestaShop | Solución Plesk

¿Tu tienda PrestaShop ha dejado de funcionar de repente y te aparece el temido mensaje "Failed to connect to MySQL"? No te preocupes, no eres el primero al que le pasa y, sobre todo, tiene solución. Este error es uno de los más comunes en el mundo del hosting, especialmente cuando trabajamos con Plesk como panel de control.

En esta guía extensa y pensada para principiantes, vamos a desglosar paso a paso todas las causas posibles y las soluciones para que tu tienda vuelva a estar operativa en cuestión de minutos. Vamos a ello.

Entendiendo el error: ¿Qué significa exactamente?

Antes de ponernos manos a la obra, es fundamental entender qué está pasando. El mensaje "Failed to connect to MySQL" es la forma que tiene PrestaShop de decirte: "He intentado hablar con la base de datos donde guardo todos los productos, clientes y pedidos, pero no he podido establecer la conexión".

Imagina que tu tienda es una biblioteca (PrestaShop) y la base de datos es el almacén secreto donde están todos los libros (tu información). Si la puerta del almacén está cerrada con un candado equivocado, o el almacén está en llamas, la biblioteca no puede mostrarte ningún libro. En términos técnicos, esto puede deberse a tres grandes grupos de problemas:

El servidor MySQL no está funcionando (el almacén está cerrado).
Las credenciales de acceso son incorrectas (el candado no coincide).
Hay un bloqueo de red o de seguridad (la carretera hacia el almacén está cortada).

Vamos a diagnosticar y solucionar cada uno de estos escenarios dentro del entorno Plesk.

Paso 1: Verificar que el servicio MySQL/MariaDB está activo

El primer paso, y el más sencillo, es comprobar que el motor de base de datos está corriendo. A veces, tras una actualización del sistema o un reinicio del servidor, el servicio no se levanta correctamente.

Acceso por SSH (Línea de comandos)

Si tienes acceso SSH a tu servidor, este es el método más directo.

Conéctate a tu servidor por SSH.
Ejecuta el siguiente comando para comprobar el estado del servicio (dependiendo de si tu servidor usa systemd o sysvinit):
```
# Para sistemas con systemd (CentOS 7+, Ubuntu 16.04+)
systemctl status mysql
# o si usas MariaDB
systemctl status mariadb
```
Si el estado es inactive (dead) o failed, tendrás que arrancarlo:
```
systemctl start mysql
# o
systemctl start mariadb
```
Para asegurarte de que se inicie automáticamente en cada reinicio:
```
systemctl enable mysql
```

Acceso desde Plesk (Interfaz gráfica)

Plesk también te ofrece una forma visual de comprobar esto, aunque es menos directa.

Entra en tu panel de Plesk.
Ve a Herramientas y configuración en el menú de la izquierda.
Busca la sección General y haz clic en Gestor de servicios (o "Services Management").
Busca la entrada de MySQL o MariaDB. Verás un semáforo. Si está en rojo o amarillo, el servicio está caído o reiniciándose.
Haz clic en el icono de "play" o "reiniciar" para intentar levantarlo de nuevo.

[INFO] Si el servicio no arranca y te da un error, anota el mensaje exacto. Suele indicar un problema de corrupción en las tablas o falta de espacio en disco. Si es falta de espacio, tendrás que liberar archivos temporales o logs antiguos en /var/log/.

Paso 2: Comprobar las credenciales de la base de datos en PrestaShop

Si el servicio MySQL está activo, el siguiente sospechoso habitual es que la configuración de conexión en PrestaShop no coincide con la realidad. Plesk gestiona las bases de datos de forma muy específica, y es fácil equivocarse al copiar un usuario o contraseña.

Localizar el archivo de configuración `parameters.php`

PrestaShop guarda la configuración de la base de datos en un archivo llamado parameters.php. La ruta típica es:

/var/www/vhosts/tu-dominio.com/httpdocs/app/config/parameters.php

[WARNING] Ten mucho cuidado al editar este archivo. Un error de sintaxis (una coma o una comilla mal puesta) puede tumbar tu tienda por completo. Siempre haz una copia de seguridad antes de editarlo.

Accede por FTP o SSH a tu servidor.
Navega a la carpeta app/config/ dentro de la raíz de tu PrestaShop.
Abre parameters.php con un editor de texto plano (nunca con Word o similar).
Busca las líneas que empiezan por 'database_host', 'database_name', 'database_user' y 'database_password'.

Verificar los datos en Plesk

Ahora, vamos a comprobar si esos datos son correctos.

Ve a tu panel de Plesk.
En el menú de la izquierda, busca tu dominio y haz clic en Bases de datos (o "Databases").
Verás una lista de bases de datos asociadas a tu dominio. Haz clic en el nombre de la que usa tu PrestaShop.
En la página de la base de datos, verás el nombre de la base de datos y el nombre de usuario asociado.
Compara estos datos con los que tienes en parameters.php. Deben ser exactamente iguales, incluyendo el prefijo que añade Plesk (a menudo algo como tu_usuario_).

[TIP] Si has olvidado la contraseña, en la misma pantalla de Plesk tienes la opción de "Cambiar contraseña". Genérala una nueva y actualízala en el parameters.php. Asegúrate de usar una contraseña segura, pero que puedas copiar sin errores.

El error típico de `database_prefix`

A veces el error no es de credenciales, sino de prefijo de tablas. PrestaShop usa un prefijo (normalmente ps_) para sus tablas. Si tu parameters.php tiene un prefijo distinto al que realmente tienen las tablas en la base de datos, el error aparecerá. Puedes verificar el prefijo real conectándote a la base de datos por phpMyAdmin desde Plesk.

Paso 3: Comprobar la conexión remota y el host de la base de datos

En instalaciones estándar de Plesk, la base de datos y el sitio web están en el mismo servidor. Por lo tanto, el database_host debería ser localhost o 127.0.0.1.

Sin embargo, hay ocasiones en las que la base de datos está en un servidor separado (una arquitectura más avanzada). Si ese es tu caso, el problema puede ser que el servidor MySQL no acepta conexiones remotas.

Verificar el host en `parameters.php`

Revisa el valor de 'database_host' en tu archivo parameters.php.
Si es localhost, pero tu base de datos está en otro servidor (te lo diría tu proveedor de hosting), tendrás que cambiar este valor por la IP del servidor de bases de datos.

Configurar MySQL para conexiones remotas (Solo si es necesario)

Si realmente necesitas conexión remota, tendrás que editar la configuración de MySQL en el servidor de bases de datos (a través de Plesk o SSH).

Edita el archivo de configuración de MySQL, normalmente en /etc/my.cnf o /etc/mysql/my.cnf.
Busca la línea que dice bind-address o skip-networking.
Si skip-networking está activo, coméntalo con #.
Si bind-address es 127.0.0.1, cámbialo a 0.0.0.0 para que escuche en todas las interfaces, o a la IP específica del servidor web.

[WARNING] Abrir MySQL a conexiones remotas es un riesgo de seguridad enorme. Asegúrate de que tu firewall solo permita el acceso desde la IP de tu servidor web. No lo hagas si no estás seguro de lo que estás haciendo.

Paso 4: Revisar el firewall y los permisos de red

Otra causa común del error MySQL PrestaShop es que el firewall del sistema (como firewalld o iptables) esté bloqueando el puerto 3306 (el puerto por defecto de MySQL).

Comprobar el firewall en Plesk

Ve a Herramientas y configuración en Plesk.
Busca la sección Seguridad y haz clic en Firewall.
Asegúrate de que hay una regla que permita el tráfico entrante al puerto 3306 desde tu IP o desde el servidor web.
Si no está, añádela. Especifica el puerto, el protocolo TCP y la fuente (puede ser "Cualquier lugar" si es un servidor dedicado, pero es más seguro limitarlo).

[INFO] Si estás en un hosting compartido, es muy probable que no tengas acceso al firewall del servidor. En ese caso, este paso no aplica para ti y deberás contactar con el soporte del hosting.

Paso 5: Reparar tablas corruptas de la base de datos

Si el error persiste, puede que las tablas de tu base de datos estén corruptas. Esto suele pasar tras un corte de luz o un fallo del disco duro.

Usando phpMyAdmin desde Plesk

Ve a tu base de datos en Plesk y haz clic en phpMyAdmin.
En el panel de la izquierda, selecciona tu base de datos.
En la pestaña Exportar, puedes hacer una copia de seguridad de seguridad (¡siempre es buena idea!).
Ahora, en la pestaña SQL, ejecuta el siguiente comando para reparar todas las tablas:
```
REPAIR TABLE `ps_orders`, `ps_customer`, `ps_product`;
```
(Sustituye los nombres por los de tus tablas, o simplemente repara todas las que veas).
También puedes usar el comando CHECK TABLE para verificar el estado.

Usando SSH (más potente)

Si tienes acceso SSH, puedes reparar todas las tablas de una sola vez con el cliente de MySQL:

mysqlcheck -u tu_usuario -p --repair --all-databases

Te pedirá la contraseña del usuario de MySQL. Este comando intentará reparar todas las bases de datos del servidor.

Paso 6: Buscar errores en los logs de MySQL

Si nada de lo anterior funciona, es hora de mirar los registros del sistema. Los logs de MySQL contienen información detallada sobre qué está fallando.

Dónde encontrar los logs en Plesk

Ve a Herramientas y configuración.
En la sección General, haz clic en Registros (o "Logs").
Busca el log de MySQL (a menudo llamado mysql.log o mysqld.log).
También puedes acceder por SSH y ver el log en tiempo real:
```
tail -f /var/log/mysql/error.log
```
O en sistemas CentOS:
```
tail -f /var/log/mysqld.log
```

Busca líneas que contengan [ERROR]. El mensaje te dará pistas sobre el problema real, como "Access denied for user", "Table doesn't exist" o "Too many connections".

Paso 7: Soluciones avanzadas: `innodb_force_recovery`

Este es un último recurso para casos muy graves, como cuando MySQL no arranca debido a un fallo grave de InnoDB (el motor de almacenamiento por defecto).

Edita el archivo de configuración de MySQL (/etc/my.cnf).
Añade la siguiente línea dentro de la sección [mysqld]:
```
innodb_force_recovery = 1
```
Intenta arrancar MySQL. Si arranca, haz una copia de seguridad de tus bases de datos inmediatamente.
Ve aumentando el número (2, 3, 4...) si no arranca, pero ten en cuenta que esto pone MySQL en modo de solo lectura y puede causar pérdida de datos.
Una vez recuperados los datos, elimina esta línea y reinicia MySQL.

[WARNING] Usar innodb_force_recovery es una operación de emergencia. No la dejes activa permanentemente. Puede provocar corrupción de datos. Es preferible contactar con un administrador de sistemas profesional si llegas a este punto.

Prevención: Cómo evitar futuros errores de conexión

Una vez que hayas solucionado el problema, es crucial tomar medidas para que no vuelva a ocurrir.

1. Monitorización de recursos

El error "Too many connections" es común si tu servidor se queda sin memoria. Instala un monitor de recursos o revisa el uso de memoria en Plesk a menudo.

2. Optimización de la base de datos

Realiza un mantenimiento regular de tu base de datos. Puedes programar un cron job que ejecute mysqlcheck --optimize --all-databases una vez a la semana.

3. Copias de seguridad periódicas

Plesk tiene una herramienta de copias de seguridad muy potente. Configúrala para que haga un backup completo (archivos y bases de datos) al menos una vez al día si tu tienda tiene movimiento.

4. Mantén todo actualizado

Tanto PrestaShop como el propio Plesk y el sistema operativo del servidor deben estar siempre actualizados. Las actualizaciones corrigen bugs que pueden causar este tipo de fallos.

Conclusión

Hemos recorrido un camino completo desde lo más básico (¿está el servicio activo?) hasta lo más avanzado (reparación de tablas InnoDB). El error "Failed to connect to MySQL" en PrestaShop con Plesk es frustrante, pero como has visto, es diagnosticable y solucionable.

Recuerda el orden lógico:

Comprueba que MySQL/MariaDB está corriendo.
Verifica las credenciales en parameters.php contra las de Plesk.
Revisa el host de la conexión.
Mira el firewall.
Repara tablas corruptas.
Analiza los logs.
Usa el modo de recuperación solo como último recurso.

Con un poco de paciencia y siguiendo estos pasos, tu tienda volverá a estar en línea. Si después de todo esto el error continúa, es el momento de contactar con tu proveedor de hosting y proporcionarles la información de los logs, ya que puede ser un problema a nivel de hardware o de configuración del servidor que escapa a tu control. ¡Mucha suerte!