From: jon
Date: April 27 2007 12:36am
Subject: svn commit - mysqldoc@docsrva: r6236 - trunk/ndbapi
List-Archive: http://lists.mysql.com/commits/25577
Message-Id: <200704270036.l3R0a0cG020755@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Author: jstephens
Date: 2007-04-27 02:35:59 +0200 (Fri, 27 Apr 2007)
New Revision: 6236
Log:
Reformat.
Modified:
trunk/ndbapi/ndb-internals.xml
Modified: trunk/ndbapi/ndb-internals.xml
===================================================================
--- trunk/ndbapi/ndb-internals.xml 2007-04-27 00:35:14 UTC (rev 6235)
+++ trunk/ndbapi/ndb-internals.xml 2007-04-27 00:35:59 UTC (rev 6236)
Changed blocks: 4, Lines Added: 1265, Lines Deleted: 804; 89746 bytes
@@ -765,358 +765,356 @@
-
-
- The NDB Protocol
+ The NDB Protocol
-
+
-
- This document discusses the protocol used for communication
- between data nodes and API nodes in an NDB Cluster to perform
- various operations such as data reads and writes, committing and
- rolling back transactions, and handling of transaction records.
-
+
+ This document discusses the protocol used for communication
+ between data nodes and API nodes in an NDB Cluster to perform
+ various operations such as data reads and writes, committing and
+ rolling back transactions, and handling of transaction records.
+
-
+
-
+
- <literal>NDB</literal> Protocol Overview
+ <literal>NDB</literal> Protocol Overview
-
- MySQL Cluster data and API nodes communicate with one another by
- passing messages to one another. The sending of a message from one
- node and its reception by another node is referred to as a
- signal; the NDB Protocol
- is the set of rules governing the format of these messages and the
- manner in which they are passed.
-
+
+ MySQL Cluster data and API nodes communicate with one another by
+ passing messages to one another. The sending of a message from
+ one node and its reception by another node is referred to as a
+ signal; the NDB
+ Protocol is the set of rules governing the format of these
+ messages and the manner in which they are passed.
+
-
- An NDB message is typically either a
- request or a
- response. A request indicates that an API
- node wants to perform an operation involving cluster data (such as
- retrieval, insertion, updating, or deletion) or trsansactions
- (commit, roll back, or to fetch or relase a transaction record). A
- request is, when necessary, accompanied by key or index
- information. The response sent by a data node to this request
- indicates whether or not the request succeeded and, where
- appropriate, is accompanied by one or more data messages.
-
+
+ An NDB message is typically either a
+ request or a
+ response. A request indicates that an API
+ node wants to perform an operation involving cluster data (such
+ as retrieval, insertion, updating, or deletion) or trsansactions
+ (commit, roll back, or to fetch or relase a transaction record).
+ A request is, when necessary, accompanied by key or index
+ information. The response sent by a data node to this request
+ indicates whether or not the request succeeded and, where
+ appropriate, is accompanied by one or more data messages.
+
-
+
- Request types
+ Request types
-
- A request is represented as a REQ message.
- Requests can be divided into those handling data and those
- handling transactions:
+
+ A request is represented as a REQ message.
+ Requests can be divided into those handling data and those
+ handling transactions:
-
+
-
-
+
+
- Data requests
+ Data requests
-
- Data request operations are of three principal types:
+
+ Data request operations are of three principal types:
-
+
-
-
+
+
- Primary key lookup operations
+ Primary key lookup operations
-
- These are performed through the exchange of
- TCKEY messages.
-
+
+ These are performed through the exchange of
+ TCKEY messages.
+
-
-
+
+
-
-
+
+
- Unique key lookup operations
+ Unique key lookup operations
-
- These are performed through the exchange of
- TCINDX messages.
-
+
+ These are performed through the exchange of
+ TCINDX messages.
+
-
-
+
+
-
-
+
+
- Table or index scan operations
+ Table or index scan operations
-
- These are performed through the exchange of
- SCANTAB messages.
-
+
+ These are performed through the exchange of
+ SCANTAB messages.
+
-
-
+
+
-
+
- Data request messages are often accompanied by
- KEYINFO messages,
- ATTRINFO messages, or both sorts of
- messages.
-
+ Data request messages are often accompanied by
+ KEYINFO messages,
+ ATTRINFO messages, or both sorts of
+ messages.
+
-
-
+
+
-
-
+
+
- Transactional requests
+ Transactional requests
-
- These may be divided into two categories:
+
+ These may be divided into two categories:
-
+
-
-
- Commits and rollbacks, which are represented by
- TC_COMMIT and
- TCROLLBACK request messages,
- respectively.
-
-
+
+
+ Commits and rollbacks, which are represented by
+ TC_COMMIT and
+ TCROLLBACK request messages,
+ respectively.
+
+
-
-
- Transaction record requests — that is,
- transaction record acquisition and release. These
- requests are handled through the use of,
- respectively, TCSEIZE and
- TCRELEASE request messages.
-
-
+
+
+ Transaction record requests — that is,
+ transaction record acquisition and release.
+ These requests are handled through the use of,
+ respectively, TCSEIZE and
+ TCRELEASE request messages.
+
+
-
-
+
+
-
-
+
+
-
-
+
+
-
+
-
+
- Response types
+ Response types
-
- A response indicates either the success or the failure of the
- request to which it is sent in reply:
+
+ A response indicates either the success or the failure of the
+ request to which it is sent in reply:
-
+
-
-
+
+
- Response indicating success
+ Response indicating success
-
- This type of response is represented as a
- CONF (confirmation) message, and is
- often accompanied by data, which is packaged as one or
- more TRANSID_AI messages.
-
+
+ This type of response is represented as a
+ CONF (confirmation) message, and is
+ often accompanied by data, which is packaged as one or
+ more TRANSID_AI messages.
+
-
-
+
+
-
-
+
+
- Response indicating failure
+ Response indicating failure
-
- This type of response is represented as a
- REF (refusal) message.
-
+
+ This type of response is represented as a
+ REF (refusal) message.
+
-
-
+
+
-
-
+
+
-
+
-
- These message types and their relationship to one another are
- discussed in more detail in
- .
-
+
+ These message types and their relationship to one another are
+ discussed in more detail in
+ .
+
-
+
-
+
- Message Naming Conventions and Structure
+ Message Naming Conventions and Structure
-
- This section describes the NDB Protocol message
- types and their structures.
-
+
+ This section describes the NDB Protocol
+ message types and their structures.
+
-
+
- Naming Conventions
+ Naming Conventions
-
- Message names are constructed according to a simple pattern
- which should be readily apparent from the discussion of request
- and response types in the previous section. These are shown in
- the following matrix:
+
+ Message names are constructed according to a simple pattern
+ which should be readily apparent from the discussion of
+ request and response types in the previous section. These are
+ shown in the following matrix:
-
-
-
-
-
-
-
-
- Operation Type
- Request (REQ)
- Response/Success
- (CONF)
- Response/Failure
- (REF)
-
-
- Primary Key Lookup
- (TCKEY)
- TCKEYREQ
- TCKEYCONF
- TCKEYREF
-
-
- Unique Key Lookup
- (TCINDX)
- TCINDXREQ
- TCINDXCONF
- TCINDXREF
-
-
- Table or Index Scan
- (SCANTAB)
- SCANTABREQ
- SCANTABCONF
- SCANTABREF
-
-
- Result Retrieval
- (SCAN_NEXT)
- SCAN_NEXTREQ
- SCANTABCONF
- SCANTABREF
-
-
- Transaction Record Acquisition
- (TCSEIZE)
- TCSEIZEREQ
- TCSEIZECONF
- TCSEIZEREF
-
-
- Transaction Record Release
- (TCRELEASE)
- TCRELEASEREQ
- TCRELEASECONF
- TCRELEASEREF
-
-
-
-
+
+
+
+
+
+
+
+
+ Operation Type
+ Request (REQ)
+ Response/Success
+ (CONF)
+ Response/Failure
+ (REF)
+
+
+ Primary Key Lookup
+ (TCKEY)
+ TCKEYREQ
+ TCKEYCONF
+ TCKEYREF
+
+
+ Unique Key Lookup
+ (TCINDX)
+ TCINDXREQ
+ TCINDXCONF
+ TCINDXREF
+
+
+ Table or Index Scan
+ (SCANTAB)
+ SCANTABREQ
+ SCANTABCONF
+ SCANTABREF
+
+
+ Result Retrieval
+ (SCAN_NEXT)
+ SCAN_NEXTREQ
+ SCANTABCONF
+ SCANTABREF
+
+
+ Transaction Record Acquisition
+ (TCSEIZE)
+ TCSEIZEREQ
+ TCSEIZECONF
+ TCSEIZEREF
+
+
+ Transaction Record Release
+ (TCRELEASE)
+ TCRELEASEREQ
+ TCRELEASECONF
+ TCRELEASEREF
+
+
+
+
- CONF and REF are shorthand
- for confirmed
and refused
,
- respectively.
-
+ CONF and REF are
+ shorthand for confirmed
and
+ refused
, respectively.
+
-
+
-
- Three additional types of messages are used in some instances of
- inter-node communication. These message types are:
+
+ Three additional types of messages are used in some instances of
+ inter-node communication. These message types are:
-
+
-
-
- A KEYINFO message contains information
- about the key used in a TCKEYREQ or
- TCINDXREQ message. It is employed when
- the key data does not fit within the request message.
- KEYINFO messages are also sent for index
- scan operations in which bounds are employed.
-
-
+
+
+ A KEYINFO message contains information
+ about the key used in a TCKEYREQ or
+ TCINDXREQ message. It is employed when
+ the key data does not fit within the request message.
+ KEYINFO messages are also sent for
+ index scan operations in which bounds are employed.
+
+
-
-
- An ATTRINFO message contains non-key
- attribute values which does not fit within a
- TCKEYREQ, TCINDXREQ,
- or SCANTABREQ message. It is used for:
+
+
+ An ATTRINFO message contains non-key
+ attribute values which does not fit within a
+ TCKEYREQ, TCINDXREQ,
+ or SCANTABREQ message. It is used for:
-
+
-
-
- Supplying attribute values for inserts and updates
-
-
+
+
+ Supplying attribute values for inserts and updates
+
+
-
-
- Designating which attributes are to be read for read
- operations
-
-
+
+
+ Designating which attributes are to be read for read
+ operations
+
+
-
-
- Specifying optional values to read for delete
- operations
-
-
+
+
+ Specifying optional values to read for delete
+ operations
+
+
-
-
-
+
+
+
-
-
- A TRANSID_AI message contains data
- returned from a read operation — in other words, it is
- a result set (or part of one).
-
-
+
+
+ A TRANSID_AI message contains data
+ returned from a read operation — in other words, it
+ is a result set (or part of one).
+
+
-
-
+
+
-
+
-
+
- Operations and Signals
+ Operations and Signals
-
- In this section we discuss the sequence of message-passing that
- takes place between a data node and an API node for each of the
- following operations:
+
+ In this section we discuss the sequence of message-passing that
+ takes place between a data node and an API node for each of the
+ following operations:
-
+
-
-
- Primary key lookup
-
-
+
+
+ Primary key lookup
+
+
-
-
- Unique key lookup
-
-
+
+
+ Unique key lookup
+
+
-
-
- Table scan or index scan
-
-
+
+
+ Table scan or index scan
+
+
-
-
- Explicit commit of a transaction
-
-
+
+
+ Explicit commit of a transaction
+
+
-
-
- Rollback of a transaction
-
-
+
+
+ Rollback of a transaction
+
+
-
-
- Transaction record handling (acquisition and release)
-
-
+
+
+ Transaction record handling (acquisition and release)
+
+
-
-
+
+
-
+
- Primary key lookup
+ Primary key lookup
-
- An operation using a primary key lookup is performed shown in
- the following diagram:
+
+ An operation using a primary key lookup is performed shown in
+ the following diagram:
-
-
-
-
-
- Messages exchanged in a primary key
- lookup
-
-
+
+
+
+
+
+ Messages exchanged in a primary key
+ lookup
+
+
-
-
- * and
- + are used here with the
- meanings zero or more
and one or
- more
, respectively.
-
-
+
+
+ * and
+ + are used here with the
+ meanings zero or more
and one or
+ more
, respectively.
+
+
- This process is explained is greater detail here:
+ This process is explained is greater detail here:
-
+
-
-
- The API node sends a TCKEYREQ message
- to the data node. In the event that the necessary
- information about the key to be used is too large to be
- contained in the TCKEYREQ, the message
- may be accompanied by any number of
- KEYINFO messages carrying the remaining
- key information. If additional attributes are used for the
- operation and exceed the space available in the
- TCKEYREQ, or if data is to be sent to
- the data node as part of a write operation, then these are
- sent with the TCKEYREQ as any number of
- ATTRINFO messages.
-
-
+
+
+ The API node sends a TCKEYREQ message
+ to the data node. In the event that the necessary
+ information about the key to be used is too large to be
+ contained in the TCKEYREQ, the
+ message may be accompanied by any number of
+ KEYINFO messages carrying the
+ remaining key information. If additional attributes are
+ used for the operation and exceed the space available in
+ the TCKEYREQ, or if data is to be
+ sent to the data node as part of a write operation, then
+ these are sent with the TCKEYREQ as
+ any number of ATTRINFO messages.
+
+
-
-
- The data node then sends a message in response to the
- request:
+
+
+ The data node then sends a message in response to the
+ request:
-
+
-
-
- If the operation was successful, the data node sends
- a TCKEYCONF message to the API
- node. If the request was for a read operation, then
- TCKEYCONF is accompanied by a
- TRANSID_AI message, which
- contains actual result data. If there is more data
- than can be contained in a single
- TRANSID_AI can carry, more than
- one of these messages may be sent.
-
-
+
+
+ If the operation was successful, the data node
+ sends a TCKEYCONF message to
+ the API node. If the request was for a read
+ operation, then TCKEYCONF is
+ accompanied by a TRANSID_AI
+ message, which contains actual result data. If
+ there is more data than can be contained in a
+ single TRANSID_AI can carry,
+ more than one of these messages may be sent.
+
+
-
-
- If the operation failed, then the data node sends a
- TCKEYREF message back to the API
- node, and no more signalling takes place until the
- API node makes a new request.
-
-
+
+
+ If the operation failed, then the data node sends
+ a TCKEYREF message back to the
+ API node, and no more signalling takes place until
+ the API node makes a new request.
+
+
-
-
-
+
+
+
-
-
+
+
-
+
-
+
- Unique key lookup
+ Unique key lookup
-
- This is performed in a manner similar to that performed in a
- primary key lookup:
+
+ This is performed in a manner similar to that performed in a
+ primary key lookup:
-
+
-
-
- A request is made by the API node using a
- TCINDXREQ message which may be
- accompanied by zero or more KEYINFO
- messages, zero or more ATTRINFO
- messages, or both.
-
-
+
+
+ A request is made by the API node using a
+ TCINDXREQ message which may be
+ accompanied by zero or more KEYINFO
+ messages, zero or more ATTRINFO
+ messages, or both.
+
+
-
-
- The data node returns a response:
+
+
+ The data node returns a response:
-
+
-
-
- If the operation was a success, the message is
- TCINDXCONF. For a successful read
- operation, this message may be accompanied by one or
- more TRANSID_AI messages carrying
- the result data.
-
-
+
+
+ If the operation was a success, the message is
+ TCINDXCONF. For a successful
+ read operation, this message may be accompanied by
+ one or more TRANSID_AI messages
+ carrying the result data.
+
+
-
-
- If the operation failed, the data node returns a
- TCINDXREF message.
-
-
+
+
+ If the operation failed, the data node returns a
+ TCINDXREF message.
+
+
-
-
-
+
+
+
-
+
- The exchange of messages involved in a unique key lookup is
- illustrated here:
+ The exchange of messages involved in a unique key lookup is
+ illustrated here:
-
-
-
-
-
- Messages exchanged in a unique key
- lookup
-
-
-
+
+
+
+
+
+ Messages exchanged in a unique key
+ lookup
+
+
+
-
+
-
+
- Table scans and index scans
+ Table scans and index scans
-
- These are similar in many respects to primary key and unique key
- lookups, as shown here:
+
+ These are similar in many respects to primary key and unique
+ key lookups, as shown here:
-
-
-
-
-
- Messages exchanged for a table scan or
- index scan operation.
-
-
+
+
+
+
+
+ Messages exchanged for a table scan or
+ index scan operation.
+
+
-
+
-
-
- A request is made by the API node using a
- SCAN_TABREQ message, along with zero or
- more ATTRINFO messages.
- KEYINFO messages are also used with
- index scans in the event that bounds are used.
-
-
+
+
+ A request is made by the API node using a
+ SCAN_TABREQ message, along with zero
+ or more ATTRINFO messages.
+ KEYINFO messages are also used with
+ index scans in the event that bounds are used.
+
+
-
-
- The data node returns a response:
+
+
+ The data node returns a response:
-
+
-
-
- If the operation was a success, the message is
- SCAN_TABCONF. For a successful
- read operation, this message may be accompanied by
- one or more TRANSID_AI messages
- carrying the result data. However — unlike the
- case with lookups based on a primary or unique key
- — it is often necessary to fetch multiple
- results from the data node. Requests following the
- first are signalled by the API node using a
- SCAN_NEXTREQ, which tells the
- data node to send the next set of results (if there
- are more results). This is shown here:
+
+
+ If the operation was a success, the message is
+ SCAN_TABCONF. For a successful
+ read operation, this message may be accompanied by
+ one or more TRANSID_AI messages
+ carrying the result data. However — unlike
+ the case with lookups based on a primary or unique
+ key — it is often necessary to fetch
+ multiple results from the data node. Requests
+ following the first are signalled by the API node
+ using a SCAN_NEXTREQ, which
+ tells the data node to send the next set of
+ results (if there are more results). This is shown
+ here:
-
-
-
-
-
- Fetching multiple result data
- sets following a table or index scan read
- operation
-
-
-
-
+
+
+
+
+
+ Fetching multiple result
+ data sets following a table or index scan read
+ operation
+
+
+
+
-
-
- If the operation failed, the data node returns a
- SCAN_TABREF message.
-
+
+
+ If the operation failed, the data node returns a
+ SCAN_TABREF message.
+
-
- SCAN_TABREF is also used to
- signal to the API node that all data resulting from
- a read has been sent.
-
-
+
+ SCAN_TABREF is also used to
+ signal to the API node that all data resulting
+ from a read has been sent.
+
+
-
-
-
+
+
+
-
-
+
+
-
+
-
+
- Committing and rolling back transactions
+ Committing and rolling back transactions
-
- The process of performing an explicit commit follows the same
- general pattern as shown previously. The API node sends a
- TC_COMMITREQ message to the data node, which
- responds with either a TC_COMMITCONF (on
- success) or a TC_COMMITREF (if the commit
- failed). This is shown in the following diagram:
+
+ The process of performing an explicit commit follows the same
+ general pattern as shown previously. The API node sends a
+ TC_COMMITREQ message to the data node,
+ which responds with either a TC_COMMITCONF
+ (on success) or a TC_COMMITREF (if the
+ commit failed). This is shown in the following diagram:
-
-
-
-
-
- Messages exchanged in explicit commit
- operation
-
-
+
+
+
+
+
+ Messages exchanged in explicit commit
+ operation
+
+
-
-
- Some operations perform a COMMIT
- automatically, so this is not required for every
- transaction.
-
-
+
+
+ Some operations perform a COMMIT
+ automatically, so this is not required for every
+ transaction.
+
+
- Rolling back a transaction also follows this pattern. In this
- case, however, the API node sends a
- TCROLLBACKTREQ message to the data node.
- Either a TCROLLACKCONF or a
- TCROLLBACKREF is sent in response, as shown
- here:
+ Rolling back a transaction also follows this pattern. In this
+ case, however, the API node sends a
+ TCROLLBACKTREQ message to the data node.
+ Either a TCROLLACKCONF or a
+ TCROLLBACKREF is sent in response, as shown
+ here:
-
-
-
-
-
- Messages exchanged when rolling back a
- transaction
-
-
-
+
+
+
+
+
+ Messages exchanged when rolling back a
+ transaction
+
+
+
-
+
-
+
- Handling of transaction records
+ Handling of transaction records
-
- Acquiring a transaction record is accomplished when an API node
- transmits a TCSEIZEREQ message to a data node
- and receives a TCSEIZECONF or
- TCSEIZEREF in return, depending on whether or
- not the request was successful. This is depicted here:
+
+ Acquiring a transaction record is accomplished when an API
+ node transmits a TCSEIZEREQ message to a
+ data node and receives a TCSEIZECONF or
+ TCSEIZEREF in return, depending on whether
+ or not the request was successful. This is depicted here:
-
-
-
-
-
- Signals used in transaction record
- acquisition
-
-
+
+
+
+
+
+ Signals used in transaction record
+ acquisition
+
+
- The release of a transaction record is also handled using the
- request-response pattern. In this case, the API node's request
- contains a TCRELEASEREQ message, and the data
- node's response uses either a TCRELEASECONF
- (indicating that the record was released) or a
- TCRELEASEREF (indicating that the attempt at
- release did not succeed). This series of events is illustrated
- in the next diagram:
+ The release of a transaction record is also handled using the
+ request-response pattern. In this case, the API node's request
+ contains a TCRELEASEREQ message, and the
+ data node's response uses either a
+ TCRELEASECONF (indicating that the record
+ was released) or a TCRELEASEREF (indicating
+ that the attempt at release did not succeed). This series of
+ events is illustrated in the next diagram:
-
-
-
-
-
- Signals used in releasing a transaction
- record
-
-
-
+
+
+
+
+
+ Signals used in releasing a transaction
+ record
+
+
+
-
+
+
+
-
-
+
<literal>NDB</literal> Kernel Blocks
-
+
This section lists and describes the major kernel blocks found in
the NDB source code, under the directory
storage/ndb/src/kernel/blocks/.
-
+
[js] Using an itemizedlist for now, may want to promote list items
to (sub)sections as more information is added?
-
+
[js] I've omitted makefiles and SCCS subdirectories from the
- kernel block file listings.
+ kernel block file listings.
-
+
[js] Possibly remove .txt files from listings and incorporate
their content directly into this doc?
-
+
Alphabatise file listings within each block; add descriptions of
the code in each one and what it does.
-
+
+
+
<literal>BACKUP</literal>
+
- This block is responsible for handling online backups. It
- it is found in
+ This block is responsible for handling online backups. It it
+ is found in
storage/ndb/src/kernel/blocks/backup/,
and contains the following files:
-
+
+
- Backup.cpp
-
- BackupFormat.hpp
-
- Backup.hpp
-
- BackupInit.cpp
-
- Backup.txt
-
- FsBuffer.hpp
-
- read.cpp
-
+
+ Backup.cpp
+
+
+
+
+ BackupFormat.hpp
+
+
+
+
+
+ Backup.hpp
+
+
+
+
+
+ BackupInit.cpp
+
+
+
+
+
+ Backup.txt
+
+
+
+
+
+ FsBuffer.hpp
+
+
+
+
+
+ read.cpp
+
+
+
-
+
-
+
+
<literal>CMVMI</literal>
+
This block is responsible for configuration management
between the kernel blocks and the NDB
- virtual machine. It is found in storage/ndb/src/kernel/blocks/cmvmi, and
- contains these files:
+ virtual machine. It is found in
+ storage/ndb/src/kernel/blocks/cmvmi,
+ and contains these files:
+
+
- Cmvmi.cpp
+
+ Cmvmi.cpp
+
+
- Cmvmi.hpp
+
+ Cmvmi.hpp
+
+
-
+
-
+
+
<literal>DBACC</literal>
+
This is the access control and lock management module, found
in storage/ndb/src/kernel/blocks/dbacc.
It contains the following files:
+
+
- Dbacc.hpp
-
- DbaccInit.cpp
-
- DbaccMain.cpp
+
+ Dbacc.hpp
+
+
+
+
+ DbaccInit.cpp
+
+
+
+
+
+ DbaccMain.cpp
+
+
+
-
+
-
+
+
<literal>DBDICT</literal>
+
This block, found in
storage/ndb/src/kernel/blocks/dbdict,
manages metadata such as table and index definitions. This
block contains these files:
+
+
- CreateIndex.txt
-
- Dbdict.cpp
-
- DictLock.txt
-
- printSchemaFile.cpp
-
- Slave_AddTable.sfl
-
- CreateTable.new.txt
-
- Dbdict.hpp
-
- DropTable.txt
-
- CreateTable.txt
-
- Dbdict.txt
-
- Event.txt
-
- Master_AddTable.sfl
-
- SchemaFile.hpp
+
+ CreateIndex.txt
+
+
+
+
+ Dbdict.cpp
+
+
+
+
+
+ DictLock.txt
+
+
+
+
+
+ printSchemaFile.cpp
+
+
+
+
+
+ Slave_AddTable.sfl
+
+
+
+
+
+ CreateTable.new.txt
+
+
+
+
+
+ Dbdict.hpp
+
+
+
+
+
+ DropTable.txt
+
+
+
+
+
+ CreateTable.txt
+
+
+
+
+
+ Dbdict.txt
+
+
+
+
+
+ Event.txt
+
+
+
+
+
+ Master_AddTable.sfl
+
+
+
+
+
+ SchemaFile.hpp
+
+
+
-
+
-
+
+
<literal>DBLIH</literal>
+
This block provides data distribution management services.
It is responsible for maintaining data fragments and
replicas, handling of local and global checkpoints, and
manages system restarts. It contains the following files,
all found in the directory
- storage/ndb/src/kernel/blocks/dbdih:
+ storage/ndb/src/kernel/blocks/dbdih:
+
+
- Dbdih.hpp
+
+ Dbdih.hpp
+
+
- DbdihMain.cpp
+
+ DbdihMain.cpp
+
+
- printSysfile/printSysfile.cpp
+
+ printSysfile/printSysfile.cpp
+
+
- DbdihInit.cpp
+
+ DbdihInit.cpp
+
+
- LCP.txt
+
+ LCP.txt
+
+
- printSysfile.cpp
+
+ printSysfile.cpp
+
+
- Sysfile.hpp
+
+ Sysfile.hpp
+
+
-
+
-
+
+
<literal>DBLQH</literal>
+
This is the local query handler block, which manages data
and transactions local to the cluster's data nodes. It
ismade up of the following files, found in
storage/ndb/src/kernel/blocks/dblqh:
-
+
+
- Dblqh.hpp
+
+ Dblqh.hpp
+
+
- DblqhInit.cpp
+
+ DblqhInit.cpp
+
+
- DblqhMain.cpp
+
+ DblqhMain.cpp
+
+
- redoLogReader/records.cpp
+
+ redoLogReader/records.cpp
+
+
- redoLogReader/records.hpp
+
+ redoLogReader/records.hpp
+
+
- redoLogReader/redoLogFileReader.cpp
+
+ redoLogReader/redoLogFileReader.cpp
+
+
-
+
-
+
+
<literal>DBTC</literal>
+
This is the transaction coordinator block, which handles
distributed transactions and other data operations on a
global level. In the source code, it is located in the
directory
- storage/ndb/src/kernel/blocks/dbtc, which contains these files:
+ storage/ndb/src/kernel/blocks/dbtc,
+ which contains these files:
+
+
- Dbtc.hpp
+
+ Dbtc.hpp
+
+
- DbtcInit.cpp
+
+ DbtcInit.cpp
+
+
- DbtcMain.cpp
+
+ DbtcMain.cpp
+
+
-
+
-
+
+
<literal>DBTUP</literal>
+
This is the tuple manager, which manages the physical
storage of cluster data. It consists of the the following
files found in the directory
- storage/ndb/src/kernel/blocks/dbtup:
+ storage/ndb/src/kernel/blocks/dbtup:
+
+
- AttributeOffset.hpp
+
+ AttributeOffset.hpp
+
- DbtupDiskAlloc.cpp
+
+
+
+ DbtupDiskAlloc.cpp
+
- DbtupIndex.cpp
+
+
+
+ DbtupIndex.cpp
+
- DbtupScan.cpp
+
+
+
+ DbtupScan.cpp
+
- tuppage.cpp
+
+
+
+ tuppage.cpp
+
- DbtupAbort.cpp
+
+
+
+ DbtupAbort.cpp
+
- DbtupExecQuery.cpp
+
+
+
+ DbtupExecQuery.cpp
+
- DbtupMeta.cpp
+
+
+
+ DbtupMeta.cpp
+
- DbtupStoredProcDef.cpp
+
+
+
+ DbtupStoredProcDef.cpp
+
- tuppage.hpp
+
+
+
+ tuppage.hpp
+
- DbtupBuffer.cpp
+
+
+
+ DbtupBuffer.cpp
+
- DbtupFixAlloc.cpp
+
+
+
+ DbtupFixAlloc.cpp
+
- DbtupPageMap.cpp
+
+
+
+ DbtupPageMap.cpp
+
- DbtupTabDesMan.cpp
+
+
+
+ DbtupTabDesMan.cpp
+
- Notes.txt
+
+
+
+ Notes.txt
+
- Undo_buffer.cpp
+
+
+
+ Undo_buffer.cpp
+
- DbtupCommit.cpp
+
+
+
+ DbtupCommit.cpp
+
- DbtupGen.cpp
+
+
+
+ DbtupGen.cpp
+
- DbtupPagMan.cpp
+
+
+
+ DbtupPagMan.cpp
+
- DbtupTrigger.cpp
+
+
+
+ DbtupTrigger.cpp
+
- Undo_buffer.hpp
+
+
+
+ Undo_buffer.hpp
+
- DbtupDebug.cpp
+
+
+
+ DbtupDebug.cpp
+
- Dbtup.hpp
+
+
+
+ Dbtup.hpp
+
- DbtupRoutines.cpp
+
+
+
+ DbtupRoutines.cpp
+
- DbtupVarAlloc.cpp
+
+
+
+ DbtupVarAlloc.cpp
+
- test_varpage.cpp
+
+
+
+ test_varpage.cpp
+
+
-
+
-
+
+
<literal>DBTUX</literal>
+
This kernel block handles the local management of ordered
indexes. It consists of the the following files found in the
storage/ndb/src/kernel/blocks/dbtux
- directory:
+ directory:
+
+
- DbtuxCmp.cpp
+
+ DbtuxCmp.cpp
+
+
- DbtuxGen.cpp
+
+ DbtuxGen.cpp
+
+
- DbtuxMaint.cpp
+
+ DbtuxMaint.cpp
+
+
- DbtuxNode.cpp
+
+ DbtuxNode.cpp
+
+
- DbtuxSearch.cpp
+
+ DbtuxSearch.cpp
+
+
- DbtuxTree.cpp
+
+ DbtuxTree.cpp
+
+
- Times.txt
+
+ Times.txt
+
+
- DbtuxDebug.cpp
+
+ DbtuxDebug.cpp
+
+
- Dbtux.hpp
+
+ Dbtux.hpp
+
+
- DbtuxMeta.cpp
+
+ DbtuxMeta.cpp
+
+
- DbtuxScan.cpp
+
+ DbtuxScan.cpp
+
+
- DbtuxStat.cpp
+
+ DbtuxStat.cpp
+
+
- tuxstatus.html
+
+ tuxstatus.html
+
+
-
+
-
+
+
<literal>DBUTIL</literal>
+
This block provides internal interfaces to transaction and
data operations. It is found in
storage/ndb/src/kernel/blocks/dbutil,
and includes these files:
+
+
- DbUtil.cpp
+
+ DbUtil.cpp
+
+
- DbUtil.hpp
+
+ DbUtil.hpp
+
+
- DbUtil.txt
+
+ DbUtil.txt
+
+
-
+
-
+
+
<literal>NDBCNTR</literal>
+
This is a cluster management block that handles block
initialisation and configuration. It is located in
storage/ndb/src/kernel/blocks/ndbcntr,
- and contains these files:
+ and contains these files:
+
+
- Ndbcntr.hpp
+
+ Ndbcntr.hpp
+
+
- NdbcntrInit.cpp
+
+ NdbcntrInit.cpp
+
+
- NdbcntrMain.cpp
+
+ NdbcntrMain.cpp
+
+
- NdbcntrSysTable.cpp
+
+ NdbcntrSysTable.cpp
+
+
-
+
-
+
+
<literal>NDBFS</literal>
+
This block provides the NDB filesystem
abstraction layer, and is located in the directory
storage/ndb/src/kernel/blocks/ndbfs,
which contains the following files:
+
+
- AsyncFile.cpp
+
+ AsyncFile.cpp
+
+
- CircularIndex.cpp
+
+ CircularIndex.cpp
+
+
- Filename.hpp
+
+ Filename.hpp
+
+
- MemoryChannelTest/MemoryChannelTest.cpp
+
+ MemoryChannelTest/MemoryChannelTest.cpp
+
+
- OpenFiles.hpp
+
+ OpenFiles.hpp
+
+
- VoidFs.cpp
+
+ VoidFs.cpp
+
+
- AsyncFile.hpp
+
+ AsyncFile.hpp
+
+
- CircularIndex.hpp
+
+ CircularIndex.hpp
+
+
- MemoryChannel.cpp
+
+ MemoryChannel.cpp
+
+
- Ndbfs.cpp
+
+ Ndbfs.cpp
+
+
- Pool.hpp
+
+ Pool.hpp
+
+
- AsyncFileTest/AsyncFileTest.cpp
+
+ AsyncFileTest/AsyncFileTest.cpp
+
+
- Filename.cpp
+
+ Filename.cpp
+
+
- MemoryChannel.hpp
+
+ MemoryChannel.hpp
+
+
- Ndbfs.hpp
+
+ Ndbfs.hpp
+
+
-
+
-
+
+
<literal>QMGR</literal>
+
This is the logical cluster management block, and handles
node membership in the cluster. It contains the following
files, found in
- storage/ndb/src/kernel/blocks/qmgr;
+ storage/ndb/src/kernel/blocks/qmgr;
+
+
- Qmgr.hpp
+
+ Qmgr.hpp
+
+
- QmgrInit.cpp
+
+ QmgrInit.cpp
+
+
- QmgrMain.cpp
+
+ QmgrMain.cpp
+
+
- timer.hpp
+
+ timer.hpp
+
+
-
+
-
+
+
<literal>SUMA</literal>
+
The cluster subscription manager, which handles event
logging and reporting functions. It consists of the
following files, found in the directory
storage/ndb/src/kernel/blocks/suma/:
+
+
- Suma.cpp
+
+ Suma.cpp
+
+
- Suma.hpp
+
+ Suma.hpp
+
+
- SumaInit.cpp
+
+ SumaInit.cpp
+
+
- Suma.txt
+
+ Suma.txt
+
+
-
+
-
+
+
<literal>TRIX</literal>
+
This kernel block is responsible for the building of unique
indexes. It is found in the directory
storage/ndb/src/kernel/blocks/trix, and
includes these files:
+
+
- Trix.cpp
+
+ Trix.cpp
+
+
- Trix.hpp
+
+ Trix.hpp
+
+
-
+
-
+
-
+
In addition, the following files are found in the
storage/ndb/src/kernel/blocks directory:
-
+
+
diskpage.cpp
-
-
- pgman.cpp
-
-
+
+ pgman.cpp
+
+
+
+
+
restore.cpp
+
SystemRestart.new.txt
+
diskpage.hpp
+
pgman.hpp
+
restore.hpp
+
SystemRestart.txt
+
ERROR_codes.txt
+
NodeRestart.new.txt
+
print_file.cpp
+
lgman.cpp
+
mutexes.hpp
+
NodeRestart.txt
+
Start.txt
+
tsman.cpp
+
lgman.hpp
+
OptNR.txt
+
record_types.hpp
+
tsman.hpp
+
-
-
+
-
-
+
-
+
<literal>NDB</literal> Internals Glossary
-
+
This section contains terms and abbreviations that are found in or
useful to understanding the NDB source code.
-
+
-
+
ACC
-
+
ACCelerator or
ACCess manager. Handles hash
indexes of primary keys, providing fast access to records.
-
+
DBTC
-
+
The transaction coordinator.
-
+
DIH
-
+
-
+
LQH
-
+
Local
Query
Handler.
-
+
SUMA
-
+
SUbscription
MAnager.
-
+
TC
-
+
Transaction
Co-ordinator
-
+
Tsman
-
+
Tablespace
@@ -2307,18 +2767,18 @@
role="bold">manager.
-
+
TUP
-
+
TUPle. Unit of data storage.
-
-
-
+
-
+
+