Esta sección también explica el error relacionado
Lost connection to server during query.
La razón más común para el error MySQL server has gone
away es que el servidor ha agotado el tiempo de espera
y ha cerrado la conexión. En este caso, normalmente obtendrá uno de los
siguientes códigos de error (dependiendo del sistema operativo):
| Código de error | Descripción |
CR_SERVER_GONE_ERROR |
El cliente no pudo enviar una consulta al servidor. |
CR_SERVER_LOST |
El cliente no obtuvo ningún error al escribir al servidor pero tampoco obtuvo una respuesta completa (o ninguna respuesta) a la pregunta. |
Por defecto, el servidor cierra la conexión tras ocho horas si no
pasa nada. Puede cambiar el límite de tiempo estableciendo la variable
wait_timeout cuadno inicie mysqld
Consulte Sección 5.3.3, “Variables de sistema del servidor”.
Si usted tiene un script, tiene que ejecutar la consulta de nuevo
para que el cliente haga una reconexión automática. Esto da por hecho
que tiene la reconexión automática activada en el cliente (que es la opción por
defecto en el cliente de línea de comandos mysql).
Otras razones comunes por las que puede aparecer el error MySQL server has gone
away son:
Usted (o el administrador de la base de datos) ha matado el hilo que se estaba
ejecutando con una sentencia KILL o el comando
mysqladmin kill.
Usted ha intentado ejecutar una sentencia tras cerrar la conexión con el servidor. Esto es síntoma de un error lógico en la aplicación que debería ser corregido.
Se ha agotado el tiempo de espera de una conexión TCP/IP desde el lado cliente. Esto puede
ocurrir si usted ha estado utilizando los comandos:
mysql_options(...,
MYSQL_OPT_READ_TIMEOUT,...) o
mysql_options(...,
MYSQL_OPT_WRITE_TIMEOUT,...). En este caso, aumentar el tiempo de espera
puede ayudar a resolver el problema.
Se ha agotado el tiempo de espera en el lado del servidor, y el cliente no tiene
activada la opción de reconexión automática (la opción reconnect en la
estructura MYSQL es igual a 0).
Usted está utilizando un cliente windows y el servidor ha cortado la conexión (probablemente
porque wait_timeout ha expirado) antes de que el comando fuese ejecutado.
El problema en windows es que en algunos casos MySQL no obtiene un error desde el SO cuando escribe a la conexión TCP/IP desde el servidor, sino que obtiene el error cuando intenta leer la respuesta desde la conexión.
En este caso, aunque el flag reconnect en la estructura
MYSQL sea igual a 1, MySQL no reconecta y vuelve a ejecutar
la sentencia, ya que no sabe si el servidor recibió la sentencia original o no.
La solución a esto es o hacer un mysql_ping en la conexión si ha pasado
mucho tiempo desde la última sentencia (esto es lo que MyODBC hace) o
establecer un wait_timeout en el servidor mysqld
tan alto que en la práctica, nunca llegue a sobrepasarse.
También puede obtener estos errores si envía una consulta al servidor que sea incorrecta
o demasiado grande. Si mysqld recibe un paquete que es demasiado
grande o fuera de lugar, asume que ha habido algún error con el cliente y cierra la
conexión. Si necesita realizar grances consultas (por ejemplo, si está trabajando con
columnas BLOB muy grandes), debería incrementar el límite de las consultas
estableciendo la variable de servidor max_allowed_packet, que tiene un valor
por defecto de 1MB. También podría necesitar incrementar el tamaño máximo de paquete en el
lado cliente. Puede encontrar más información para establecer el tamaño de paquete en
Sección A.2.9, “Packet too large”.
También puede perder la conexión si envía un paquete de más de 16MB y su cliente es anterior a la versión 4.0.8 y su servidor posterior a 4.0.8, o viceversa.
También puede ver el error MySQL server has gone
away si MySQL se inicia con la opción --skip-networking.
Ha encontrado un error por el que el servidor cayó mientas ejecutaba una sentencia.
Puede comprobar si el servidor MySQL cayó y se reinició ejecutando mysqladmin version y examinando el tiempo de ejecución del servidor (uptime). Si la conexión del cliente se cortó debido a que mysqld falló y se reninicó, debería intentar encontrar la razón del fallo. Comience por comprobar si ejecutando la misma sentencia el servidor cae de nuevo. Consulte Sección A.4.2, “Qué hacer si MySQL sigue fallando (crashing)”.
Puede obtener más información sobre las conexiones perdidas iniciando mysqld con la
opción --log-warnings=2. Esto registra algunos de los errores de
desconexión en el archivo hostname.err. Consulte Sección 5.10.1, “El registro de errroes (Error Log)”.
Si quiere crear un informe de error en relación a este problema, asegúrese de incluir la siguiente información:
Indique si el servidor MySQL murió. Puede enecontrar esta información en el registro de errores del servidor. Consulte Sección A.4.2, “Qué hacer si MySQL sigue fallando (crashing)”.
Si una consulta específica mata a mysqld y las tablas implicadas habían sido
comprobadas con CHECK TABLE antes de ejecutar la consulta, ¿puede proporcionar
una prueba que permita reproducir el caso? Consulte Sección D.1.6, “Crear un caso de prueba tras haber encontrado una tabla corrupta”.
¿Cual es el valor de la variable de sistema wait_timeout en el
servidor MySQL? (mysqladmin variables le da el valor de esta variable.)
Ha intentado ejecutar mysqld con la opción --log
para determinar si la consulta problemática aparece en el registro?
Consulte también Sección A.2.10, “Errores de comunicación y conexiones abortadas”.
Consulte Sección 1.6.1.2, “Hacer preguntas y reportar bugs”.
Ésta es una traducción del manual de referencia de MySQL, que puede encontrarse en dev.mysql.com. El manual de referencia original de MySQL está escrito en inglés, y esta traducción no necesariamente está tan actualizada como la versión original. Para cualquier sugerencia sobre la traducción y para señalar errores de cualquier tipo, no dude en dirigirse a mysql-es@vespito.com.
