- 220.127.116.11 Ndb_cluster_connection Class Constructor
- 18.104.22.168 Ndb_cluster_connection::connect()
- 22.214.171.124 Ndb_cluster_connection::get_auto_reconnect()
- 126.96.36.199 Ndb_cluster_connection::get_latest_error()
- 188.8.131.52 Ndb_cluster_connection::get_latest_error_msg()
- 184.108.40.206 Ndb_cluster_connection::get_max_adaptive_send_time()
- 220.127.116.11 Ndb_cluster_connection::get_next_ndb_object()
- 18.104.22.168 Ndb_cluster_connection::get_num_recv_threads()
- 22.214.171.124 ndb_cluster_connection::lock_ndb_objects()
- 126.96.36.199 Ndb_cluster_connection::set_auto_reconnect()
- 188.8.131.52 Ndb_cluster_connection::set_data_node_neighbour()
- 184.108.40.206 Ndb_cluster_connection::set_max_adaptive_send_time()
- 220.127.116.11 Ndb_cluster_connection::set_name()
- 18.104.22.168 Ndb_cluster_connection::set_num_recv_threads()
- 22.214.171.124 Ndb_cluster_connection::set_optimized_node_selection()
- 126.96.36.199 Ndb_cluster_connection::set_timeout()
- 188.8.131.52 ndb_cluster_connection::unlock_ndb_objects()
- 184.108.40.206 Ndb_cluster_connection::wait_until_ready()
This class represents a connection to a cluster of data nodes.
Parent class. None
Child classes. None
An NDB application program should begin with the creation of a
Ndb_cluster_connection object, and
typically makes use of a single
Ndb_cluster_connection. The application
connects to a cluster management server when this object's
method is called. By using the
method it is possible to wait for the connection to reach one or
more data nodes.
An instance of
Ndb_cluster_connection used to
Ndb object. Prior to
NDB 7.3.8 and NDB 7.4.3, it was possible to delete the
Ndb_cluster_connection used to create a given
Ndb without first deleting the
Ndb object. (Bug #19999242)
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
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 (
Ndb_cluster_connectionobject “belongs” to a single management server whose host name or IP address is used in instantiating this object (passed as the
connection_stringargument to its constructor); once the object is created, it cannot be used to initiate a connection to a different management server.
Ndbobject 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
Ndbis bound to a specific
Ndb_cluster_connectionwhen created, and that
Ndb_cluster_connectionis in turn bound to a single and unique management server when it is instantiated.
The bindings described above persist for the lifetimes of the
Ndb_cluster_connectionobjects 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 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”.
Methods. The following table lists the public methods of this class and the purpose or use of each method:
|Method||Purpose / Use|
||Constructor; creates a connection to a cluster of data nodes.|
||Connects to a cluster management server.|
Gets the auto-reconnection setting for API nodes using
Whether or not the most recent attempt to connect succeeded.
If the most recent attempt to connect failed, provides the reason.
Get timeout before adaptive send forces the sending of all pending signals.
Get number of receive threads.
Used to iterate through multiple
Get activation level for bound receive threads.
Disables the creation of new
Enables or disables auto-reconnection of API nodes using
||Sets a neighbor node for for optimal transaction coordinator placement|
Set timeout to elapse before adaptive send forces the sending of all pending signals.
||Provides a name for the connection|
Set number of receive threads to be bound.
Set one or more CPUs to bind receive threads to.
||Used to control node-selection behavior.|
||Sets a connection timeout|
Enables the creation of new
Unset the binding of the receive thread to one or more CPUs.
||Waits until a connection with one or more data nodes is successful.|
This diagram shows all the available methods of the