Ya colgamos la base de datos dos veces e intentamos encontrar una causa.

show processlist
Waiting for global read lock | INSERT INTO {myisam_table} ...

Aquí el espacio en disco estaba lleno, así que pensamos que el problema había terminado después de darle un poco más, pero al día siguiente al mediodía volvió a colgar:

show processlist
Waiting for table level lock | UPDATE {myisam_table} ... 

¿Qué podría estar causándolo?

Motor predeterminado de Mysql: InnoDB.

La base de datos tiene una mezcla de tablas con los motores MyISAM e InnoDB.

Registro publicado aquí:

http://arturito.net/2013/08/28/mysql-waiting-for-table-level-lock-errors/

OBSERVACIONES INICIALES

• El ID de proceso 42686 dice que se está preparando para ejecutar una consulta SELECT
• Hay algunas conexiones para dormir
• Todos los demás procesos no pueden adquirir un bloqueo de tabla
• Hubiera esperado una ACTUALIZACIÓN, BORRAR o INSERTAR para hacer el bloqueo. No se reclama la propiedad de la tabla en cuestión.
• No se puede ver la consulta completa en el identificador de proceso 42686, pero sospecho que se trata de una JOIN, GROUP BYoORDER BY

TEORIA DE TRABAJO

Si te quedaste sin espacio en disco con la lista de procesos que me diste, entonces podemos echarle la culpa al motor de almacenamiento MyISAM. ¿Por qué?

En su caso particular, no es una de sus tablas. Si una JOIN, GROUP BYo ORDER BYse estaba ejecutando y una tabla temporal se estaba escribiendo en el disco (en el disco tablas temporales utilizan el motor de almacenamiento MyISAM) de MySQL simplemente se congela cuando está fuera del espacio. Cómo sé eso ?

De acuerdo con la Guía de estudio de certificación MySQL 5.0

Página 408,409 La sección 29.2 Punto 11 dice:

Si se queda sin espacio en disco al agregar filas a una tabla MyISAM, no se produce ningún error. El servidor suspende la operación hasta que haya espacio disponible y luego completa la operación.

He discutido esta situación antes

• Apr 05, 2013: El servidor MySQL "Site Offline" no puede iniciarse y detenerse
• Dec 17, 2012: ¿Cómo resolver el error 1114 "La tabla está llena" de MySQL con Amazon RDS?
• Apr 25, 2012: Archivos de registro muy grandes
• Mar 15, 2012: ¿Por qué fallan las tablas MySQL? ¿Cómo lo evito?

Algo me dice que tienes una de estas dos situaciones

• tablas temporales basadas en disco para sus SELECT y competir por espacio con sus datos regulares
• Si la tabla temporal está aterrizando en /tmpla partición raíz, se está quedando sin espacio

SUGERENCIAS

Sugerencia n. ° 1: asigne tmpdir a otro disco

[mysqld]
tmpdir = /another/disk/besides/root/partition

Sugerencia n. ° 2: crear un disco RAM

Ejecute este código para instalar un disco RAM que estará disponible en el reinicio de Linux.

RAMDISK_SIZE=32g
service mysql stop
mkdir /var/tmpfs
echo "none   /var/tmpfs  tmpfs  defaults,size=${RAMDISK_SIZE} 1 2" >> /etc/fstab
mount -t tmpfs -o size=${RAMDISK_SIZE} none /var/tmpfs
cp -R /var/lib/mysql/* /var/tmpfs
mv /var/lib/mysql /var/lib/mysql_old
ln -s /var/tmpfs /var/lib/mysql
chown -R mysql:mysql /var/tmpfs
chown -R mysql:mysql /var/lib/mysql
service mysql start

Luego, asigne tmpdir a/var/tmpfs

DARLE UNA OPORTUNIDAD !!!