Code | Symbol | Kernel Block(s) |
data_node_id 2350
operation_filter + |
--- |
--- |
Description. Dumps all operations on a given data node or data nodes, according to the type and other parameters defined by the operation filter or filters specified.
Sample Output. Dump all operations on data node 2, from API node 5:
ndb_mgm> 2 DUMP 2350 1 5
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: Starting dump of operations
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: OP[470]:
Tab: 4 frag: 0 TC: 3 API: 5(0x8035)transid: 0x31c 0x3500500 op: SCAN state: InQueue
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: End of operation dump
Additional information.
Operation filter values. The operation filter (or filters) can take on the following values:
Value | Filter |
---|---|
0 | table ID |
1 | API node ID |
2 | 2 transaction IDs, defining a range of transactions |
3 | transaction coordinator node ID |
In each case, the ID of the object specified follows the specifier. See the sample output for examples.
Operation states. The “normal” states that may appear in the output from this command are listed here:
Transactions.
Prepared
.
The transaction coordinator is idle,
waiting for the API to proceed
Running
.
The transaction coordinator is
currently preparing operations
Committing
, Prepare to commit
,
Commit sent
.
The transaction coordinator is
committing
Completing
.
The transaction coordinator is
completing the commit (after commit,
some cleanup is needed)
Aborting
.
The transaction coordinator is
aborting the transaction
Scanning
.
The transaction coordinator is
scanning
Scan operations.
WaitNextScan
.
The scan is idle, waiting for API
InQueue
.
The scan has not yet started, but
rather is waiting in queue for other
scans to complete
Primary key operations.
In lock queue
.
The operation is waiting on a lock
Running
.
The operation is being prepared
Prepared
.
The operation is prepared, holding
an appropriate lock, and waiting for
commit or rollback to complete
Relation to NDB API.
It is possible to match the output of DUMP
2350
to specific threads or
Ndb
objects. First suppose that
you dump all operations on data node 2 from API node
5, using table 4 only, like this:
ndb_mgm> 2 DUMP 2350 1 5 0 4
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: Starting dump of operations
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: OP[470]:
Tab: 4 frag: 0 TC: 3 API: 5(0x8035)transid: 0x31c 0x3500500 op: SCAN state: InQueue
2006-10-09 13:16:49 [MgmSrvr] INFO -- Node 2: End of operation dump
Suppose you are working with an
Ndb
instance named
MyNdb
, to which this operation
belongs. You can see that this is the case by
calling the Ndb
object's
getReference()
method, like this:
printf("MyNdb.getReference(): 0x%x\n", MyNdb.getReference());
The output from the preceding line of code is:
MyNdb.getReference(): 0x80350005
The high 16 bits of the value shown corresponds to
the number in parentheses from the
OP
line in the
DUMP
command's output (8035). For
more about this method, see
Section 2.3.8.1.17, “Ndb::getReference()
”.
This command was added in MySQL Cluster NDB 6.1.12 and MySQL Cluster NDB 6.2.2.