16.10. Preguntas frecuentes sobre MySQL Cluster

¿Qué diferencia hay entre usar cluster y replicación?

En una replicación, un servidor maestro MySQL actualiza uno o más esclavos. Las transacciones hacen commit secuencialmente, y una transacción lenta puede causar que el esclavo quede desactualizado. Esto significa que si falla el maestro, es posible que el esclavo pueda no haber registrado las últimas transacciones. Si un motor transaccional como InnoDB se usa, una transacción será completa en el esclavo o no aplicada en absoluto, pero la replicación no garantiza que todos los datos en el maestro y el esclavo sean consistentes siempre. En MySQL Cluster,todos los nodos de datos con un commit hecho por algun nodo de datos se realiza un commit para todos los nodos. En caso de un fallo de un nodo de datos, todos los nodos de datos restantes quedarán en un estado consistente.

En breve, mientras que la replicación estándar MySQL es asíncrona, MySQL Cluster es síncrono.

Planeamos implementar replicación asíncrona para Cluster en MySQL 5.1. Esto incluye la capacidad de replicar entre dos cluster y entre un cluster MySQL y un MySQL server no cluster.

¿Necesito hacer alguna configuración especial de red para el Cluster? (¿Cómo se comunican las máquinas en un cluster?)

MySQL Cluster está pensado para usarse en un entorno de gran ancho de banda, con máquinas conectadas via TCP/IP. Su rendimiento depende directamente en la velocidad de conexión entre las máquinas del cluster. Los requerimientos de conectividad mínimo para cluster incluyen una red típica 100-megabit Ethernet o equivalente. Recomendamos usar Ethernet cuando sea posible.

También se soporta el protocolo SCI (más rápido), pero necesita hardware especial. Consulte Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más información acerca de SCI.

¿Cuántas máquinas necesito para ejecutar un cluster, y porqué?

Como mínimo se necesitan tres máquinas. Sin embargo, el número mínimo recomendado en MySQL Cluster es cuatro: una para el nodo de administración y otra para el de SQL, y dos para servir como nodos de almacenamiento. El propósito de los dos nodos de datos es proporcionar redundancia; el nodo de administración debe ejecutarse en una máquina separada para garantizar servicio de arbitración contínuo en caso que un nodo de datos falle.

¿Qué hacen las distintas máquinas en un cluster?

Un MySQL Cluster tiene organización física y lógica, con máquinas como elementos físicos. Los elementos lógicos son los nodos, y una máquina hospedando un nodo es un huesped cluster. Idealmente, habrá un nodo por huesped cluster, aunque es posible ejecutar más de un nodo en una máquina. Hay tres tipos de nodos, cada uno correspondiente a un rol específico en el cluster. Son:

¿Qué sistemas operativos pueden usar Cluster?

En MySQL 5.0, MySQL Cluster se soporta oficialmente en Linux, Mac OS X, y Solaris. Estamos trabajando para añadir soporte a cluster para otras plataformas, incluyendo Windows, y nuestra finalidad es eventualmente ofrecer MySQL Cluster en todas las plataformas en que se soporta MySQL .

Puede ser posible ejecutar procesos Cluster en otros sistemas operativos. Hemos tenido reportes de usuarios que dicen que han ejecutado Cluster en FreeBSD. Sin embargo, Cluster en cualquier plataforma que no sen las 3 mencionadas aquí se considera software alfa (como mucho), no puede garantizarse el buen funcionamiento en un entorno de producción, y no lo soporta MySQL AB.

¿Cuáles son los requerimientos de hardware para ejecutar MySQL Cluster?

Cluster debe ejecutarse en cualquier plataforma en que los binarios de NDB estén disponibles. Naturalmente, una CPU más rápida y más memoria mejora el rendimiento, y CPUs de 64 bits serán mejores que los procesadores de 32. Debe haber suficiente memoria en las máquinas usadas por los nodos de datos para tratar cada parte de la base de datos (consulte ¿Cuánta RAM necesito? para más información). Los nodos pueden comunicarse via TCP/IP estándard y su hardware. Para soporte SCI, se necesita hardware especial de red.

Como MySQL Cluster usa TCP/IP, ¿significa que puedo usarlo en Internet, con uno o más nodos en una localización remota?

Es importante tener presente que la comunicación entre nodos en MySQL Cluster no es segura ; no está encriptada ni guardada por ningún otro mecanismo. La configuración más segura para un cluster es en una red privada detrás de un firewall, sin acceso directo a ningún nodo de datos ni de administración desde fuera.

