Aj... det är inte så MySQL Cluster fungerar.
Som standard partitionerar MySQL Cluster data på PRIMÄRNYCKELN. Det är dock möjligt att använda användardefinierad partitionering och partition på en del av PRIMARY KEY. Detta är extremt användbart för att gruppera relaterade data tillsammans och för att säkerställa lokalisering av data inom en partition. Eftersom relaterad data sedan förvaras i en partition är det sedan möjligt att skala från 2 till 48 datanoder utan att offra prestanda - det kommer att vara konstant. Se mer information på http://dev.mysql.com/doc/refman/5.5/en/partitioning-key.html
Som standard kommer API:et att beräkna en hash (med LH3*-algoritmen, som använder md5) på PRIMÄRNYCKLEN (eller den använda definierade delen av primärnyckeln) för att bestämma vilken partition som ska skicka en fråga. Den beräknade hashen är 128 bitar, och 64 bitar bestämmer partitionen och 64 bitar bestämmer platsen i ett hashindex på partitionen. Som användare har du inte insikten exakt vilken nod som har data (eller vem som kommer att lagra data), men praktiskt taget spelar det ingen roll.
Angående den ursprungliga frågan om att distribuera ett MySQL-kluster över 2 moln och partitionera data. Datanoder behöver pålitlig åtkomst med låg latens till varandra, så du vill inte sprida ut noderna om de inte är mindre än 50-100 miles från varandra.