The default method is to select the transaction coordinator (TC) determined to be the "nearest" data node, using a heuristic for proximity based on the type of transporter connection. In order of nearest to most distant, these are:

If there are several connections available with the same proximity, one is selected for each transaction in a round-robin fashion. Optionally, you may set the method for TC selection to round-robin mode, where each new set of transactions is placed on the next data node. The pool of connections from which this selection is made consists of all available connections.

As noted in Section 1.3.3, “Review of MySQL Cluster Concepts”, the application programmer can provide hints to the NDB API as to which transaction coordinator should be uses. This is done by providing a table and a partition key (usually the primary key). If the primary key as the partition key, then the transaction is placed on the node where the primary replica of that record resides. Note that this is only a hint; the system can be reconfigured at any time, in which case the NDB API chooses a transaction coordinator without using the hint. For more information, see Section 2.3.1.2.16, “Column::getPartitionKey()”, and Section 2.3.8.1.8, “Ndb::startTransaction()”. The application programmer can specify the partition key from SQL by using this construct:

CREATE TABLE ... ENGINE=NDB PARTITION BY KEY (attribute_list);

For additional information, see Partitioning, and in particular KEY Partitioning, in the MySQL Manual.