Skip navigation links
6.3.2 Message Naming Conventions and Structure »
Section Navigation      [Toggle]

6.3.1. NDB 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.

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 transactions (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.  A request is represented as a REQ message. Requests can be divided into those handling data and those handling transactions:

  • Data requests.  Data request operations are of three principal types:

    1. Primary key lookup operations.  These are performed through the exchange of TCKEY messages.

    2. Unique key lookup operations.  These are performed through the exchange of TCINDX messages.

    3. Table or index scan operations.  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.

  • Transactional requests.  These may be divided into two categories:

    1. Commits and rollbacks, which are represented by TC_COMMIT and TCROLLBACK request messages, respectively.

    2. 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.  A response indicates either the success or the failure of the request to which it is sent in reply:

  • 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.

  • Response indicating failure.  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 Section 6.3.2, “Message Naming Conventions and Structure”.