La solución de Cluster de Mysql no sirve para todo el mundo. Un administrador puede encontrarse con que tras 1 semana entera de trabajo, las 6 máquinas resultantes le dan un resultado mucho peor que la base de datos sencilla que tenía antes. ¿Porqué ocurre esto?. Porque antes de instalar, hay que saber lo que se está instalando.

MySQL Cluster es una solución de ALTA DISPONIBILIDAD. Un cluster empieza a ser rentable cuando existe un número de conexiones ALTO. Es decir, allá donde una sola instancia de MySQL empieza a tener problemas de rendimiento, el cluster es capaz de aguantar (y no sólo aguantar, sino crecer adecuadamente y en horizontal hasta un número de conexiones simultáneas y consultas razonable).

.

También es importante saber que el tiempo de recuperación de un Cluster de MySQL es MUY alto comparado a una base de datos de un sólo nodo y varios gigas de tamaño. Dicho en claro, es muy difícil que se caiga el cluster, pero una vez se ha caido, os vais a pasar 10-20 minutos recuperando y arrancando, como mínimo.

Además, añadir otro nodo de almacenamiento no es trivial. Hay que ELIMINAR TODO lo almacenado, añadir el nuevo nodo, y recuperar de backup. Esto es así porque el proceso “ndb” hay de regenerar todo su estructura interna, la cual cambia al añadir otro nodo.

Más…despues del salto.

Las principales diferencias con respecto a una replicación MAESTRO-ESCLAVO son:

- Permite escrituras en todos los nodos de acceso. Salvo configuraciones extrañas, en la replicación Maestro-esclavo se deben enviar los INSERT siempre a un nodo.

- Permite crecer más de dos nodos. Antes que me lo digáis, ya se que existe por ahí una configuración llamada replicación circular, que permite crecer 3+ nodos, pero da muchos problemas. La otra configuración posible con varios servidores MASTER, también es una buena manera de meterse en serios problemas.

Cuando llega el momento en que realmente empezáis a notar ralentización en ciertas querys, los procesos de MySQL no bajan del 90%, y el backup se eterniza, ese es el momento de empezar a pensar en:

1- Contratar un DBA y un látigo para los programadores, y optimizar por una vez todos esos select con “cross join” milenarios.

2- Montar un Cluster de MySQL para dar soporte al crecimiento futuro de tus aplicaciones.

.

Una vez ya se ha decidido probar MySQL Cluster (y fijáos, digo PROBAR), lo primero es sentarse, y ver si las LIMITACIONES (en inglés) de Mysql Cluster

Lo que más me llamó la atención de las limitaciones, es el número máximo de tablas, y ciertos tipos de campos (FULLTEXT) que no se pueden usar.

Además de esas limitaciones, los Cluster de MySQL no conviven muy bien con las consultas con varios JOIN. Es esta una de las limitaciones más serias, puesto que tiene un efecto inmediato en el rendimiento, y a veces no son fáciles reprogramar.

.

La maqueta en la que se ha de probar el Cluster no puede tener menos de 3 nodos. Y esta es la configuración mínima requerida para cualquier cluster.

- 1 nodo de gestión (proceso ndb_mgmd). Este proceso no carga nada, se puede meter en cualquier lado y no ocupa espacio siquiera. Pero, dicho claramente, TIENE QUE ESTAR arrancado, porque es el encargado de coordinar los diferentes nodos y su ausencia puede causar falta de sincronía.

- 2 servidores, cada uno con un nodo de almacenamiento (ndbd), y un nodo de acceso (mysql normales de toda la vida, pero que apuntan al cluster en vez de a local).

Lo mejor, es coger un volcado de las bases de datos que se van a migrar, modificar los tipos de datos y estructura, y probar a meterlos en esta maqueta. De esta manera podremos hacer un DIMENSIONADO adecuado del futuro cluster en producción.

.

¿Y ahora, almaceno las tablas en disco o en memoria?

La decisión es bien fácil. Si te puedes permitir tener servidores con tanta RAM como para que quepa entera tu base de datos, mas el crecimiento futuro, almacena todo en RAM.

Si tu empresa es modesta (aunque sea un google en potencia), puedes almacenar las tablas en disco.

Hay que tener en cuenta que almacenar las tablas en disco aumenta el tiempo de respuesta, aunque las pruebas realizadas indican que este aumento es algo inferior al esperado, sobre todo una vez has ajustado las cachés a disco.

Además, no todo va a disco, sino que almacena los índices en memoria. Esto hace que no podáis pillar el típico server barato de 1 giga de RAM y un disco SATA de 750GB, y haya que ir a servidores con 2+ gigas de RAM si se quieren hacer bien las cosas.

Desde que comenzé con el Cluster, visito el blog de Johan Andersson cada día. En dicha web viene un script para DIMENSIONAR clusters que es sencillamente, perfecto.

La razón de ejecutarlo sobre una maqueta es que el script será capaz de decirte el tamaño de los TABLESPACES que almacenarán las tablas en disco.

Con los datos que os proporcione ese script, y un poco de maña a la hora de estimar el crecimiento futuro de vuestras bases de datos, y de los accesos a la misma, seréis capaces de calcular el número de nodos que necesitáis.

.

Para finalizar esta parte, un apunte sobre el backup. Este se realiza simultáneamente en todos los nodos con la herramienta de backup del cluster. Este deja unos ficheros en el directorio del cluster, sin comprimir. No tiene un impacto excesivo en el rendimiento del cluster, y durante las pruebas este casi ni se inmutó mientras le hacia querys con mysqlslap y hacía el backup a la vez.

Recomiendo utilizar el mk-parallel-dump de maatkit. El rendimiento no tiene comparación con respecto a mysqldump.

A modo de consejo, escalad siempre de 2 a 4 nodos, luego a 8,etc…

.

Al final, podéis haber hecho dos cosas:

- Crear un cluster de MySQL que admite n-mil consultas por segundo, con n-cientos updates simultáneos, sobre bases de datos de varios GB, almacenados parte en disco, parte en RAM, todo en alta disponibilidad con un tiempo de recuperación aceptable.

- Un monstruo inutil que tarda 3 segundos más por consulta que un solo nodo, se cae porque no cabe en la RAM o los tablespaces se llenan, y cuando se cae, no hay manera de levantar en un tiempo razonable. Vuestra empresa pierde dinero, y os vais a la calle por torpes.

Así que mejor, os lo pensáis dos veces antes de instalarlo, y retomáis la opción de ampliar el Mysql Actual.

Proximamente, la instalación de un cluster completo de MySQL, proceso que dura 15 minutos, y causa unas dos semanas de insomnio si se hace mal, y cómo gestionar el monstruo recién creado.