Skip navigation links
A.4.3 Cómo se comporta MySQL ante un disco lleno »
Section Navigation      [Toggle]

A.4.2. Qué hacer si MySQL sigue fallando (crashing)

Cada versión de MySQL es probada en muchas plataformas antes de ser lanzada al público. Esto no significa que no haya ningún fallo en MySQL, pero si hay alguno, deberían ser muy pocos y difíciles de encontrar. Si tiene un problema, siempre ayuda si usted intenta encontrar qué es lo que hace fallar su sistema exactamente, porque tendrá una probabilidad mucho mayor de que su problema sea solucionado rápidamente.

Primero, debería intentar averiguar si el problema es que el servidor mysqld muere o el problema tiene que ver con su cliente. Puede comprobar cuando tiempo se ha estado ejecutando ininterrumpidamente su servidor ejecutando mysqladmin version. Sí mysqld ha caido y se ha reiniciado, podría encontrar la razón mirando en el registro de errores del servidor. Consulte Sección 5.10.1, “El registro de errroes (Error Log)”.

En algunos sistemas, puede encontrar en volcado de pila en el registro de errores del momento en que el servidor mysqld murió, y que puede analizar con el programa resolve_stack_dump. Consulte Sección D.1.4, “Usar stack trace”. Nótese que los valores de las variables escritos en el registro de errores pueden no ser siempre correctos al 100%.

Muchas caidas del servidor son causadas por archivos de datos o índices corruptos. MySQL actualiza los archivos en el disco con la llamada de sistema write() después de cada sentencia SQL y antes de que el cliente sea notificado del resultado. (Esto no es así si está ejecutando con --delay-key-write, en cuyo caso los archivos de datos son escritos pero no los de índices.) Esto significa que los contenidos de los archivos de datos están seguros aunque mysqld caiga, porque el sistema operativo se asegura de que los datos no volcados sean escritos al disco. Puede forzar a que MySQL escriba todo a disco tras cada sentencia SQL iniciando mysqld con la opción --flush.

Esto significa que normalmente usted no debería obtener tablas corruptas a menos que una de las siguientes cosas ocurra:

  • El servidor MySQL o la máquina han sido cerrados en medio de una actualización.

  • Usted ha encontrado un fallo en mysqld que ha causado que caiga en el medio de una actualización.

  • Algún programa externo está manipulando los archivos de datos o índices a la vez que mysqld sin bloquear la tabla apropiadamente.

  • Está ejecutando varios servidores mysqld utilizando el mismo directorio de datos en un sistema que no soporta un buen mecanismo de bloqueo de sistema de archivos (normalmente gestionado por el gestor de bloqueos lockd), o está ejecutando múltiples servidores con la opción --skip-external-locking.

  • Usted tiene un archivo de datos o índices erróneo que contiene datos muy corruptos que han confundido a mysqld.

  • Ha encontrado un fallo en el código de almacenaje de datos. Esto no es muy probable, pero es posible. En este caso, puede intentar cambiar el tipo de la tabla a otro motor de almacenamiento utilizando ALTER TABLE sobre una copia reparada de la tabla.

