MySQL Cluster (NDB) vs MySQL Replication (InnoDB) para Rails 3 aplicaciones: pros/contras?

Question

Estamos haciendo una descripción general de nuestros sistemas actuales, tratando de averiguar si podemos mejorar la fiabilidad del rendimiento &.

Actualmente ejecutamos un montón de aplicaciones internas de Rails y nuestro sitio web basado en Rails. Algunos ya son Rails 3, algunos se están convirtiendo a Rails 3. Todos se conectan a la siguiente configuración de MySQL.

mysql01 (master server) => mysql02 (slave) => (copias de seguridad diarias de la base de datos en una unidad, que se respalda en una base diaria, semanal y mensual de & semestral).

Todas las escrituras ocurren en mysql01 y la mayoría de las lecturas cortas también lo incluyen, algunas "lecturas que consumen más recursos" (como informes mensuales/semanales que tardan 3-10 minutos en ejecutarse y volcar datos en csv o copias de seguridad). servidor mysql02 Recibimos aproximadamente 3-5,000 visitas por día a nuestro sitio, y tenemos entre 20 y 30 usuarios internos, que usan varias aplicaciones a diario para inventarios, procesamiento de pedidos, etc. Por lo tanto, estos servidores no están particularmente bajo cargas pesadas, aparte de los informes, que Ejecución del esclavo de todos modos.

Todos los servidores se ejecutan en un grupo virtualized XEN en Debian Lenny VM.

Así que estamos haciendo una revisión de los sistemas, y alguien lanzó una sugerencia de cambiar a la configuración MySQL Cluster (NDB). Lo sé en teoría, pero en realidad nunca lo he ejecutado. Entonces, ¿alguien que tenga experiencia sabe de pro/contras contra nuestra configuración actual, y de cualquier advertencia particular cuando se trata de aplicaciones de Ruby/Rails?

Answer 1

Hay una buena comparación de InnoDB y MySQL Cluster (NDB) recientemente publicado de los documentos ... vale la pena echar un vistazo: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-compared.html

La arquitectura Cluster consiste en un grupo de servidores de MySQL que se accede por la aplicación (es); estos servidores MySQL en realidad no almacenan los datos del clúster, los datos se dividen en el grupo de nodos de datos a continuación. Cada servidor MySQL tiene acceso a los datos en todos los nodos de datos. Si un servidor MySQL cambia una parte de los datos, entonces es instantáneamente visible para todos los otros servidores MySQL.

Obviamente, esta arquitectura hace que sea extremadamente fácil escalar la base de datos. A diferencia de la fragmentación, la aplicación no necesita saber dónde se guardan los datos: puede cargar el equilibrio entre todos los servidores MySQL disponibles. A diferencia de la ampliación con la replicación de MySQL, Cluster le permite escalar las escrituras tan bien como las lecturas. Se pueden agregar nuevos nodos de datos o servidores MySQL a un clúster existente sin pérdida de servicio para la aplicación.

La arquitectura compartida de MySQL Cluster no significa que puede ofrecer una disponibilidad extremadamente alta (99.999% +). Cada vez que cambia los datos, se replican sincrónicamente en un segundo nodo de datos; si un nodo de datos falla, entonces las aplicaciones leen & las solicitudes de escritura son manejadas automáticamente por el nodo de datos de la copia de seguridad.

Debido a la naturaleza distribuida de MySQL Cluster, algunas operaciones pueden ser más lentas (por ejemplo, JOINs que tienen miles de resultados provisionales, aunque hay una solución prototipo disponible que soluciona esto) pero otros pueden ser muy rápidos y pueden escalar extremadamente bien (por ejemplo, lecturas y escrituras de teclas principales). Tiene la opción de almacenar tablas (o incluso columnas) en la memoria o en el disco y al elegir la opción de memoria (con los cambios marcados en el disco en el backgoround) las transacciones pueden ser muy rápidas.

MySQL Cluster puede ser más complejo de configurar que un solo servidor MySQL pero puede evitar tener que implementar fragmentación o división de lectura/escritura en su aplicación. Columpios y rotondas.

Para obtener el mejor rendimiento y escalabilidad de MySQL Cluster, es posible que necesite modificar su aplicación (consulte el documento técnico de ajuste del rendimiento del clúster: http://www.mysql.com/why-mysql/white-papers/mysql_wp_cluster_perfomance.php). Si posee la aplicación, esto normalmente no es un gran problema, pero si está utilizando la aplicación de otra persona que no puede modificar, entonces podría ser un problema.

Una nota final es que no necesita ser todo o nada: puede elegir almacenar algunas de sus tablas en Cluster y algunas usando otros motores de almacenamiento, esta es una opción por tabla. También puede replicar entre Cluster y otros motores de almacenamiento (por ejemplo, use Cluster para su base de datos en tiempo de ejecución y luego replíquelo a InnoDB para generar informes complejos).