(mysql.info.gz) ndbd process

(mysql.info.gz) MySQL Cluster Process Management
 
 16.4.2 `ndbd', the Storage Engine Node Process
 ----------------------------------------------
 
 `ndbd' is the process that is used to handle all the data in the tables
 using the NDB Cluster storage engine. This is the process that contains
 all the logic of distributed transaction handling, node recovery,
 checkpointing to disk, online backup, and lots of other functionality.
 
 In a cluster there is a set of `ndbd' processes cooperating in handling
 the data. These processes can execute on the same computer or on
 different computers, in a completely configurable manner.
 
 Before MySQL 4.1.5, `ndbd' process should start from a separate
 directory. The reason for this was that `ndbd' generates a set of log
 files in its starting directory.
 
 In MySQL 4.1.5, this was changed such that the files are placed in the
 directory specified by `DataDir' in the configuration file. Thus `ndbd'
 can be started from anywhere.
 
 These log files are (the 2 is the node ID):
 
    * NDB_2_ERROR.LOG (was `error.log' in version 4.1.3) is a file that
      contains information of all the crashes which the `ndbd' process
      has encountered and a smaller error string and reference to a
      trace file for this crash. An entry could like this:
 
           Date/Time: Saturday 31 January 2004 - 00:20:01
           Type of error: error
           Message: Internal program error (failed ndbrequire)
           Fault ID: 2341
           Problem data: DbtupFixAlloc.cpp
           Object of reference: DBTUP (Line: 173)
           ProgramName: NDB Kernel
           ProcessID: 14909
           TraceFile: ndb_2_trace.log.2
           ***EOM***
 
    * `ndb_2_trace.log.1' (was `NDB_TraceFile_1.trace' in version 4.1.3)
      is a trace file describing exactly what happened before the error
      occurred. This information is useful for the MySQL Cluster team
      when analysing any bugs occurring in MySQL Cluster. The
      information in this file will be described in the section `MySQL
      Cluster Troubleshooting'. There can be a configurable number of
      those trace files in the directory before old files are
      overwritten. 1 in this context is simply the number of the trace
      file.
 
    * `ndb_2_trace.log.next' (was `NextTraceFileNo.log' in version
      4.1.3) is the file that keeps track of what the next trace file
      number is to be.
 
    * `ndb_2_out.log' is the file which contains any data printed by the
      `ndbd' process. 2 in this context is the node ID. (this file only
      applies if `ndbd' is started in daemon mode which is default from
      4.1.5, was `node2.out' in version 4.1.3)
 
    * `ndb_2.pid' is a file containing the process id of the ndbd when
      started as a daemon (default from 4.1.5 and named `node2.pid' in
      version 4.1.3). It also functions as a lock file to avoid the
      starting of nodes with the same id.
 
    * `ndb_2_signal.log' (was `Signal.log' in version 4.1.3) is a file
      which is only used in debug versions of `ndbd' where it is
      possible to trace all incoming, outgoing and internal messages
      with their data in the `ndbd' process.
 
 
 It is recommended to not use a directory mounted through NFS because in
 some environments that can cause problems with the lock on the pid-file
 remaining even after the process has stopped.
 
 Also when starting the `ndbd' process it may be necessary to specify
 the hostname of the management server and the port it is listening to,
 optionally one may specify node ID the process is to use, see 
 MySQL Cluster Connectstring.
 
      shell> ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"
 
 When `ndbd' starts it will actually start two processes. The starting
 process is called the "angel" and its only job is to discover when the
 execution process has completed, and then restart the `ndbd' process if
 configured to do so.  Thus if one attempts to kill `ndbd' through the
 `kill' command in Unix, it is necessary to kill both processes.  A more
 proper way to handle the stopping of `ndbd' processes is to use the
 management client and stop the process from there.
 
 The execution process uses one thread for all activities in reading,
 writing, and scanning data and all other activities. This thread is
 designed with asynchronous programming so it can easily handle
 thousands of concurrent activities. In addition there is a watch-dog
 thread supervising the execution thread to ensure it doesn't stop in an
 eternal loop or other problem. There is a pool of threads handling file
 I/O. Each thread can handle one open file. In addition threads can be
 used for connection activities of the transporters in the `ndbd'
 process. Thus in a system that performs a large number of activities
 including update activities the `ndbd' process will consume up to about
 2 CPUs if allowed to. Thus in a large SMP box with many CPUs it is
 recommended to use several `ndbd' processes which are configured to be
 part of different node groups.
Info Catalog
(mysql.info.gz) mysqld process
(mysql.info.gz) MySQL Cluster Process Management
(mysql.info.gz) ndb_mgmd process
automatically generated byinfo2html