The cluster_transactions table shows information about all ongoing transactions in an NDB Cluster.
The cluster_transactions table contains the following columns:
node_id
Node ID of transaction coordinator
block_instance
TC block instance
transid
Transaction ID
state
Operation state (see text for possible values)
count_operations
Number of stateful primary key operations in transaction (includes reads with locks, as well as DML operations)
outstanding_operations
Operations still being executed in local data management blocks
inactive_seconds
Time spent waiting for API
client_node_id
Client node ID
client_block_ref
Client block reference
The transaction ID is a unique 64-bit number which can be obtained using the NDB API's getTransactionId() method. (Currently, the MySQL Server does not expose the NDB API transaction ID of an ongoing transaction.)
block_instance refers to an instance of a kernel block. Together with the block name, this number can be used to look up a given instance in the threadblocks table.
The state column can have any one of the values CS_ABORTING, CS_COMMITTING, CS_COMMIT_SENT, CS_COMPLETE_SENT, CS_COMPLETING, CS_CONNECTED, CS_DISCONNECTED, CS_FAIL_ABORTED, CS_FAIL_ABORTING, CS_FAIL_COMMITTED, CS_FAIL_COMMITTING, CS_FAIL_COMPLETED, CS_FAIL_PREPARED, CS_PREPARE_TO_COMMIT, CS_RECEIVING, CS_REC_COMMITTING, CS_RESTART, CS_SEND_FIRE_TRIG_REQ, CS_STARTED, CS_START_COMMITTING, CS_START_SCAN, CS_WAIT_ABORT_CONF, CS_WAIT_COMMIT_CONF, CS_WAIT_COMPLETE_CONF, CS_WAIT_FIRE_TRIG_REQ. (If the MySQL Server is running with ndbinfo_show_hidden enabled, you can view this list of states by selecting from the ndb$dbtc_apiconnect_state table, which is normally hidden.)
In client_node_id and client_block_ref, client refers to an NDB Cluster API or SQL node (that is, an NDB API client or a MySQL Server attached to the cluster).
The tc_block_instance column provides the DBTC block instance number. You can use this along with the block name to obtain information about specific threads from the threadblocks table.