ndbmtd is a multi-threaded version of
ndbd, the process that is used to handle
all the data in tables using the
NDBCLUSTER storage engine.
ndbmtd is intended for use on host
computers having multiple CPU cores. Except where otherwise
noted, ndbmtd functions in the same way as
ndbd; therefore, in this section, we
concentrate on the ways in which ndbmtd
differs from ndbd, and you should consult
Section 17.4.2, “ndbd — The MySQL Cluster Data Node Daemon”, for additional
information about running MySQL Cluster data nodes that apply
to both the single-threaded and multi-threaded versions of the
data node process.
Command-line options and configuration parameters used with ndbd also apply to ndbmtd. For more information about these options and parameters, see Section 17.4.2, “ndbd — The MySQL Cluster Data Node Daemon”, and Section 17.3.2.6, “Defining MySQL Cluster Data Nodes”, respectively.
ndbmtd is also file system-compatible with
ndbd. In other words, a data node running
ndbd can be stopped, the binary replaced
with ndbmtd, and then restarted without any
loss of data. (However, when doing this, you must make sure
that
MaxNoOfExecutionThreads
is set to an apppriate value before restarting the node if you
wish for ndbmtd to run in multi-threaded
fashion.) Similarly, an ndbmtd binary can
be replaced with ndbd simply by stopping
the node and then starting ndbd in place of
the multi-threaded binary. It is not necessary when switching
between the two to start the data node binary using
--initial.
Using ndbmtd differs from using ndbd in two key respects:
Because ndbmtd runs by default in
single-threaded mode (that is, it behaves like
ndbd), you must configure it to use
multiple threads. This can be done by setting an
appropriate value in the config.ini
file for the
MaxNoOfExecutionThreads
configuration parameter or (in MySQL Cluster NDB 7.2.3 and
later) the
ThreadConfig
configuration parameter. Using
MaxNoOfExecutionThreads is simpler, but
ThreadConfig offers more flexibility.
For more information about these configuration parameters
and their use, see
Multi-Threading Configuration Parameters (ndbmtd).
Trace files are generated by critical errors in ndbmtd processes in a somewhat different fashion from how these are generated by ndbd failures. These differences are discussed in more detail in the next few paragraphs.
Like ndbd, ndbmtd
generates a set of log files which are placed in the directory
specified by DataDir
in the config.ini configuration file.
Except for trace files, these are generated in the same way
and have the same names as those generated by
ndbd.
In the event of a critical error, ndbmtd
generates trace files describing what happened just prior to
the error' occurrence. These files, which can be found in
the data node's
DataDir, are useful
for analysis of problems by the MySQL Cluster Development and
Support teams. One trace file is generated for each
ndbmtd thread. The names of these files
have the following pattern:
ndb_node_id_trace.log.trace_id_tthread_id,
In this pattern, node_id stands for
the data node's unique node ID in the cluster,
trace_id is a trace sequence
number, and thread_id is the thread
ID. For example, in the event of the failure of an
ndbmtd process running as a MySQL Cluster
data node having the node ID 3 and with
MaxNoOfExecutionThreads
equal to 4, four trace files are generated in the data
node's data directory. If the is the first time this node
has failed, then these files are named
ndb_3_trace.log.1_t1,
ndb_3_trace.log.1_t2,
ndb_3_trace.log.1_t3, and
ndb_3_trace.log.1_t4. Internally, these
trace files follow the same format as ndbd
trace files.
The ndbd exit codes and messages that are
generated when a data node process shuts down prematurely are
also used by ndbmtd. See
ndbd Error Messages, for a listing of these.

User Comments
Add your own comment.