Es muy dudoso que un cluster se muestre fiable bajo tales condiciones, ya que se diseñó e implementó con la suposición que se ejecutaría bajo condiciones que garantizaran conectividad dedicada de alta velocidad como las encontradas en configuraciones en una LAN con 100 Mbps o gigabit Ethernet (mejor la última). No testeamos ni garantizamos el rendimiento usando algo más lento que esto.

¿Debo usar nuevos lenguajes de programación o de consulta para usar Cluster?

No. Aunque se usan algunos comandos especializados para administrar y configurar el cluster, solo comandos estándard (My)SQL se necesitan para:

¿Cómo puedo sabar qúe significan loa mensajes de error o advertencias al usar Cluster?

Se puede hacer de dos modos:

¿Es MySQL Cluster transaccional? ¿Qué tipo de tablas se soportan en Cluster ?

Sí. MySQL Cluster utiliza tablas creadas con el motor NDB , que soporta transacciones. NDB es el único motor que soporta cluster.

¿Qué significa “NDB”?

Significa "Network Database".

¿Qué versiones de MySQL software soportan Cluster? ¿Debo compilarlo de las fuentes?

Cluster se soporta en todos los binarios MySQL-max en la serie 5.0, excepto lo que se explica en el siguiente parágrafo. Puede determinar si su servidor soporta o no NDB usando los comandos SHOW VARIABLES LIKE 'have_%'; o SHOW ENGINES;. (Consulte Sección 5.1.2, “El servidor extendido de MySQL mysqld-max” para más información.)

Usuarios de Linux , tengan en cuenta que NDB no se incluye en los RPM estándar de MySQL server. Desde MySQL 5.0.4, hay paquetes RPM separados para el motor NDB junto con herramientas de administración; consulte la sección de descargas NDB RPM de MySQL 5.0 Downloads . (Antes de 5.0.4, debe usar los binarios -max proporcionados como .tar.gz . Todabía es posible, pero no es un requerimiento, así que puede usar su administración de RPMs de Linux si lo prefiere.) Puede obtener soporte NDB compilando los binarios -max de las fuentes, pero no es necesario hacerlo para usar MySQL Cluster. Para descargar los últimos binarios, RMP o distribución fuente en la serie MySQL 5.0 visite http://dev.mysql.com/downloads/mysql/5.0.html.

¿Cuánta RAM necesito? ¿Es posible usar memoria de disco?

Actualmente, Cluster sólo funciona en memoria. Esto significa que todos los datos de tabla (incluyendo índices) se almacena en RAM. Por lo tanto, si sus datos ocupan 1 GB de espacio y quiere replicarlo en el cluster, necesitará 2 GB de memoria para ello. Esto es a parte de la memoria necesaria para el sistema operativo y cualquier aplicación ejecutándose en las máquinas del cluster.

Puede usar la siguiente fórmula para obtener una estimación aproximada de cuánta RAM necesita para cada nodo de datos en el cluster:

(SizeofDatabase * NumberOfReplicas * 1.1 ) / NumberOfDataNodes

Para calcular los requerimientos de memoria con más exactitud debe determinar, para cada tabla en la base de datos del cluster, el espacio de almacenamiento requerido por registro (consulte Sección 11.5, “Requisitos de almacenamiento según el tipo de columna” para más detalles), y multiplicarlo por el número de registros. Debe recordar tener en cuenta cualquier índice de columna como sigue:

Es especialmente importante tener en mente que cada tabla en MySQL Cluster debe tener clave primaria, que el motor NDB creará una clave primaria automáticamente si no se define y que esta clave primaria se crea sin USING HASH.

No hay una forma sencilla en MySQL 5.0 para determinar exactamente cuánta memoria se está usando para almacenar índices Cluster en un momento dado; sin embargo, las advertencias se escriben en el log del cluster cuando el 80% de memoria DataMemory y/o IndexMemory está en uso, y de nuevo al 85%, 90% etc.

A menudo vemos preguntas de usuarios que reportan que, cuando intentan rellenar una base de datos cluster, el proceso de carga termina prematuramente y aparece un mensaje de error como este:

ERROR 1114: The table 'my_cluster_table' is full

Cuando esto ocurre, la causa es que su configuración no proporciona suficiente RAM para todos los datos de tablas e índice , incluyendo la clave primaria requerida por el motor NDB y creada automáticamente en el caso que la definición de tabla no incluya la definición de la clave primaria.

