¿Cómo tener mejor confiabilidad de mysqld en EC2?

Tenemos serios problemas de estabilidad con mysqld ejecutándose en hosts Linux en EC2, con todos sus datos y files de logging almacenados en un volumen EBS. Mantenemos un esclavo puramente para la copy de security y la conmutación por error, y cuando el maestro se cae, por lo general podemos traer al esclavo como un maestro sin ningún problema, y ​​luego crear un nuevo esclavo.

Pero es muy problemático que nuestro maestro simplemente se vaya abajo. El host maestro sigue funcionando bien, pero mysqld no responderá a nada, y ni siquiera se puede matar con kill -9.

Esto ocurre tanto en nuestros entornos de producción como en los escenarios, que son similares, pero la producción se ejecuta en instancias grandes (con Centos 5.2 x86_64) y en escenarios en instancias medianas (con Centos 5.2 i686).

¿Alguien ha experimentado problemas similares de estabilidad de mysqld en EC2, y si es así, ¿cómo lidiar con ellos?

Gracias por adelantado.

Si mysqld no va a morir incluso con un kill -9, entonces el problema es casi seguro que está en el sueño ininterrumpido esperando el disco IO. Esto sugiere fuertemente que tienes un dud EBS, que sucede a veces. Si te sientes excesivamente optimista, puedes intentar ponerte en contacto con el soporte de Amazon, pero la solución más rápida es crear un nuevo EBS y usarlo (esperamos que estés en una unidad de almacenamiento de less crap) o tratar de cambiar a una disponibilidad diferente zona. Sí, son opciones de bollocks, pero EC2 simplemente falla como a veces y estás efectivamente atornillado.

Convenido. Tenemos algunas instancias largas de ec2mysql y no hemos tenido problemas. Suena como un problema de hardware específico de su entorno.

Trate de conectarse como root (es decir, el usuario root mysql, no su usuario root normal). Es posible que haya demasiadas conexiones a mysql, lo que impide nuevas conexiones. La count raíz mysql es excepto a partir de estas restricciones y siempre se puede conectar.