Ouch... ce n'est pas comme ça que MySQL Cluster fonctionne.
Par défaut, MySQL Cluster partitionne les données sur la PRIMARY KEY. Il est cependant possible d'utiliser le partitionnement défini par l'utilisateur et le partitionnement sur une partie de la PRIMARY KEY. Ceci est extrêmement utile pour regrouper les données associées et pour garantir la localité des données au sein d'une partition. Étant donné que les données associées sont ensuite conservées dans une partition, il est alors possible de passer de 2 à 48 nœuds de données sans sacrifier les performances - elles seront constantes. Voir plus de détails sur http://dev.mysql.com/doc/refman/5.5/en/partitioning-key.html
Par défaut, l'API calculera un hachage (à l'aide de l'algorithme LH3*, qui utilise md5) sur la PRIMARY KEY (ou la partie définie utilisée de la clé primaire) pour déterminer à quelle partition envoyer une requête. Le hachage calculé est de 128 bits, et 64 bits déterminent la partition et 64 bits déterminent l'emplacement dans un index de hachage sur la partition. En tant qu'utilisateur, vous ne savez pas exactement quel nœud contient les données (ou qui stockera les données), mais en pratique, cela n'a pas vraiment d'importance.
En ce qui concerne la question initiale sur la distribution d'un cluster MySQL sur 2 clouds et le partitionnement des données. Les nœuds de données ont besoin d'un accès fiable à faible latence les uns aux autres, vous ne voudriez donc pas étendre les nœuds à moins qu'ils ne soient à moins de 50 à 100 miles les uns des autres.
