Author: paul
Date: 2007-03-02 22:16:45 +0100 (Fri, 02 Mar 2007)
New Revision: 5153
Log:
r20854@polar: paul | 2007-03-02 13:53:52 -0600
Convert ndbd section to use manpage markup.
Modified:
trunk/refman-4.1/mysql-cluster.xml
trunk/refman-5.0/mysql-cluster.xml
trunk/refman-5.1/mysql-cluster.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:20851
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:16997
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593
+ 4767c598-dc10-0410-bea0-d01b485662eb:/mysqldoc-local/mysqldoc/trunk:20854
7d8d2c4e-af1d-0410-ab9f-b038ce55645b:/mysqldoc-local/mysqldoc:16997
b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:14218
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:14593
Modified: trunk/refman-4.1/mysql-cluster.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster.xml 2007-03-02 19:18:55 UTC (rev 5152)
+++ trunk/refman-4.1/mysql-cluster.xml 2007-03-02 21:16:45 UTC (rev 5153)
Changed blocks: 2, Lines Added: 241, Lines Deleted: 202; 21986 bytes
@@ -8851,104 +8851,135 @@
</section>
- <section id="mysql-cluster-ndbd-process">
+ <section id="fake-id-for-ndbd-manpage-section-wrapper">
- <title><command>ndbd</command>, the Storage Engine Node Process</title>
+ <title>fake title for ndbd manpage section wrapper</title>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary><command>ndbd</command> process</secondary>
- </indexterm>
+ <refentry id="mysql-cluster-ndbd-process">
- <indexterm>
- <primary><command>ndbd</command> (MySQL Cluster process)</primary>
- </indexterm>
+ <indexterm>
+ <primary>ndbd (MySQL Cluster process)</primary>
+ </indexterm>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>data nodes</secondary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary><command>ndbd</command> process</secondary>
+ </indexterm>
- <indexterm>
- <primary>data nodes (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data nodes</secondary>
+ </indexterm>
- <indexterm>
- <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
+ <indexterm>
+ <primary>data nodes (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
<!-- <see>data nodes, <command>ndbd</command></see> -->
- </indexterm>
+ </indexterm>
- <para>
- <command>ndbd</command> is the process that is used to handle
- all the data in tables using the NDB Cluster storage engine.
- This is the process that empowers a data node to accomplish
- distributed transaction handling, node recovery, checkpointing
- to disk, online backup, and related tasks.
- </para>
+ <refmeta>
+ <refentrytitle><command>ndbd</command></refentrytitle>
+
+ <manvolnum>1</manvolnum>
+ <refmiscinfo class="manual">MySQL Database System</refmiscinfo>
+ <refmiscinfo class="source">MySQL</refmiscinfo>
+ <refmiscinfo class="version">¤t-series;</refmiscinfo>
+ <refmiscinfo class="refman">The Storage Engine Node Process</refmiscinfo>
+ </refmeta>
- <para>
- In a MySQL Cluster, a set of <command>ndbd</command> processes
- cooperate in handling data. These processes can execute on the
- same computer (host) or on different computers. The
- correspondences between data nodes and Cluster hosts is
- completely configurable.
- </para>
+ <refnamediv>
+ <refname>ndbd</refname>
+
+ <refpurpose>the storage engine node process</refpurpose>
+ </refnamediv>
- <remark role="todo">
- [js] Insert figure here?
- </remark>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>ndbd <replaceable>options</replaceable></command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>log files</secondary>
- </indexterm>
+ <refsection id="ndbd-description">
- <indexterm>
- <primary>log files (MySQL Cluster)</primary>
- </indexterm>
+ <title>Description</title>
- <para>
- In MySQL versions prior to 4.1.5, each <command>ndbd</command>
- process should be started in a separate directory, the reason
- for this being that <command>ndbd</command> generated a set of
- log files in its starting directory. In MySQL 4.1.5, this
- behavior was changed such that these files are placed in the
- directory specified by <literal>DataDir</literal> in the
- configuration file. Thus <command>ndbd</command> can be started
- from anywhere.
- </para>
+ <para>
+ <command>ndbd</command> is the process that is used to
+ handle all the data in tables using the NDB Cluster storage
+ engine. This is the process that empowers a data node to
+ accomplish distributed transaction handling, node recovery,
+ checkpointing to disk, online backup, and related tasks.
+ </para>
- <para>
- These log files are listed below.
- <replaceable>node_id</replaceable> is the node's unique
- identifier. Note that <replaceable>node_id</replaceable>
- represents the node's unique identifier. For example,
- <filename>ndb_2_error.log</filename> is the error log generated
- by the data node whose node ID is <literal>2</literal>.
- </para>
+ <para>
+ In a MySQL Cluster, a set of <command>ndbd</command>
+ processes cooperate in handling data. These processes can
+ execute on the same computer (host) or on different
+ computers. The correspondences between data nodes and
+ Cluster hosts is completely configurable.
+ </para>
- <itemizedlist>
+ <remark role="todo">
+ [js] Insert figure here?
+ </remark>
- <listitem>
<indexterm>
<primary>MySQL Cluster</primary>
- <secondary>error logs</secondary>
+ <secondary>log files</secondary>
</indexterm>
<indexterm>
- <primary>error logs (MySQL Cluster)</primary>
+ <primary>log files (MySQL Cluster)</primary>
</indexterm>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
- (was <filename>error.log</filename> in version 4.1.3) is a
- file containing records of all crashes which the referenced
- <command>ndbd</command> process has encountered. Each record
- in this file contains a brief error string and a reference
- to a trace file for this crash. A typical entry in this file
- might appear as shown here:
+ In MySQL versions prior to 4.1.5, each
+ <command>ndbd</command> process should be started in a
+ separate directory, the reason for this being that
+ <command>ndbd</command> generated a set of log files in its
+ starting directory. In MySQL 4.1.5, this behavior was
+ changed such that these files are placed in the directory
+ specified by <literal>DataDir</literal> in the configuration
+ file. Thus <command>ndbd</command> can be started from
+ anywhere.
</para>
+ <para>
+ These log files are listed below.
+ <replaceable>node_id</replaceable> is the node's unique
+ identifier. Note that <replaceable>node_id</replaceable>
+ represents the node's unique identifier. For example,
+ <filename>ndb_2_error.log</filename> is the error log
+ generated by the data node whose node ID is
+ <literal>2</literal>.
+ </para>
+
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>error logs</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>error logs (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
+ (was <filename>error.log</filename> in version 4.1.3) is
+ a file containing records of all crashes which the
+ referenced <command>ndbd</command> process has
+ encountered. Each record in this file contains a brief
+ error string and a reference to a trace file for this
+ crash. A typical entry in this file might appear as
+ shown here:
+ </para>
+
<programlisting>
Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
@@ -8962,159 +8993,167 @@
***EOM***
</programlisting>
- <para>
- <emphasis role="bold">Note</emphasis>: <emphasis>It is very
- important to be aware that the last entry in the error log
- file is not necessarily the newest one</emphasis> (nor is it
- likely to be). Entries in the error log are
- <emphasis>not</emphasis> listed in chronological order;
- rather, they correspond to the order of the trace files as
- determined in the
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- file (see below). Error log entries are thus overwritten in
- a cyclical and not sequential fashion.
- </para>
- </listitem>
+ <para>
+ <emphasis role="bold">Note</emphasis>: <emphasis>It is
+ very important to be aware that the last entry in the
+ error log file is not necessarily the newest
+ one</emphasis> (nor is it likely to be). Entries in the
+ error log are <emphasis>not</emphasis> listed in
+ chronological order; rather, they correspond to the
+ order of the trace files as determined in the
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ file (see below). Error log entries are thus overwritten
+ in a cyclical and not sequential fashion.
+ </para>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>trace files</secondary>
- </indexterm>
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>trace files</secondary>
+ </indexterm>
- <indexterm>
- <primary>trace files (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>trace files (MySQL Cluster)</primary>
+ </indexterm>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
+ (was
+ <filename>NDB_TraceFile_<replaceable>trace_id</replaceable>.trace</filename>
+ in version 4.1.3) is a trace file describing exactly
+ what happened just before the error occurred. This
+ information is useful for analysis by the MySQL Cluster
+ development team.
+ </para>
+
+ <remark>
+ The information in this file is described in @ref{MySQL
+ Cluster Troubleshooting}.
+ </remark>
+
+ <para>
+ It is possible to configure the number of these trace
+ files that will be created before old files are
+ overwritten. <replaceable>trace_id</replaceable> is a
+ number which is incremented for each successive trace
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ (was <filename>NextTraceFileNo.log</filename> in version
+ 4.1.3) is the file that keeps track of the next trace
+ file number to be assigned.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
+ is a file containing any data output by the
+ <command>ndbd</command> process. This file is created
+ only if <command>ndbd</command> is started as a daemon,
+ which is the default behavior beginning with MySQL
+ 4.1.5. This file was named
+ <filename>node<replaceable>node_id</replaceable>.out</filename>
+ in versions 4.1.3 and 4.1.4.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
+ is a file containing the process ID of the
+ <command>ndbd</command> process when started as a
+ daemon. It also functions as a lock file to avoid the
+ starting of nodes with the same identifier.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
+ (was <filename>Signal.log</filename> in version 4.1.3)
+ is a file used only in debug versions of
+ <command>ndbd</command>, where it is possible to trace
+ all incoming, outgoing, and internal messages with their
+ data in the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
- (was
- <filename>NDB_TraceFile_<replaceable>trace_id</replaceable>.trace</filename>
- in version 4.1.3) is a trace file describing exactly what
- happened just before the error occurred. This information is
- useful for analysis by the MySQL Cluster development team.
+ It is recommended not to use a directory mounted through NFS
+ because in some environments this can cause problems whereby
+ the lock on the <filename>.pid</filename> file remains in
+ effect even after the process has terminated.
</para>
- <remark>
- The information in this file is described in @ref{MySQL
- Cluster Troubleshooting}.
- </remark>
-
<para>
- It is possible to configure the number of these trace files
- that will be created before old files are overwritten.
- <replaceable>trace_id</replaceable> is a number which is
- incremented for each successive trace file.
+ To start <command>ndbd</command>, it may also be necessary
+ to specify the hostname 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.
</para>
- </listitem>
- <listitem>
+<programlisting>
+shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
+</programlisting>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- (was <filename>NextTraceFileNo.log</filename> in version
- 4.1.3) is the file that keeps track of the next trace file
- number to be assigned.
+ See <xref linkend="mysql-cluster-connectstring"/>, for
+ additional information about this issue.
+ <xref linkend="mysql-cluster-command-options"/>, describes
+ other options for <command>ndbd</command>.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
- is a file containing any data output by the
- <command>ndbd</command> process. This file is created only
- if <command>ndbd</command> is started as a daemon, which is
- the default behavior beginning with MySQL 4.1.5. This file
- was named
- <filename>node<replaceable>node_id</replaceable>.out</filename>
- in versions 4.1.3 and 4.1.4.
+ When <command>ndbd</command> starts, it actually initiates
+ two processes. The first of these is called the <quote>angel
+ process</quote>; its only job is to discover when the
+ execution process has been completed, and then to restart
+ the <command>ndbd</command> process if it is configured to
+ do so. Thus, if you attempt to kill <command>ndbd</command>
+ via the Unix <command>kill</command> command, it is
+ necessary to kill both processes, beginning with the angel
+ process. The preferred method of terminating an
+ <command>ndbd</command> process is to use the management
+ client and stop the process from there.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
- is a file containing the process ID of the
- <command>ndbd</command> process when started as a daemon. It
- also functions as a lock file to avoid the starting of nodes
- with the same identifier.
+ 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 activites. 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
+ <command>ndbd</command> process. In a multi-processor system
+ performing a large number of operations (including updates),
+ the <command>ndbd</command> process can consume up to 2 CPUs
+ if permitted to do so.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
- (was <filename>Signal.log</filename> in version 4.1.3) is a
- file used only in debug versions of <command>ndbd</command>,
- where it is possible to trace all incoming, outgoing, and
- internal messages with their data in the
- <command>ndbd</command> process.
+ For a machine with many CPUs it is possible to use several
+ <command>ndbd</command> processes which belong to different
+ node groups; however, such a configuration is still
+ considered experimental and is not supported for MySQL
+ ¤t-series; in a production setting. See
+ <xref linkend="mysql-cluster-limitations"/>.
</para>
- </listitem>
- </itemizedlist>
+ </refsection>
- <para>
- It is recommended not to use a directory mounted through NFS
- because in some environments this can cause problems whereby the
- lock on the <filename>.pid</filename> file remains in effect
- even after the process has terminated.
- </para>
+ </refentry>
- <para>
- To start <command>ndbd</command>, it may also be necessary to
- specify the hostname 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.
- </para>
-
-<programlisting>
-shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
-</programlisting>
-
- <para>
- See <xref linkend="mysql-cluster-connectstring"/>, for
- additional information about this issue.
- <xref linkend="mysql-cluster-command-options"/>, describes other
- options for <command>ndbd</command>.
- </para>
-
- <para>
- When <command>ndbd</command> starts, it actually initiates two
- processes. The first of these is called the <quote>angel
- process</quote>; its only job is to discover when the execution
- process has been completed, and then to restart the
- <command>ndbd</command> process if it is configured to do so.
- Thus, if you attempt to kill <command>ndbd</command> via the
- Unix <command>kill</command> command, it is necessary to kill
- both processes, beginning with the angel process. The preferred
- method of terminating an <command>ndbd</command> process is to
- use the management client and stop the process from there.
- </para>
-
- <para>
- 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 activites. 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
- <command>ndbd</command> process. In a multi-processor system
- performing a large number of operations (including updates), the
- <command>ndbd</command> process can consume up to 2 CPUs if
- permitted to do so.
- </para>
-
- <para>
- For a machine with many CPUs it is possible to use several
- <command>ndbd</command> processes which belong to different node
- groups; however, such a configuration is still considered
- experimental and is not supported for MySQL ¤t-series; in
- a production setting. See
- <xref linkend="mysql-cluster-limitations"/>.
- </para>
-
</section>
<section id="mysql-cluster-ndb-mgmd-process">
Modified: trunk/refman-5.0/mysql-cluster.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster.xml 2007-03-02 19:18:55 UTC (rev 5152)
+++ trunk/refman-5.0/mysql-cluster.xml 2007-03-02 21:16:45 UTC (rev 5153)
Changed blocks: 2, Lines Added: 224, Lines Deleted: 186; 20086 bytes
@@ -8881,94 +8881,125 @@
</section>
- <section id="mysql-cluster-ndbd-process">
+ <section id="fake-id-for-ndbd-manpage-section-wrapper">
- <title><command>ndbd</command>, the Storage Engine Node Process</title>
+ <title>fake title for ndbd manpage section wrapper</title>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary><command>ndbd</command> process</secondary>
- </indexterm>
+ <refentry id="mysql-cluster-ndbd-process">
- <indexterm>
- <primary><command>ndbd</command> (MySQL Cluster process)</primary>
- </indexterm>
+ <indexterm>
+ <primary>ndbd (MySQL Cluster process)</primary>
+ </indexterm>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>data nodes</secondary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary><command>ndbd</command> process</secondary>
+ </indexterm>
- <indexterm>
- <primary>data nodes (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data nodes</secondary>
+ </indexterm>
- <indexterm>
- <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
+ <indexterm>
+ <primary>data nodes (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
<!-- <see>data nodes, <command>ndbd</command></see> -->
- </indexterm>
+ </indexterm>
- <para>
- <command>ndbd</command> is the process that is used to handle
- all the data in tables using the NDB Cluster storage engine.
- This is the process that empowers a data node to accomplish
- distributed transaction handling, node recovery, checkpointing
- to disk, online backup, and related tasks.
- </para>
+ <refmeta>
+ <refentrytitle><command>ndbd</command></refentrytitle>
+
+ <manvolnum>1</manvolnum>
+ <refmiscinfo class="manual">MySQL Database System</refmiscinfo>
+ <refmiscinfo class="source">MySQL</refmiscinfo>
+ <refmiscinfo class="version">¤t-series;</refmiscinfo>
+ <refmiscinfo class="refman">The Storage Engine Node Process</refmiscinfo>
+ </refmeta>
- <para>
- In a MySQL Cluster, a set of <command>ndbd</command> processes
- cooperate in handling data. These processes can execute on the
- same computer (host) or on different computers. The
- correspondences between data nodes and Cluster hosts is
- completely configurable.
- </para>
+ <refnamediv>
+ <refname>ndbd</refname>
+
+ <refpurpose>the storage engine node process</refpurpose>
+ </refnamediv>
- <remark role="todo">
- [js] Insert figure here?
- </remark>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>ndbd <replaceable>options</replaceable></command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>log files</secondary>
- </indexterm>
+ <refsection id="ndbd-description">
- <indexterm>
- <primary>log files (MySQL Cluster)</primary>
- </indexterm>
+ <title>Description</title>
- <para>
- <command>ndbd</command> generates a set of log files which are
- placed in the directory specified by <literal>DataDir</literal>
- in the <filename>config.ini</filename> configuration file. These
- log files are listed below. Note that
- <replaceable>node_id</replaceable> represents the node's unique
- identifier. For example, <filename>ndb_2_error.log</filename> is
- the error log generated by the data node whose node ID is
- <literal>2</literal>.
- </para>
+ <para>
+ <command>ndbd</command> is the process that is used to
+ handle all the data in tables using the NDB Cluster storage
+ engine. This is the process that empowers a data node to
+ accomplish distributed transaction handling, node recovery,
+ checkpointing to disk, online backup, and related tasks.
+ </para>
- <itemizedlist>
+ <para>
+ In a MySQL Cluster, a set of <command>ndbd</command>
+ processes cooperate in handling data. These processes can
+ execute on the same computer (host) or on different
+ computers. The correspondences between data nodes and
+ Cluster hosts is completely configurable.
+ </para>
- <listitem>
+ <remark role="todo">
+ [js] Insert figure here?
+ </remark>
+
<indexterm>
<primary>MySQL Cluster</primary>
- <secondary>error logs</secondary>
+ <secondary>log files</secondary>
</indexterm>
<indexterm>
- <primary>error logs (MySQL Cluster)</primary>
+ <primary>log files (MySQL Cluster)</primary>
</indexterm>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
- is a file containing records of all crashes which the
- referenced <command>ndbd</command> process has encountered.
- Each record in this file contains a brief error string and a
- reference to a trace file for this crash. A typical entry in
- this file might appear as shown here:
+ <command>ndbd</command> generates a set of log files which
+ are placed in the directory specified by
+ <literal>DataDir</literal> in the
+ <filename>config.ini</filename> configuration file. These
+ log files are listed below. Note that
+ <replaceable>node_id</replaceable> represents the node's
+ unique identifier. For example,
+ <filename>ndb_2_error.log</filename> is the error log
+ generated by the data node whose node ID is
+ <literal>2</literal>.
</para>
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>error logs</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>error logs (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
+ is a file containing records of all crashes which the
+ referenced <command>ndbd</command> process has
+ encountered. Each record in this file contains a brief
+ error string and a reference to a trace file for this
+ crash. A typical entry in this file might appear as
+ shown here:
+ </para>
+
<programlisting>
Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
@@ -8982,152 +9013,159 @@
***EOM***
</programlisting>
- <para>
- <emphasis role="bold">Note</emphasis>: <emphasis>It is very
- important to be aware that the last entry in the error log
- file is not necessarily the newest one</emphasis> (nor is it
- likely to be). Entries in the error log are
- <emphasis>not</emphasis> listed in chronological order;
- rather, they correspond to the order of the trace files as
- determined in the
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- file (see below). Error log entries are thus overwritten in
- a cyclical and not sequential fashion.
- </para>
- </listitem>
+ <para>
+ <emphasis role="bold">Note</emphasis>: <emphasis>It is
+ very important to be aware that the last entry in the
+ error log file is not necessarily the newest
+ one</emphasis> (nor is it likely to be). Entries in the
+ error log are <emphasis>not</emphasis> listed in
+ chronological order; rather, they correspond to the
+ order of the trace files as determined in the
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ file (see below). Error log entries are thus overwritten
+ in a cyclical and not sequential fashion.
+ </para>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>trace files</secondary>
- </indexterm>
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>trace files</secondary>
+ </indexterm>
- <indexterm>
- <primary>trace files (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>trace files (MySQL Cluster)</primary>
+ </indexterm>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
+ is a trace file describing exactly what happened just
+ before the error occurred. This information is useful
+ for analysis by the MySQL Cluster development team.
+ </para>
+
+ <remark>
+ The information in this file is described in @ref{MySQL
+ Cluster Troubleshooting}.
+ </remark>
+
+ <para>
+ It is possible to configure the number of these trace
+ files that will be created before old files are
+ overwritten. <replaceable>trace_id</replaceable> is a
+ number which is incremented for each successive trace
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ is the file that keeps track of the next trace file
+ number to be assigned.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
+ is a file containing any data output by the
+ <command>ndbd</command> process. This file is created
+ only if <command>ndbd</command> is started as a daemon,
+ which is the default behavior.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
+ is a file containing the process ID of the
+ <command>ndbd</command> process when started as a
+ daemon. It also functions as a lock file to avoid the
+ starting of nodes with the same identifier.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
+ is a file used only in debug versions of
+ <command>ndbd</command>, where it is possible to trace
+ all incoming, outgoing, and internal messages with their
+ data in the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
- is a trace file describing exactly what happened just before
- the error occurred. This information is useful for analysis
- by the MySQL Cluster development team.
+ It is recommended not to use a directory mounted through NFS
+ because in some environments this can cause problems whereby
+ the lock on the <filename>.pid</filename> file remains in
+ effect even after the process has terminated.
</para>
- <remark>
- The information in this file is described in @ref{MySQL
- Cluster Troubleshooting}.
- </remark>
-
<para>
- It is possible to configure the number of these trace files
- that will be created before old files are overwritten.
- <replaceable>trace_id</replaceable> is a number which is
- incremented for each successive trace file.
+ To start <command>ndbd</command>, it may also be necessary
+ to specify the hostname 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.
</para>
- </listitem>
- <listitem>
+<programlisting>
+shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
+</programlisting>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- is the file that keeps track of the next trace file number
- to be assigned.
+ See <xref linkend="mysql-cluster-connectstring"/>, for
+ additional information about this issue.
+ <xref linkend="mysql-cluster-command-options"/>, describes
+ other options for <command>ndbd</command>.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
- is a file containing any data output by the
- <command>ndbd</command> process. This file is created only
- if <command>ndbd</command> is started as a daemon, which is
- the default behavior.
+ When <command>ndbd</command> starts, it actually initiates
+ two processes. The first of these is called the <quote>angel
+ process</quote>; its only job is to discover when the
+ execution process has been completed, and then to restart
+ the <command>ndbd</command> process if it is configured to
+ do so. Thus, if you attempt to kill <command>ndbd</command>
+ via the Unix <command>kill</command> command, it is
+ necessary to kill both processes, beginning with the angel
+ process. The preferred method of terminating an
+ <command>ndbd</command> process is to use the management
+ client and stop the process from there.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
- is a file containing the process ID of the
- <command>ndbd</command> process when started as a daemon. It
- also functions as a lock file to avoid the starting of nodes
- with the same identifier.
+ 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 activites. 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
+ <command>ndbd</command> process. In a multi-processor system
+ performing a large number of operations (including updates),
+ the <command>ndbd</command> process can consume up to 2 CPUs
+ if permitted to do so.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
- is a file used only in debug versions of
- <command>ndbd</command>, where it is possible to trace all
- incoming, outgoing, and internal messages with their data in
- the <command>ndbd</command> process.
+ For a machine with many CPUs it is possible to use several
+ <command>ndbd</command> processes which belong to different
+ node groups; however, such a configuration is still
+ considered experimental and is not supported for MySQL
+ ¤t-series; in a production setting. See
+ <xref linkend="mysql-cluster-limitations"/>.
</para>
- </listitem>
- </itemizedlist>
+ </refsection>
- <para>
- It is recommended not to use a directory mounted through NFS
- because in some environments this can cause problems whereby the
- lock on the <filename>.pid</filename> file remains in effect
- even after the process has terminated.
- </para>
+ </refentry>
- <para>
- To start <command>ndbd</command>, it may also be necessary to
- specify the hostname 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.
- </para>
-
-<programlisting>
-shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
-</programlisting>
-
- <para>
- See <xref linkend="mysql-cluster-connectstring"/>, for
- additional information about this issue.
- <xref linkend="mysql-cluster-command-options"/>, describes other
- options for <command>ndbd</command>.
- </para>
-
- <para>
- When <command>ndbd</command> starts, it actually initiates two
- processes. The first of these is called the <quote>angel
- process</quote>; its only job is to discover when the execution
- process has been completed, and then to restart the
- <command>ndbd</command> process if it is configured to do so.
- Thus, if you attempt to kill <command>ndbd</command> via the
- Unix <command>kill</command> command, it is necessary to kill
- both processes, beginning with the angel process. The preferred
- method of terminating an <command>ndbd</command> process is to
- use the management client and stop the process from there.
- </para>
-
- <para>
- 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 activites. 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
- <command>ndbd</command> process. In a multi-processor system
- performing a large number of operations (including updates), the
- <command>ndbd</command> process can consume up to 2 CPUs if
- permitted to do so.
- </para>
-
- <para>
- For a machine with many CPUs it is possible to use several
- <command>ndbd</command> processes which belong to different node
- groups; however, such a configuration is still considered
- experimental and is not supported for MySQL ¤t-series; in
- a production setting. See
- <xref linkend="mysql-cluster-limitations"/>.
- </para>
-
</section>
<section id="mysql-cluster-ndb-mgmd-process">
Modified: trunk/refman-5.1/mysql-cluster.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster.xml 2007-03-02 19:18:55 UTC (rev 5152)
+++ trunk/refman-5.1/mysql-cluster.xml 2007-03-02 21:16:45 UTC (rev 5153)
Changed blocks: 3, Lines Added: 225, Lines Deleted: 187; 20313 bytes
@@ -8910,94 +8910,125 @@
</section>
- <section id="mysql-cluster-ndbd-process">
+ <section id="fake-id-for-ndbd-manpage-section-wrapper">
- <title><command>ndbd</command>, the Storage Engine Node Process</title>
+ <title>fake title for ndbd manpage section wrapper</title>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary><command>ndbd</command> process</secondary>
- </indexterm>
+ <refentry id="mysql-cluster-ndbd-process">
- <indexterm>
- <primary><command>ndbd</command> (MySQL Cluster process)</primary>
- </indexterm>
+ <indexterm>
+ <primary>ndbd (MySQL Cluster process)</primary>
+ </indexterm>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>data nodes</secondary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary><command>ndbd</command> process</secondary>
+ </indexterm>
- <indexterm>
- <primary>data nodes (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>data nodes</secondary>
+ </indexterm>
- <indexterm>
- <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
+ <indexterm>
+ <primary>data nodes (MySQL Cluster)</primary>
+ </indexterm>
+
+ <indexterm>
+ <primary>storage nodes - see data nodes, <command>ndbd</command></primary>
<!-- <see>data nodes, <command>ndbd</command></see> -->
- </indexterm>
+ </indexterm>
- <para>
- <command>ndbd</command> is the process that is used to handle
- all the data in tables using the NDB Cluster storage engine.
- This is the process that empowers a data node to accomplish
- distributed transaction handling, node recovery, checkpointing
- to disk, online backup, and related tasks.
- </para>
+ <refmeta>
+ <refentrytitle><command>ndbd</command></refentrytitle>
+
+ <manvolnum>1</manvolnum>
+ <refmiscinfo class="manual">MySQL Database System</refmiscinfo>
+ <refmiscinfo class="source">MySQL</refmiscinfo>
+ <refmiscinfo class="version">¤t-series;</refmiscinfo>
+ <refmiscinfo class="refman">The Storage Engine Node Process</refmiscinfo>
+ </refmeta>
- <para>
- In a MySQL Cluster, a set of <command>ndbd</command> processes
- cooperate in handling data. These processes can execute on the
- same computer (host) or on different computers. The
- correspondences between data nodes and Cluster hosts is
- completely configurable.
- </para>
+ <refnamediv>
+ <refname>ndbd</refname>
+
+ <refpurpose>the storage engine node process</refpurpose>
+ </refnamediv>
- <remark role="todo">
- [js] Insert figure here?
- </remark>
+ <refsynopsisdiv>
+ <cmdsynopsis>
+ <command>ndbd <replaceable>options</replaceable></command>
+ </cmdsynopsis>
+ </refsynopsisdiv>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>log files</secondary>
- </indexterm>
+ <refsection id="ndbd-description">
- <indexterm>
- <primary>log files (MySQL Cluster)</primary>
- </indexterm>
+ <title>Description</title>
- <para>
- <command>ndbd</command> generates a set of log files which are
- placed in the directory specified by <literal>DataDir</literal>
- in the <filename>config.ini</filename> configuration file. These
- log files are listed below. Note that
- <replaceable>node_id</replaceable> represents the node's unique
- identifier. For example, <filename>ndb_2_error.log</filename> is
- the error log generated by the data node whose node ID is
- <literal>2</literal>.
- </para>
+ <para>
+ <command>ndbd</command> is the process that is used to
+ handle all the data in tables using the NDB Cluster storage
+ engine. This is the process that empowers a data node to
+ accomplish distributed transaction handling, node recovery,
+ checkpointing to disk, online backup, and related tasks.
+ </para>
- <itemizedlist>
+ <para>
+ In a MySQL Cluster, a set of <command>ndbd</command>
+ processes cooperate in handling data. These processes can
+ execute on the same computer (host) or on different
+ computers. The correspondences between data nodes and
+ Cluster hosts is completely configurable.
+ </para>
- <listitem>
+ <remark role="todo">
+ [js] Insert figure here?
+ </remark>
+
<indexterm>
<primary>MySQL Cluster</primary>
- <secondary>error logs</secondary>
+ <secondary>log files</secondary>
</indexterm>
<indexterm>
- <primary>error logs (MySQL Cluster)</primary>
+ <primary>log files (MySQL Cluster)</primary>
</indexterm>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
- is a file containing records of all crashes which the
- referenced <command>ndbd</command> process has encountered.
- Each record in this file contains a brief error string and a
- reference to a trace file for this crash. A typical entry in
- this file might appear as shown here:
+ <command>ndbd</command> generates a set of log files which
+ are placed in the directory specified by
+ <literal>DataDir</literal> in the
+ <filename>config.ini</filename> configuration file. These
+ log files are listed below. Note that
+ <replaceable>node_id</replaceable> represents the node's
+ unique identifier. For example,
+ <filename>ndb_2_error.log</filename> is the error log
+ generated by the data node whose node ID is
+ <literal>2</literal>.
</para>
+ <itemizedlist>
+
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>error logs</secondary>
+ </indexterm>
+
+ <indexterm>
+ <primary>error logs (MySQL Cluster)</primary>
+ </indexterm>
+
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_error.log</filename>
+ is a file containing records of all crashes which the
+ referenced <command>ndbd</command> process has
+ encountered. Each record in this file contains a brief
+ error string and a reference to a trace file for this
+ crash. A typical entry in this file might appear as
+ shown here:
+ </para>
+
<programlisting>
Date/Time: Saturday 30 July 2004 - 00:20:01
Type of error: error
@@ -9011,152 +9042,159 @@
***EOM***
</programlisting>
- <para>
- <emphasis role="bold">Note</emphasis>: <emphasis>It is very
- important to be aware that the last entry in the error log
- file is not necessarily the newest one</emphasis> (nor is it
- likely to be). Entries in the error log are
- <emphasis>not</emphasis> listed in chronological order;
- rather, they correspond to the order of the trace files as
- determined in the
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- file (see below). Error log entries are thus overwritten in
- a cyclical and not sequential fashion.
- </para>
- </listitem>
+ <para>
+ <emphasis role="bold">Note</emphasis>: <emphasis>It is
+ very important to be aware that the last entry in the
+ error log file is not necessarily the newest
+ one</emphasis> (nor is it likely to be). Entries in the
+ error log are <emphasis>not</emphasis> listed in
+ chronological order; rather, they correspond to the
+ order of the trace files as determined in the
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ file (see below). Error log entries are thus overwritten
+ in a cyclical and not sequential fashion.
+ </para>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>trace files</secondary>
- </indexterm>
+ <listitem>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>trace files</secondary>
+ </indexterm>
- <indexterm>
- <primary>trace files (MySQL Cluster)</primary>
- </indexterm>
+ <indexterm>
+ <primary>trace files (MySQL Cluster)</primary>
+ </indexterm>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
+ is a trace file describing exactly what happened just
+ before the error occurred. This information is useful
+ for analysis by the MySQL Cluster development team.
+ </para>
+
+ <remark>
+ The information in this file is described in @ref{MySQL
+ Cluster Troubleshooting}.
+ </remark>
+
+ <para>
+ It is possible to configure the number of these trace
+ files that will be created before old files are
+ overwritten. <replaceable>trace_id</replaceable> is a
+ number which is incremented for each successive trace
+ file.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
+ is the file that keeps track of the next trace file
+ number to be assigned.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
+ is a file containing any data output by the
+ <command>ndbd</command> process. This file is created
+ only if <command>ndbd</command> is started as a daemon,
+ which is the default behavior.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
+ is a file containing the process ID of the
+ <command>ndbd</command> process when started as a
+ daemon. It also functions as a lock file to avoid the
+ starting of nodes with the same identifier.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
+ is a file used only in debug versions of
+ <command>ndbd</command>, where it is possible to trace
+ all incoming, outgoing, and internal messages with their
+ data in the <command>ndbd</command> process.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.<replaceable>trace_id</replaceable></filename>
- is a trace file describing exactly what happened just before
- the error occurred. This information is useful for analysis
- by the MySQL Cluster development team.
+ It is recommended not to use a directory mounted through NFS
+ because in some environments this can cause problems whereby
+ the lock on the <filename>.pid</filename> file remains in
+ effect even after the process has terminated.
</para>
- <remark>
- The information in this file is described in @ref{MySQL
- Cluster Troubleshooting}.
- </remark>
-
<para>
- It is possible to configure the number of these trace files
- that will be created before old files are overwritten.
- <replaceable>trace_id</replaceable> is a number which is
- incremented for each successive trace file.
+ To start <command>ndbd</command>, it may also be necessary
+ to specify the hostname 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.
</para>
- </listitem>
- <listitem>
+<programlisting>
+shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
+</programlisting>
+
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_trace.log.next</filename>
- is the file that keeps track of the next trace file number
- to be assigned.
+ See <xref linkend="mysql-cluster-connectstring"/>, for
+ additional information about this issue.
+ <xref linkend="mysql-cluster-command-options"/>, describes
+ other options for <command>ndbd</command>.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_out.log</filename>
- is a file containing any data output by the
- <command>ndbd</command> process. This file is created only
- if <command>ndbd</command> is started as a daemon, which is
- the default behavior.
+ When <command>ndbd</command> starts, it actually initiates
+ two processes. The first of these is called the <quote>angel
+ process</quote>; its only job is to discover when the
+ execution process has been completed, and then to restart
+ the <command>ndbd</command> process if it is configured to
+ do so. Thus, if you attempt to kill <command>ndbd</command>
+ via the Unix <command>kill</command> command, it is
+ necessary to kill both processes, beginning with the angel
+ process. The preferred method of terminating an
+ <command>ndbd</command> process is to use the management
+ client and stop the process from there.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>.pid</filename>
- is a file containing the process ID of the
- <command>ndbd</command> process when started as a daemon. It
- also functions as a lock file to avoid the starting of nodes
- with the same identifier.
+ 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 activites. 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
+ <command>ndbd</command> process. In a multi-processor system
+ performing a large number of operations (including updates),
+ the <command>ndbd</command> process can consume up to 2 CPUs
+ if permitted to do so.
</para>
- </listitem>
- <listitem>
<para>
- <filename>ndb_<replaceable>node_id</replaceable>_signal.log</filename>
- is a file used only in debug versions of
- <command>ndbd</command>, where it is possible to trace all
- incoming, outgoing, and internal messages with their data in
- the <command>ndbd</command> process.
+ For a machine with many CPUs it is possible to use several
+ <command>ndbd</command> processes which belong to different
+ node groups; however, such a configuration is still
+ considered experimental and is not supported for MySQL
+ ¤t-series; in a production setting. See
+ <xref linkend="mysql-cluster-limitations"/>.
</para>
- </listitem>
- </itemizedlist>
+ </refsection>
- <para>
- It is recommended not to use a directory mounted through NFS
- because in some environments this can cause problems whereby the
- lock on the <filename>.pid</filename> file remains in effect
- even after the process has terminated.
- </para>
+ </refentry>
- <para>
- To start <command>ndbd</command>, it may also be necessary to
- specify the hostname 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.
- </para>
-
-<programlisting>
-shell> <userinput>ndbd --connect-string="nodeid=2;host=ndb_mgmd.mysql.com:1186"</userinput>
-</programlisting>
-
- <para>
- See <xref linkend="mysql-cluster-connectstring"/>, for
- additional information about this issue.
- <xref linkend="mysql-cluster-command-options"/>, describes other
- options for <command>ndbd</command>.
- </para>
-
- <para>
- When <command>ndbd</command> starts, it actually initiates two
- processes. The first of these is called the <quote>angel
- process</quote>; its only job is to discover when the execution
- process has been completed, and then to restart the
- <command>ndbd</command> process if it is configured to do so.
- Thus, if you attempt to kill <command>ndbd</command> via the
- Unix <command>kill</command> command, it is necessary to kill
- both processes, beginning with the angel process. The preferred
- method of terminating an <command>ndbd</command> process is to
- use the management client and stop the process from there.
- </para>
-
- <para>
- 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 activites. 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
- <command>ndbd</command> process. In a multi-processor system
- performing a large number of operations (including updates), the
- <command>ndbd</command> process can consume up to 2 CPUs if
- permitted to do so.
- </para>
-
- <para>
- For a machine with many CPUs it is possible to use several
- <command>ndbd</command> processes which belong to different node
- groups; however, such a configuration is still considered
- experimental and is not supported for MySQL ¤t-series; in
- a production setting. See
- <xref linkend="mysql-cluster-limitations"/>.
- </para>
-
</section>
<section id="mysql-cluster-ndb-mgmd-process">
@@ -15151,7 +15189,7 @@
further example, consider the table created and populated as
shown here:
</para>
-
+
<programlisting>
CREATE TABLE dogs (
id INT(11) NOT NULL AUTO_INCREMENT,
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r5153 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 2 Mar |
