No se soportan todos los conjuntos de caracteres y colaciones.

No hay índices prefijo; sólo los campos completos pueden indexarse.

Los índices de texto no están soportados.

Tipos de datos geométricos (WKT y WKB) no soportados.

No hay rollback parcial de transacciones. Una clave duplicada o error similar resultará en un rollback de la transacción completa.

Existen un número de límites de hard que son configurables, pero la memoria disponible en el cluster delimite al límite. Consulte la lista completa de parámetros de configuración en Sección 16.4.4, “Fichero de configuración”. La mayoría de parámetros de configuración pueden actualizarse en línea. Estos límites de hard incluyen:

Los nombres de bases de datos, tablas y atributos no pueden ser tan largos en NDB como con otros motores. Los nombres de atributos se truncan a 31 caracteres, y si no son únicos tras truncarse da lugar a error. Los nombres de base de datos y de tabla pueden tener en total un máximo de 122 caracteres. (Esto es, la longitud máxima para un nombre de tabla en un cluster NDB es 122 caracteres menos el número de caracteres en el nombre de la base de datos de la tabla.)

En MySQL 4.1 y 5.0, todos los registros de tabla de Cluster son de longitud fija. Esto significa (por ejemplo) que si una tabla tiene uno o más campos VARCHAR conteniendo sólo valores pequeños, serán necesarios más memoria y espacio de disco al usar el motor NDB que el que sería para la misma tabla y datos usando el motor MyISAM. Estamos trabajando para rectificar este punto en MySQL 5.1.

El máximo número de objetos de metadatos está limitado a 1600, incluyendo tablas de base de datos, tablas de sistema, índices y BLOBs. Estamos trabajando para incrementar esto a aproximadamente 20k en MySQL 5.0.

El máximo número de atributos por tabla está limitado a 128.

El tamaño máximo permitido de registro es 8k, sin incluir datos almacenados en columnas BLOB. Esperamos incrementar esto a aproximadamente 32k en MySQL 5.1.

El máximo número de atributos por clave es 32.

El constructor de clave primaria se ignora, como en tablas MyISAM .

Los puntos de chequeo y rollbacks se ignoran como en MyISAM.

La caché de consulta está desactivada, ya que no está invalidad si ocurre una actualización en distintos servidores MySQL.

Hay temas de rendimiento de consulta debido a acceso secuencial al motor NDB; también es relativamente más costoso hacer varios escaneos de rango que con MyISAM o InnoDB.

La estadística Records in range no está soportada, resultando en planes de consulta no óptimos en algunos casos. Use USE INDEX o FORCE INDEX como solución.

Índices hash únicos creados con USING HASH no pueden usarse para acceder a una tabla si NULL se da como parte de la clave.

El único nivel de isolación soportado es READ_COMMITTED. (InnoDB soporta READ_COMMITTED, REPEATABLE_READ, y SERIALIZABLE.) Consulte Sección 16.6.4.5, “Resolver problemas con copias de seguridad” para información sobre cómo puede afectar a las copias de seguridad y restauración de bases de datos Cluster.

Commits no durables en disco. Los commits se replican, pero no hay garantía que los logs se vuelquen a disco en un commit.

ALTER TABLE no es completamente bloqueante cuando se ejecutan múltiples MySQL servers (no hay bloqueo de tabla distribuído).

La replicación MySQL no funcionará correctamente si las acutalizaciones se hacen en múltiples MySQL servers. Sin embargo, si el esquema de particionado de la base de datos es en nivel de aplicación, y no hay transacciones entre estas particiones, la replicación puede funcionar.

El autodescubrimiento de bases de datos no se soporta para múltiples MySQL servers accediendo al mismo MySQL Cluster. Sin embargo, el autodescubrimiento de tablas se soporta en estos casos. Lo que significa que si tras una base de datos llamada db_name se crea o importa usando un MySQL server, debe ejecutar un CREATE DATABASE db_name; en cada MySQL server adicional que accede al mismo MySQL Cluster. (Desde MySQL 5.0.2 puede usar CREATE SCHEMA db_name;.) Una vez hecho esto para un MySQL server dado, el servidor debería ser capaz de detectar las tablas de la base de datos sin error.

Todas las máquinsa usadas en el cluster deben tener la misma arquitectura; esto es, todas las máquinas con nodos deben ser o big-endian o little-endian, y no puede usar una mezcla. Por ejemplo, no puede tener un nodo de administración ejecutándose en un PPC con un nodo datos en una máquina x86 . Esta restricción no se aplica a máquinas que ejecuten sólo mysql u otros clientes que puedan estar accediendo a los nodos SQL del cluster.

No es posible hacer cambios del esquema en línea tales como los realizados usando ALTER TABLE o CREATE INDEX, ya que NDB Cluster no soporta autodescubrimiento de tales cambios. (Sin embargo, puede importar o crear una tabla que use distintos motores, convertirlos a NDB usando ALTER TABLE tbl_name ENGINE=NDBCLUSTER;. En tales casos, necesitará ejecutar un comando FLUSH TABLES para forzar al cluster a recoger los cambios.)

Añadir o eliminar nodos en línea no es posible (el cluster debe reiniciarse en tales casos).

Cuando se usan múltiples servidores de administración debe dar a los nodos explícitamente los IDs en los connectstrings ya que la reserva automática de IDs de nodo no funciona entre múltiples servidores de administración.

Usando varios servidores de administración debe tener cuidado de tener la misma configuración para todos los servidores de administración. El cluster no hace chequeos para ello.

El número máximo de nodos de datos es 48.

El número máximo de nodos en MySQL Cluster es 63. Este número incluye todos los MySQL Servers (nodos SQL), nodos de datos, y servidores de administración.