MySQL NDB Cluster API Developer Guide

1.5 Application-level partitioning

There is no restriction against instantiating multiple Ndb_cluster_connection objects representing connections to different management servers in a single application, nor against using these for creating multiple instances of the Ndb class. Such Ndb_cluster_connection objects (and the Ndb instances based on them) are not required even to connect to the same cluster.

For example, it is entirely possible to perform application-level partitioning of data in such a manner that data meeting one set of criteria are handed off to one cluster using an Ndb object that makes use of an Ndb_cluster_connection object representing a connection to that cluster, while data not meeting those criteria (or perhaps a different set of criteria) can be sent to a different cluster through a different instance of Ndb that makes use of an Ndb_cluster_connection pointing to the second cluster.

It is possible to extend this scenario to develop a single application that accesses an arbitrary number of clusters. However, in doing so, the following conditions and requirements must be kept in mind:

Therefore, it is imperative in designing and implementing any application that accesses multiple clusters in a single session, that a separate set of Ndb_cluster_connection and Ndb objects be instantiated for connecting to each cluster management server, and that no confusion arises as to which of these is used to access which NDB Cluster.

It is also important to keep in mind that no direct sharing of data or data nodes between different clusters is possible. A data node can belong to one and only one cluster, and any movement of data between clusters must be accomplished on the application level.

For examples demonstrating how connections to two different clusters can be made and used in a single application, see Section 2.5.2, “NDB API Example Using Synchronous Transactions and Multiple Clusters”, and Section 3.6.2, “MGM API Event Handling with Multiple Clusters”.