O cómo cargarte un servidor de bases de datos por tocar un parámetro de configuracion 😛 .

Hace un par de semanas tuvimos una incidencia con el MySQL de uno de nuestros servidores. Algunas tablas comenzaron a devolver errores extraños referentes a /tmp y al archivo de índices de algunas tablas. Lo siento, no tengo el mensaje concreto. El caso es que la base de datos estaba inutilizada. Tras investigar un poco por Google comencé a probar algunos cambios de parametrización en /etc/my.cnf. Me pareció muy extraño puesto que la configuración que utilizamos lleva muchos años dando buen resultado, de hecho no es ni por asomo hoy por hoy el momento de mayor actividad que hemos tenido.

Tras hacer un poco el tonto caí en la cuenta, ríanse de mi, de que la máquina se había quedado sin espacio en disco 😛 . Era esto lo que provocaba que no se pudieran regenerar los índices de las tablas y demás errores asociados.

Una vez solucionado el error todo comenzó a funcionar con normalidad y parecía que todo iba bien. Craso error.

Hace unos días nos dimos cuenta que el log de MySQL se estaba llenando de mensajes de error como éste sin aparente explicación:

080902  0:51:42 [ERROR] /usr/libexec/mysqld: Incorrect key file for table ‘./basededatos/tabla.MYI’; try to repair it

Lanzando un repair table tabla se solucionaba el error, pero era algo temporal, pronto volvía a aparecer, sino era con esa tabla era con otras. Incluso tablas de bases de datos sin apenas uso.

Googleando de nuevo, el primer resultado me dió la clave. Sí, era uno de los parámetros que había modificado el día que me había quedado sin espacio en disco y no lo había restaurado.

key_cache_block_size=1024

Había leído que aumentando este parámetro se solucionaría el error, así que ni corto ni perezoso lo puse a 10024 y así se quedó aunque el problema no se solucionó 😛 .

Al parecer este parámetro debe tener un valor que sea potencia 2 de 512, sino aparecerán los errores aleatorios en los archivos de índices que nos estaban ocurriendo a nosotros.

Restauramos el valor a 1024, reiniciamos el servidor de bases de datos y, por arte de magia, los problemas desaparecieron.

Como conclusión sacamos que el parámetro más absurdo puede hacernos perder días de investigación y problemas, en mi caso a las cuatro de la madrugada 😛 . Esta vez tuvimos suerte. Para la próxima, pensaré en apuntar cada cambio que haga, por si acaso…