Vale la pena tener en cuenta que todos los nodos de datos deben tener la misma cantidad de RAM, ya que ningún nodo de datos en el cluster puede usar más memoria que la mínima cantidad disponible para cualquier nodo de datos individual. En otras palabras, si hay tres máquinas con nodos de datos y dos tienen 3 GB RAM disponibles y otro sólo 1 GB de RAM, entonces cada nodo sólo puede usar 1 GB para el cluster.

En caso de un fallo catastrófico — por ejemplo, que la ciudad entera se queda sin electricidad y mi UPS falla — ¿perdería todos mis datos?

Todas las transacciones con commit se loguean. Por lo tanto, aunque es posible perder algunos datos en caso de catástrofe, debería ser algo limitado. La pérdida de datos puede reducirse minimizando el número de operaciones por transacción. (No es buena idea realizar un gran número de operaciones por transacción en cualquier caso.)

¿Es posile usar índices FULLTEXT con Cluster?

La indexación FULLTEXT no se soporta en el motor NDB , o por cualquier motor que no sea MyISAM. Estamos trabajando para añadir esta funcionalidad en nuevas versiones.

¿Puedo ejectura múltiples nodos en una sola máquina?

Es posible pero no recomendable. Una de las razones principales para ejecutar un cluster es proporcionar redundancia; para tener todos los beneficios de esta redundancia, cada nodo debe residir en máquinas separadas. Si tiene múltiples nodos en una misma máquina y esta falla, pierde todos estos nodos. Dado que MySQL Cluster puede ejecutarse en hardware dedicado cargado con sistemas operativos de bajo o ningún coste, vale la pena el gasto en una o dos máquina extra para guardar datos críticos. También vale la pena tener en cuenta que los requerimientos para una máquina cluster ejectuando un nodo de administración son mínimos; esta tarea puede realizarse con una CPU 200 MHz Pentium y suficiente RAM para el sistema operativo más una mínima cantidad de sobrecarga para los procesos ndb_mgmd y ndb_mgm .

¿Puedo añadir nodos en un cluster sin reiniciarlo?

No. Un reinicio es necesario para añadir nuevos nodos MGM o SQL. Al añadir nodos de datos el proceso es más complejo, y necesita los siguientes pasos:

En el futuro, esperamos implementar capacidad de reconfiguración “hot” para MySQL Cluster para minimizar (o eliminar) los requerimientos para reiniciar el cluster al añadir nuevos nodos.

¿Hay alguna limitación que deba tener en cuenta al usar Cluster?

Las tablas NDB tienen las siguientes limitaciones:

Para información adicional de limitaciones de cluster, consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster”.

¿Cómo importo una base de datos existente en un cluster?

Puede importar bases de datos en MySQL Cluster como con cualquier otra versión de MySQL. A parte de las limitaciones mencionadas anteriormente, el único requerimiento especial es que cualquier tabla que se incluya en el cluster debe usar el motor NDB. Esto significa que las tablas deben crearse con la opción ENGINE=NDB o ENGINE=NDBCLUSTER.

¿Cómo se comunican los nodos del cluster entre ellos?

Los nodos del Cluster pueden comunicarse meiante tres protocolos: TCP/IP, SHM (memoria compartida), y SCI (Scalable Coherent Interface). Donde está disponible, SHM se usa por defecto entre nodos residentes en el mismo equipo de cluster. SCI es un protocolo de alta velocidad (1 gigabit por segundo o más), alta disponibilidad usado en construir sistemas escalables de multi procesador; requiere hardware especial y drivers. Consulte Sección 16.7, “Usar interconexiones de alta velocidad con MySQL Cluster” para más información usando SCI como mecanismo de transporte en MySQL Cluster.

¿Qué es un “árbitro”?

Si uno o más nodos en un cluster fallan, es posible que no todos los nodos del cluster será capaz de “verse” entre ellos. De hecho, es posible que dos conjuntos de nodos puedan a estar aislados de los otros en una partición de red, también conocido como un escenario “split brain”. Este tipo de situación no es deseable ya que cada conjunto de nodos trata de comportarse como si fuera el cluster entero.

Cuando caen los nodos del cluster, hay dos posibilidades. Si más del 50% de los nodos restantes pueden comunicarse entre ellos, entonces tenemos lo que a veces se llama “reglas de mayoría” , y este conjunto de nodos se consideran como el cluster. El árbitro entra en juego cuando hay un número impar de nodos: en tales casos, el conjunto de nodos al que pertenece el árbitro se considera el cluster, y los nodos que no pertenecen a este grupo se paran.

