Spec-Zone .ru
спецификации, руководства, описания, API
|
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.1, "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.1, "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 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