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:
Primary key lookup operations are
performed through the exchange of
TCKEY messages.
Unique key lookup operations are
performed through the exchange of
TCINDX messages.
Table or index scan operations 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:
Commits and rollbacks, which are
represented by TC_COMMIT and
TCROLLBACK request messages,
respectively.
Transaction record requests,
consisting of transaction record acquisition and
release, 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:
A response indicating success is represented as a
CONF (confirmation) message, and is often
accompanied by data, which is packaged as one or more
TRANSID_AI messages.
A response indicating failure is represented as a
REF (refusal) message.
For more information about these message types and their relationship to one another, see Section 8.3.2, “Message Naming Conventions and Structure”.
© 2013, Oracle Corporation and/or its affiliates