Autsch... so funktioniert MySQL Cluster nicht.
Standardmäßig partitioniert MySQL Cluster Daten auf dem PRIMARY KEY. Es ist jedoch möglich, eine benutzerdefinierte Partitionierung und Partitionierung eines Teils des PRIMARY KEY zu verwenden. Dies ist äußerst nützlich, um zusammengehörige Daten zu gruppieren und die Lokalität von Daten innerhalb einer Partition sicherzustellen. Da zusammengehörige Daten dann in einer Partition gehalten werden, ist es dann möglich, ohne Leistungseinbußen von 2 auf 48 Datenknoten zu skalieren - sie bleibt konstant. Weitere Details finden Sie unter http://dev.mysql.com/doc/refman/5.5/en/partitioning-key.html
Standardmäßig berechnet die API einen Hash (unter Verwendung des LH3*-Algorithmus, der md5 verwendet) für den PRIMARY KEY (oder den verwendeten definierten Teil des Primärschlüssels), um zu bestimmen, an welche Partition eine Abfrage gesendet werden soll. Der berechnete Hash beträgt 128 Bit, und 64 Bit bestimmen die Partition und 64 Bit bestimmen die Position in einem Hash-Index auf der Partition. Als Benutzer haben Sie nicht genau die Einsicht, welcher Knoten die Daten hat (oder wer die Daten speichern wird), aber praktisch spielt es keine Rolle.
In Bezug auf die ursprüngliche Frage zum Verteilen eines MySQL-Clusters auf 2 Clouds und zum Partitionieren von Daten. Datenknoten benötigen einen zuverlässigen Zugriff mit geringer Latenzzeit, daher sollten Sie die Knoten nicht verteilen, es sei denn, sie sind weniger als 50–100 Meilen voneinander entfernt.
