Documentation Home
MySQL 5.7 Reference Manual
Related Documentation Download this Manual
PDF (US Ltr) - 35.0Mb
PDF (A4) - 35.1Mb
Man Pages (TGZ) - 255.5Kb
Man Pages (Zip) - 360.4Kb
Info (Gzip) - 3.4Mb
Info (Zip) - 3.4Mb
Excerpts from this Manual

21.6.15.40 The ndbinfo tc_time_track_stats Table

The tc_time_track_stats table provides time-tracking information obtained from the DBTC block (TC) instances in the data nodes, through API nodes access NDB. Each TC instance tracks latencies for a set of activities it undertakes on behalf of API nodes or other data nodes; these activities include transactions, transaction errors, key reads, key writes, unique index operations, failed key operations of any type, scans, failed scans, fragment scans, and failed fragment scans.

A set of counters is maintained for each activity, each counter covering a range of latencies less than or equal to an upper bound. At the conclusion of each activity, its latency is determined and the appropriate counter incremented. tc_time_track_stats presents this information as rows, with a row for each instance of the following:

  • Data node, using its ID

  • TC block instance

  • Other communicating data node or API node, using its ID

  • Upper bound value

Notes

Each row contains a value for each activity type. This is the number of times that this activity occurred with a latency within the range specified by the row (that is, where the latency does not exceed the upper bound).

The tc_time_track_stats table contains the following columns:

  • node_id

    Requesting node ID

  • block_number

    TC block number

  • block_instance

    TC block instance number

  • comm_node_id

    Node ID of communicating API or data node

  • upper_bound

    Upper bound of interval (in microseconds)

  • scans

    Based on duration of successful scans from opening to closing, tracked against the API or data nodes requesting them.

  • scan_errors

    Based on duration of failed scans from opening to closing, tracked against the API or data nodes requesting them.

  • scan_fragments

    Based on duration of successful fragment scans from opening to closing, tracked against the data nodes executing them

  • scan_fragment_errors

    Based on duration of failed fragment scans from opening to closing, tracked against the data nodes executing them

  • transactions

    Based on duration of successful transactions from beginning until sending of commit ACK, tracked against the API or data nodes requesting them. Stateless transactions are not included.

  • transaction_errors

    Based on duration of failing transactions from start to point of failure, tracked against the API or data nodes requesting them.

  • read_key_ops

    Based on duration of successful primary key reads with locks. Tracked against both the API or data node requesting them and the data node executing them.

  • write_key_ops

    Based on duration of successful primary key writes, tracked against both the API or data node requesting them and the data node executing them.

  • index_key_ops

    Based on duration of successful unique index key operations, tracked against both the API or data node requesting them and the data node executing reads of base tables.

  • key_op_errors

    Based on duration of all unsuccessful key read or write operations, tracked against both the API or data node requesting them and the data node executing them.

The block_instance column provides the DBTC kernel block instance number. You can use this together with the block name to obtain information about specific threads from the threadblocks table.