- 8.2.3 DUMP Codes 2000 to 2999
- 8.2.3.1 DUMP 2300
- 8.2.3.2 DUMP 2301
- 8.2.3.3 DUMP 2302
- 8.2.3.4 DUMP 2303
- 8.2.3.5 DUMP 2304
- 8.2.3.6 DUMP 2305
- 8.2.3.7 DUMP 2308
- 8.2.3.8 DUMP 2315
- 8.2.3.9 DUMP 2350
- 8.2.3.10 DUMP 2352
- 8.2.3.11 DUMP 2398
- 8.2.3.12 DUMP 2399
- 8.2.3.13 DUMP 2400
- 8.2.3.14 DUMP 2401
- 8.2.3.15 DUMP 2402
- 8.2.3.16 DUMP 2403
- 8.2.3.17 DUMP 2404
- 8.2.3.18 DUMP 2405
- 8.2.3.19 DUMP 2406
- 8.2.3.20 DUMP 2500
- 8.2.3.21 DUMP 2501
- 8.2.3.22 DUMP 2502
- 8.2.3.23 DUMP 2503
- 8.2.3.24 DUMP 2504
- 8.2.3.25 DUMP 2505
- 8.2.3.26 DUMP 2506
- 8.2.3.27 DUMP 2507
- 8.2.3.28 DUMP 2508
- 8.2.3.29 DUMP 2509
- 8.2.3.30 DUMP 2510
- 8.2.3.31 DUMP 2511
- 8.2.3.32 DUMP 2512
- 8.2.3.33 DUMP 2513
- 8.2.3.34 DUMP 2514
- 8.2.3.35 DUMP 2515
- 8.2.3.36 DUMP 2550
- 8.2.3.37 DUMP 2600
- 8.2.3.38 DUMP 2601
- 8.2.3.39 DUMP 2602
- 8.2.3.40 DUMP 2603
- 8.2.3.41 DUMP 2604
| 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
2011-11-01 13:16:49 [MgmSrvr] INFO -- Node 2: Starting dump of operations
2011-11-01 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
2011-11-01 13:16:49 [MgmSrvr] INFO -- Node 2: End of operation dump
Additional information. Information about operation filter and operation state values follows.
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 proceedRunning: The transaction coordinator is currently preparing operationsCommitting,Prepare to commit,Commit sent: The transaction coordinator is committingCompleting: The transaction coordinator is completing the commit (after commit, some cleanup is needed)Aborting: The transaction coordinator is aborting the transactionScanning: The transaction coordinator is scanning
-
Scan operations:
WaitNextScan: The scan is idle, waiting for APIInQueue: 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 lockRunning: The operation is being preparedPrepared: 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
2011-11-01 13:16:49 [MgmSrvr] INFO -- Node 2: Starting dump of operations
2011-11-01 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
2011-11-01 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.14.1.12, “Ndb::getReference()”.
This command was added in MySQL Cluster NDB 6.1.12 and MySQL Cluster NDB 6.2.2.