Debido a que es muy difícil saber por qué algo está fallando, primero intente comprobar las cosas que funcionan frente a las que fallan en su caso. Por favor, intente las siguientes comprobaciones:

  • Pare el servidor mysqld con mysqladmin shutdown, ejecute myisamchk --silent --force */*.MYI desde el directorio de datos para comprobar todas las tablas MyISAM, y reinicie mysqld. Esto le hará estar seguro de que está ejecutando el servidor desde un estado inicial limpio. Consulte Capítulo 5, Administración de bases de datos.

  • Inicie mysqld con la opción --log e intente determinar a través de la información escrita en el registro si hay alguna consulta particular que mate al servidor. Sobre el 95% de todos los fallos son relacionados con una consulta en particular. Normalmente, esta es una de las últimas consultas en el archivo de registro antes de que el servidor se reinicie. Consulte Sección 5.10.2, “El registro general de consultas”. Si usted puede matar repetidamente MySQL con una consulta específica, aún cuando ha comprobado todas las tablas antes de ejecutarla, entonces ha sido capaz de localizar el fallo, y debería enviar un informe de fallos. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”.

  • Intente hacer un juego de pruebas que podamos utilizar para repetir el problema. Consulte Sección D.1.6, “Crear un caso de prueba tras haber encontrado una tabla corrupta”.

  • Intente ejecutar las pruebas en el direcotrio mysql-test y los bancos de pruebas MySQL. Consulte Sección 27.1.2, “El paquete de pruebas MySQL Test”. Estos deberían comprobar bastante bien MySQL. También puede añadir código a los bancos de pruebas que simulen su aplicación. Los bancos de pruebas pueden ser localizados en el directorio sql-bench en una distribución de código fuente, o, en una distribución binaria, en el directorio sql-bench bajo su directorio de instalación de MySQL.

  • Intente el script fork_big.pl. (Está ubicado en el directorio tests de una distribución de código fuente.)

  • Si usted configura MySQL para depuración, es mucho más fácil recoger información sbore los posibles errores cuando algo va mal. Configurar MySQL para depuración causa que un gestor de memoria seguro se incluya para encontrar algunos errores. También produce muchas más salidas informativas sobre lo que está pasando. Reconfigure MySQL con la opción --with-debug o --with-debug=full para ejecutar después configure y seguidamente recompilar. Consulte Sección D.1, “Depurar un servidor MySQL”.

  • Asegúrese de que usted ha aplicado los últimos parches para su sistema operativo.

  • Utilice la opción --skip-external-locking para mysqld. En algunos sitemas, el gestor de bloqueos lockd no funciona apropiadamente; la opción --skip-external-locking le dice a mysqld que no utilice bloqueos externos. (Esto significa que no puede ejecutar dos servidores mysqld en el mismo directorio de datos, y que debe ser muy cuidadoso cuando utilice myisamchk). Aún así, puede ser muy instructivo intentar la opción como prueba.)

  • ¿Ha intentado el comando mysqladmin -u root processlist cuando mysqld parece estar ejecutándose pero no responde? A veces mysqld no está comatoso, aunque usted pueda pensar lo contrario. El problema puede ser que todas las conexiones estén en uso, o que haya algún problema de bloqueo interno. mysqladmin -u root processlist es normalmente capaz de hacer una conexión aún en esots casos, y puede proveerle de información útil sobre el número actual de conexiones y su estado.

  • Ejecute del comando mysqladmin -i 5 status o mysqladmin -i 5 -r status en una ventana separada para producir estadísticas mientras ejecuta sus otras consultas.

  • Intente lo siguiente:

    1. Inicie mysqld desde gdb (u otro depurador). Consulte Sección D.1.3, “Depurar mysqld con gdb”.

    2. Ejecute sus scripts de comprobación.

    3. Imprima el trazado y las variables locales en los tres niveles más bajos. En gdb, puede hacer esto con los siuguientes comandos cuando mysqld ha caido dentro de gdb: 

      backtrace
info local
up
info local
up
info local

      Con gdb, usted puede también examinar que hilos de ejecución existen con info threads y cambiar a un hilo específico con thread #, donde # es el ID del hilo.

  • Trate de simular su aplicación con un script Perl para forzar a que MySQL falle o se comporte indebidamente.

  • Envíe un informe de fallos normal. Consulte Sección 1.6.1.3, “Cómo informar de bugs y problemas”. Sea aún más detallado de lo normal. Debido a que MySQL funciona para mucha gente, podría ser que los fallos fueran resultado de algo que exista tan sólo en su máquina (por ejemplo, un error relacionado con sus librerías de sistema particulares).

  • Si usted tiene un problema con tablas que contengan filas de longitud dinámica y está utilizando únicamente columnas VARCHAR (no columnas BLOB ni TEXT), puede intentar cambiar todas las columnas VARCHAR a CHAR con ALTER TABLE. Esto fuerza a MySQL a utilizar filas de tamaño fijo. Las filas de tamaño fijo ocupan un poco más de espacio, pero son mucho más tolerantes a la corrupción.

    El código de filas dinámicas actual ha sido utilizado en MySQL AB durante muchos años con muy pocos problemas, pero las filas de longitud dinámica son, por naturaleza, más propensas a errores, así que podría ser una buena idea intentar esta estrategia y ver si ayuda.

  • No deje fuera el hardware de su servidor cuando esté diagnosticando problemas. El hardware defectuoso puede ser causa de corrupción de datos. Debe poner especial atención en la RAM y los discos duros cuando esté buscando problemas de hardware.

É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.