La información anterior está simplificada; a continuación hay una explicación más completa:

Cuando todos los nodos en al menos un grupo de nodos está vivo, la partición de la red no es un problema, porque ninguna porción del cluster puede formar un cluster funcional. El problem real es cuando un grupo no tiene todos sus nodos vivos, en tal caso la partición de red (el escenario “split-brain” mencinado anteriormente) es posible. Cuando se necesita un árbitro, que normalmente es el servidor de administración; sin embargo, es posible configurar cualquier MySQL Server en el cluster para que actúe como el árbitro. El árbitro acepta el primer conjunto de nodos del cluster que contacten con el, y le dice al resto que mueran. La selección del árbitro se controla mediante el parámetro de configuración ArbitrationRank para los nodos MySQL Server y de administración. (Consulte Sección 16.4.4.4, “Definición del servidor de administración de MySQL Cluster” para más detalles.) Debe tener en cuenta que el rol de administrador no impone ninguna demanda en la máquina designada, y por lo tanto la máquina árbitro no necesita ser particularmente rápida o tener memoria extra para este propósito.

¿Qué tipos de columna soport MySQL Cluster?

MySQL Cluster soporta todos los tipos de columna MySQL usuales, con la excepción de los asocidados con las extensiones espaciales. (Consulte Capítulo 18, Extensiones espaciales de MySQL.) Además, hay algunas diferencias respecto a los índices cuando se usan con tablas NDB. Nota: En MySQL 5.0, las tablas Cluster (esto es, tablas creadas con ENGINE=NDBCLUSTER) tiene sólo registros de longitud fija. Esto significa que (por ejemplo, cada registro conteniendo una columna VARCHAR(255) necesitará 256 bytes de almacenamiento para esa columna, independientemente del tamaño de los datos almacenados. Este punto se arreglará en futuras versiones.

Consulte Sección 16.8, “Limitaciones conocidas de MySQL Cluster” para más información.

¿Cómo arranco y paro MySQL Cluster?

Es necesario arrancar cada nodo en el cluster por separado en el siguiente orden:

Cada uno de estos comandos debe ejecutarse en una shell de sistema en la máquina que contenga el nodo afectado. Puede verificar que el cluster está en ejecución arrancando el cliente de administración MGM . ndb_mgm en la máquina con el nodo MGM.

¿Qué ocurre a los datos del cluster cuando el cluster se para?

Los datos en memoria de los nodos de datos se escriben en disco, y se recargan en memoria la siguiente vez que se inicia el cluster.

Para parar el cluster, introduzca lo siguiente en una shell en la máquina del nodo MGM:

shell> ndb_mgm -e shutdown

Esto hace que ndb_mgm, ndb_mgm, y cualquier proceso ndbd termina correctamente. MySQL servers corriendo como nodos Cluster SQL pueden pararse usando mysqladmin shutdown.

Para más información, consulte Sección 16.6.1, “Comandos del cliente de administración” y Sección 16.3.6, “Apagado y encendido seguros”.

¿Es útil tener más de un nodo de administración para el cluster?

Puede ser útil para ser más seguro. Sólo un nodo MGM controla el cluster en un momento dado, pero es posible configurar un MGM como primario, y otro o más nodos adicionales para tomar el control en caso de fallo del nodo MGM primario.

¿Puedo mezclar hardware y sistemas operativos distintos en un Cluster?

Sí, mientras todas las máquinas y sistemas operativos tengan la misma endian. Es posible usar distintas versiones de MySQL Cluster en nodos distintos; sin embargo, recomendamos que esto se haga sólo como parte del procedimiento de actualización.

¿Puedo ejecutar dos nodos de datos en una misma máquina? ¿Dos nodos SQL?

Sí. En el caso de múltiples nodos de datos, cada nodo debe usar un directorio de datos distinto. Si quiere ejectuar múltiples nodos SQL en una máquina, entonces cada instancia de mysqld debe usar un puerto TCP/IP distinto.

¿Puedo usar nombres de equipo con MySQL Cluster?

Sí, es posible usar DNS y DHCP para equipos del cluster. Sin embargo, si su aplicación necesita disponibilidad de "cinco nueves", recomendamos usar direcciones IP fijas. Esto es porque hacer la comunicación entre equipos del cluster dependiente de estos servicios introduce puntos de fallo adicionales, y mientras menos haya, mejor.