Documentation Home
MySQL NDB Cluster 8.0
Related Documentation Download this Excerpt

MySQL NDB Cluster 8.0  /  ...  /  The ndbinfo locks_per_fragment Table

7.10.24 The ndbinfo locks_per_fragment Table

The locks_per_fragment table provides information about counts of lock claim requests, and the outcomes of these requests on a per-fragment basis, serving as a companion table to operations_per_fragment and memory_per_fragment. This table also shows the total time spent waiting for locks successfully and unsuccessfully since fragment or table creation, or since the most recent restart.

The following table provides information about the columns in the locks_per_fragment table. For each column, the table shows the name, data type, and a brief description. Additional information can be found in the notes following the table.

Table 7.37 Columns of the locks_per_fragment table

Column Name Type Description
fq_name string Fully qualified table name
parent_fq_name string Fully qualified name of parent object
type string Table type; see text for possible values
table_id integer Table ID
node_id integer Reporting node ID
block_instance integer LDM instance ID
fragment_num integer Fragment identifier
ex_req integer Exclusive lock requests started
ex_imm_ok integer Exclusive lock requests immediately granted
ex_wait_ok integer Exclusive lock requests granted following wait
ex_wait_fail integer Exclusive lock requests not granted
sh_req integer Shared lock requests started
sh_imm_ok integer Shared lock requests immediately granted
sh_wait_ok integer Shared lock requests granted following wait
sh_wait_fail integer Shared lock requests not granted
wait_ok_millis integer Time spent waiting for lock requests that were granted, in milliseconds
wait_fail_millis integer Time spent waiting for lock requests that failed, in milliseconds

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.

fq_name is a fully qualified database object name in database/schema/name format, such as test/def/t1 or sys/def/10/b$unique.

parent_fq_name is the fully qualified name of this object's parent object (table).

table_id is the table's internal ID generated by NDB. This is the same internal table ID shown in other ndbinfo tables; it is also visible in the output of ndb_show_tables.

The type column shows the type of table. This is always one of System table, User table, Unique hash index, Hash index, Unique ordered index, Ordered index, Hash index trigger, Subscription trigger, Read only constraint, Index trigger, Reorganize trigger, Tablespace, Log file group, Data file, Undo file, Hash map, Foreign key definition, Foreign key parent trigger, Foreign key child trigger, or Schema transaction.

The values shown in all of the columns ex_req, ex_req_imm_ok, ex_wait_ok, ex_wait_fail, sh_req, sh_req_imm_ok, sh_wait_ok, and sh_wait_fail represent cumulative numbers of requests since the table or fragment was created, or since the last restart of this node, whichever of these occurred later. This is also true for the time values shown in the wait_ok_millis and wait_fail_millis columns.

Every lock request is considered either to be in progress, or to have completed in some way (that is, to have succeeded or failed). This means that the following relationships are true:

ex_req >= (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)
sh_req >= (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

The number of requests currently in progress is the current number of incomplete requests, which can be found as shown here:

[exclusive lock requests in progress] =
    ex_req - (ex_req_imm_ok + ex_wait_ok + ex_wait_fail)
[shared lock requests in progress] =
    sh_req - (sh_req_imm_ok + sh_wait_ok + sh_wait_fail)

A failed wait indicates an aborted transaction, but the abort may or may not be caused by a lock wait timeout. You can obtain the total number of aborts while waiting for locks as shown here:

[aborts while waiting for locks] = ex_wait_fail + sh_wait_fail