MySQL NDB Cluster API Developer Guide
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:
A cluster management server (ndb_mgmd) can
connect to one and only one cluster without being restarted
and reconfigured, as it must read the data telling it which
data nodes make up the cluster from a configuration file
(config.ini
).
An Ndb_cluster_connection
object
“belongs” to a single management server whose
host name or IP address is used in instantiating this object
(passed as the connection_string
argument to its constructor); once the object is created, it
cannot be used to initiate a connection to a different
management server.
An Ndb
object making use of
this connection (Ndb_cluster_connection
)
cannot be re-used to connect to a different cluster management
server (and thus to a different collection of data nodes
making up a cluster). Any given instance of
Ndb
is bound to a specific
Ndb_cluster_connection
when created, and
that Ndb_cluster_connection
is in turn
bound to a single and unique management server when it is
instantiated.
(See Ndb Class Constructor.)
The bindings previously described persist for the lifetimes of
the Ndb
and
Ndb_cluster_connection
objects in question.
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”.