4.7 The DBLQH Block

This is the local, low-level query handler block, which manages data and transactions local to the cluster's data nodes, and acts as a coordinator of 2-phase commits. It is responsible (when called on by the transaction coordinator) for performing operations on tuples, accomplishing this task with help of DBACC block (which manages the index structures) and DBTUP (which manages the tuples). It is made up of the following files, found in storage/ndb/src/kernel/blocks/dblqh:

• Dblqh.hpp: Contains the Dblqh class definition. The code itself includes the following modules:

  • Start/Restart Module.  This module handles the following start phases:

    • Start phase 1.  Load block reference and processor ID

    • Start phase 2.  Initiate all records within the block; connect LQH with ACC and TUP

    • Start phase 4.  Connect each LQH with every other LQH in the database system. For an initial start, create the fragment log files. For a system restart or node restart, open the fragment log files and find the end of the log files.

  • Fragment addition and deletion module.  Used by the data dictionary to create new fragments and delete old fragments.

  • Execution module.  This module handles the reception of LQHKEYREQ messages and all processing of operations on behalf of this request. This also involves reception of various types of ATTRINFO and KEYINFO messages, as well as communications with ACC and TUP.

  • Log module.  The log module handles the reading and writing of the log. It is also responsible for handling system restarts, and controls system restart in TUP and ACC as well.

  • Transaction module.  This module handles the commit and completion phases.

  • TC failure module.  Handles failures in the transaction coordinator.

  • Scan module.  This module contains the code that handles a scan of a particular fragment. It operates under the control of the transaction coordinator and orders ACC to perform a scan of all tuples in the fragment. TUP performs the necessary search conditions to insure that only valid tuples are returned to the application.

  • Node recovery module.  This is used when a node has failed, copying the effected fragment to a new fragment replica. It also shuts down all connections to the failed node.

  • LCP module.  This module handles execution and control of local checkpoints in TUP and ACC. It also interacts with DIH to determine which global checkpoints are recoverable.

  • Global checkpoint module.  Assists DIH in discovering when GCPs are recoverable, and handles the GCP_SAVEREQ message requesting that LQH save a given GCP to disk and provide a notification of when this has been done.

  • File handling module.  This includes a number of sub-modules:

    • Signal reception

    • Normal operation

    • File change

    • Initial start

    • System restart, Phase 1

    • System restart, Phase 2

    • System restart, Phase 3

    • System restart, Phase 4

    • Error

• DblqhInit.cpp: Initialises Dblqh records and data. Also includes the Dblqh class destructor, used for deallocating these.

• DblqhMain.cpp: Implements Dblqh functionality (class methods).

• This directory also has the files listed here in a redoLogReader subdirectory containing the sources for the ndb_redo_log_reader utility:

  • records.cpp

  • records.hpp

  • redoLogFileReader.cpp

This block also handles redo logging, and helps oversee the DBACC, DBTUP, LGMAN, TSMAN, PGMAN, and BACKUP blocks. It is implemented as the class Dblqh, defined in the file storage/ndb/src/kernel/blocks/dblqh/Dblqh.hpp.

DBQLQH is a subtype of this block, used for query and recovery threads, added in NDB 8.0.23.