ndbinfo_select_all — Select From ndbinfo Tables ndb_ node_id _trace.log.next  file (see below). Error log entries are thus overwritten in a cyclical and not sequential fashion. •  ndb_ node_id _trace.log. trace_id  is a trace file describing exactly what happened just before the error occurred. This information is useful for analysis by the NDB Cluster development team. • ndb_ node_id _trace.log.next  is the file that keeps track of the next trace file number to be assigned. • ndb_ node_id _out.log  is a file containing any data output by the  ndbd  process. This file is created only if  ndbd  is started as a daemon, which is the default behavior. • ndb_ node_id .pid  is a file containing the process ID of the  ndbd  process when started as a daemon. It also functions as a lock file to avoid the starting of nodes with the same identifier. • ndb_ node_id _signal.log  is a file used only 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 possible to configure the number of these trace files that are created before old files are overwritten. trace_id  is a number which is incremented for each successive trace file. It is recommended not to use a directory mounted through NFS because in some environments this can cause problems whereby the lock on the  .pid  file remains in effect even after the process has terminated. To start  ndbd , it may also be necessary to specify the host name of the management server and the port on which it is listening. Optionally, one may also specify the node ID that the process is to use. See Section 23.3.3.3, “NDB Cluster Connection Strings” , for additional information about this issue. For more information about data node configuration parameters, see Section 23.3.3.6, “Defining NDB Cluster Data Nodes” . When  ndbd  starts, it actually initiates two processes. The first of these is called the “angel process” ; its only job is to discover when the execution process has been completed, and then to restart the  ndbd process if it is configured to do so. Thus, if you attempt to kill  ndbd  using the Unix  kill  command, it is necessary to kill both processes, beginning with the angel process. The preferred method of terminating an ndbd  process is to use the management client and stop the process from there. The execution process uses one thread for reading, writing, and scanning data, as well as all other activities. This thread is implemented asynchronously so that it can easily handle thousands of concurrent actions. In addition, a watch-dog thread supervises the execution thread to make sure that it does not hang in an endless loop. A pool of threads handles file I/O, with each thread able to handle one open file. Threads can also be used for transporter connections by the transporters in the  ndbd  process. In a multi- processor system performing a large number of operations (including updates), the  ndbd  process can consume up to 2 CPUs if permitted to do so. For a machine with many CPUs it is possible to use several  ndbd  processes which belong to different node groups; however, such a configuration is still considered experimental and is not supported for MySQL 8.0 in a production setting. See Section 23.1.7, “Known Limitations of NDB Cluster” . ndbinfo_select_all  is a client program that selects all rows and columns from one or more tables in the  ndbinfo  database 23.4.2 ndbinfo_select_all — Select From ndbinfo Tables 4248 shell>  ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"