El servidor MySQL se ha ido
WordPress tenía una conexión de base de datos de trabajo y lo perdió la mitad de la investigación. La consulta es raramente culpa; la conexión es.
WordPress database error MySQL server has gone away for query …
Tres cosas dejan una conexión en vivo: una consulta más grande que max_allowed_packet, un período ocioso más largo que wait_timeout, o MySQL restarting. Compruebe si el servidor ha estado más alto que el sitio tiene, porque un tiempo de inactividad baja responde a la pregunta inmediatamente y los otros dos no necesitan pruebas.
Las causas más probables primero.
Revisa la lista en orden. Cada comprobación permite confirmar o descartar una causa antes de hacer cambios: las soluciones son distintas y adivinar cuesta más que ejecutar un comando.
| Causa | Cómo comprobarlo | Solución |
|---|---|---|
| Una consulta más grande que max_allowed_packet | El fracaso sigue una gran importación, un post con un valor meta serializado muy grande, o una restauración de respaldo, y falla en el mismo punto cada vez más que aleatoriamente. | Eleve max_allowed_packet en el servidor para superar cómodamente la mayor declaración individual. Este es un techo lado del servidor, por lo que un ajuste lado del cliente no lo mueve. |
| La conexión se ha reducido a más de wait_timeout | Las operaciones de administración larga fallan cerca del final mientras que las cargas de página ordinarias nunca hacen. La brecha entre dos consultas superó el tiempo de salida y MySQL cerró el socket. | Elevar wait_timeout , o romper el trabajo en lotes más cortos por lo que ninguna conexión se sienta ocioso durante tanto tiempo. El batido es el más duradero de los dos. |
| MySQL se reincendió o fue asesinado | El tiempo de funcionamiento del servidor es más corto que el sitio, o el registro de errores registra un cierre. Los asesinatos fuera de memoria son la razón habitual en las máquinas pequeñas. | Encuentra por qué se detuvo antes de reiniciarlo. Una base de datos que fue asesinada una vez por memoria será asesinada de nuevo bajo la misma carga. |
| La base de datos está negando nuevos trabajos | Los errores se agrupan bajo carga y se aclaran cuando el tráfico cae, y la lista de procesos está cerca de max_connections. | Reducir lo que está manteniendo conexiones en lugar de elevar el límite. Las consultas de larga duración que ocupan ranuras son la causa; un techo superior sólo retrasa el mismo fracaso. |
Solución paso a paso.
Los comandos requieren WP-CLI y acceso a la consola. Si no los tienes, cada paso explica cómo hacer lo mismo desde el panel o por SFTP.
Pregunta cuánto tiempo ha estado funcionando el servidor
Una vez más corta que la última vez que el sitio funcionó significa que la base de datos se reinicia, y nada más en esta lista necesita comprobar.
mysqladmin status mysql -e "SHOW GLOBAL STATUS LIKE 'Uptime';"
Lea los dos límites que importan
El tamaño del paquete y el tiempo libre cuenta para la mayoría de lo que queda una vez que se descarta un reinicio.
mysql -e "SHOW VARIABLES WHERE Variable_name IN ('max_allowed_packet','wait_timeout','interactive_timeout');"Aumentar el techo del paquete si una importación está fallando
Establecelo en la configuración del servidor en lugar de por sesión, por lo que una restauración administrada por cualquier herramienta lo hereda.
[mysqld] max_allowed_packet = 256M wait_timeout = 300
Comprueba si fue asesinado por memoria
El registro del núcleo nombra el proceso que eligió. Esta es la causa más común en un pequeño servidor que ejecuta MySQL junto a PHP.
dmesg -T | grep -i -E 'out of memory|killed process' | tail -n 20
Retrocede la operación en piezas más pequeñas
Si el trabajo es una importación, el batido mantiene todas las declaraciones bien bajo el techo y cada conexión ocupada.
wp db import dump.sql wp db check
De esto se encarga la plataforma.
La base de datos se ejecuta en su propio contenedor con una asignación de memoria que le pertenece solo, por lo que un proceso PHP que espigas no pueden conseguir que MySQL muera por el núcleo, el modo de fallo detrás de la mayoría de estos errores en una sola máquina compartida. Los valores de paquete y timeout se dimensionan en contra de esa asignación en lugar de dejar en las distribuciones por defecto que una gran restauración supera inmediatamente.
Preguntas frecuentes.
¿Mis datos están dañados?
¿Por qué sólo durante las importaciones y copias de seguridad?
¿Debería poner wait_timeout muy alto?
¿Cómo es diferente de “error estableciendo una conexión de base de datos”?
Si el problema era otro.
Estos errores pueden parecerse en el navegador.