Ay... así no es como funciona MySQL Cluster.
Por defecto, MySQL Cluster divide los datos en PRIMARY KEY. Sin embargo, es posible utilizar particiones definidas por el usuario y particiones en parte de la CLAVE PRINCIPAL. Esto es extremadamente útil para agrupar datos relacionados y asegurar la ubicación de los datos dentro de una partición. Dado que los datos relacionados se mantienen en una partición, es posible escalar de 2 a 48 nodos de datos sin sacrificar el rendimiento; será constante. Vea más detalles en http://dev.mysql.com/doc/refman/5.5/en/partitioning-key.html
De forma predeterminada, la API calculará un hash (usando el algoritmo LH3*, que usa md5) en la CLAVE PRINCIPAL (o la parte definida usada de la clave principal) para determinar a qué partición enviar una consulta. El hash calculado es de 128 bits, y 64 bits determinan la partición y 64 bits determinan la ubicación en un índice hash en la partición. Como usuario, no tiene la idea exacta de qué nodo tiene los datos (o quién almacenará los datos), pero prácticamente no importa.
Con respecto a la pregunta original sobre la distribución de un MySQL Cluster en 2 nubes y la partición de datos. Los nodos de datos necesitan un acceso confiable de baja latencia entre sí, por lo que no querrá distribuir los nodos a menos que estén a menos de 50 a 100 millas entre sí.
