Ouch.. zo werkt MySQL Cluster niet.
Standaard verdeelt MySQL Cluster gegevens op de PRIMAIRE SLEUTEL. Het is echter mogelijk om door de gebruiker gedefinieerde partities en partities op een deel van de PRIMAIRE SLEUTEL te gebruiken. Dit is uitermate handig om gerelateerde gegevens te groeperen en om de lokaliteit van gegevens binnen één partitie te garanderen. Omdat gerelateerde gegevens vervolgens in één partitie worden bewaard, is het mogelijk om te schalen van 2 naar 48 gegevensknooppunten zonder prestatieverlies - het zal constant zijn. Zie meer details op http://dev.mysql.com/doc/refman/5.5/en/partitioning-key.html
Standaard berekent de API een hash (met behulp van het LH3*-algoritme, dat md5 gebruikt) op de PRIMAIRE SLEUTEL (of het gebruikte gedefinieerde deel van de primaire sleutel) om te bepalen naar welke partitie een query moet worden verzonden. De berekende hash is 128 bits en 64 bits bepaalt de partitie en 64 bits bepaalt de locatie in een hash-index op de partitie. Als gebruiker heb je niet precies het inzicht welke node de data heeft (of wie de data gaat opslaan), maar in de praktijk maakt het niet zoveel uit.
Wat betreft de oorspronkelijke vraag over het distribueren van één MySQL-cluster over 2 clouds en het partitioneren van gegevens. Data Nodes hebben betrouwbare low-latency-toegang tot elkaar nodig, dus je zou de nodes niet willen spreiden, tenzij ze minder dan 80-100 mijl van elkaar verwijderd zijn.