Author: paul
Date: 2006-02-01 02:39:33 +0100 (Wed, 01 Feb 2006)
New Revision: 1160
Log:
r7012@frost: paul | 2006-01-31 19:38:35 -0600
General revisions.
Modified:
trunk/
trunk/refman-4.1/ndbcluster.xml
trunk/refman-5.0/ndbcluster.xml
trunk/refman-5.1/ndbcluster.xml
Property changes on: trunk
___________________________________________________________________
Name: svk:merge
- b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7008
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2749
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7012
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2749
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-01-31 23:51:53 UTC (rev 1159)
+++ trunk/refman-4.1/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
@@ -2641,9 +2641,9 @@
bytes) to which the file can grow before logging
rolls over to a new file. When this occurs, the
old logfile is renamed by appending
- <filename>.x</filename> to the filename, where
- <literal>x</literal> is the next number not yet
- used with this name.
+ <replaceable>.N</replaceable> to the filename,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
</para>
</listitem>
@@ -2661,8 +2661,8 @@
</programlisting>
<para>
- It is possible to specify multiple log destinations as
- shown here, using a semicolon-delimited string:
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
</para>
<programlisting>
@@ -2747,13 +2747,13 @@
</para>
<para>
- This sets the directory where output files from the
+ This specifies the directory where output files from the
management server will be placed. These files include
cluster log files, process output files, and the daemon's
- pid file. (For log files, this can be overridden by
- setting the <literal>FILE</literal> parameter for
- <literal>[NDB_MGMD]LogDestination</literal> as discussed
- previously in this section.)
+ process ID (PID) file. (For log files, this location can
+ be overridden by setting the <literal>FILE</literal>
+ parameter for <literal>LogDestination</literal> as
+ discussed previously in this section.)
</para>
</listitem>
@@ -2790,8 +2790,8 @@
</itemizedlist>
<para>
- These need to be defined in the <literal>[NDBD
- DEFAULT]</literal> section.
+ These mandatory parameters must be defined in the
+ <literal>[NDBD DEFAULT]</literal> section.
</para>
<para>
@@ -2857,10 +2857,9 @@
Specifying this parameter has an effect similar to
specifying <literal>ExecuteOnComputer</literal>. It
defines the hostname of the computer the storage node on
- which is to reside. Either this parameter or
- <literal>ExecuteOnComputer</literal> is required to
- specify a hostname other than
- <literal>localhost</literal>.
+ which is to reside. To specify a hostname other than
+ <literal>localhost</literal>, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required..
</para>
</listitem>
@@ -2906,8 +2905,8 @@
and the second node group by nodes 4 and 5. It is
important to configure the cluster in such a manner that
nodes in the same node groups are not placed on the same
- computer, as in this situation a single hardware failure
- would cause the entire cluster to crash.
+ computer because a single hardware failure would cause the
+ entire cluster to crash.
</para>
<para>
@@ -2967,10 +2966,11 @@
</para>
<para>
- It is also possible to specify the directory in which
- backups are placed. By default, this directory is
- <filename><replaceable>FileSystemPath/</replaceable>BACKUP</filename>.
- (See above.)
+ This parameter specifies the directory in which backups
+ are placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the
+ <literal>FileSystemPath</literal> parameter. (See above.)
</para>
</listitem>
@@ -3026,7 +3026,7 @@
ordered index. A common error among users is to assume
that all indexes are stored in the memory allocated by
<literal>IndexMemory</literal>, but this is not the case:
- only primary key and unique hash indexes use this memory;
+ Only primary key and unique hash indexes use this memory;
ordered indexes use the memory allocated by
<literal>DataMemory</literal>. However, creating a primary
key or unique hash index also creates an ordered index on
@@ -3048,9 +3048,9 @@
<literal>NoOfReplicas</literal>. Once a page has been
allocated, it is currently not possible to return it to
the pool of free pages, except by deleting the table.
- Performing a node recovery also will compress the
- partition because all records are inserted into empty
- partitions from other live nodes.
+ Performing a node recovery also compresses the partition
+ because all records are inserted into empty partitions
+ from other live nodes.
</para>
<para>
@@ -3134,9 +3134,18 @@
</para>
<para>
- Consider a table defined by
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
<programlisting>
CREATE TABLE example (
a INT NOT NULL,
@@ -3147,92 +3156,82 @@
) ENGINE=NDBCLUSTER;
</programlisting>
- <para>
- There are 12 bytes overhead (having no nullable columns
- saves 4 bytes of overhead) plus 12 bytes of data per
- record. In addition we have two ordered indexes on columns
- <literal>a</literal> and <literal>b</literal> consuming
- roughly 10 bytes each per record. There is a primary key
- hash index on the base table using roughly 29 bytes per
- record. The unique constraint is implemented by a separate
- table with <literal>b</literal> as primary key and
- <literal>a</literal> as a column. This table will consume
- an additional 29 bytes of index memory per record in the
- <literal>example</literal> table as well as 12 bytes of
- overhead, plus 8 bytes of record data.
- </para>
+ <para>
+ There are 12 bytes overhead (having no nullable columns saves
+ 4 bytes of overhead) plus 12 bytes of data per record. In
+ addition we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming
+ roughly 10 bytes each per record. There is a primary key hash
+ index on the base table using roughly 29 bytes per record. The
+ unique constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal>
+ as a column. This table will consume an additional 29 bytes of
+ index memory per record in the <literal>example</literal>
+ table as well as 12 bytes of overhead, plus 8 bytes of record
+ data.
+ </para>
- <para>
- Thus, for one million records, we need 58MB for index
- memory to handle the hash indexes for the primary key and
- the unique constraint. We also need 64MB for the records
- of the base table and the unique index table, plus the two
- ordered index tables.
- </para>
+ <para>
+ Thus, for one million records, we need 58MB for index memory
+ to handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base
+ table and the unique index table, plus the two ordered index
+ tables.
+ </para>
- <para>
- You can see that hash indexes takes up a fair amount of
- memory space; however, they provide very fast access to
- the data in return. They are also used in MySQL Cluster to
- handle uniqueness constraints.
- </para>
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle
+ uniqueness constraints.
+ </para>
- <para>
- Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered
- indexes cannot be used to handle uniqueness constraints in
- the general case.
- </para>
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
- <para>
- An important point for both <literal>IndexMemory</literal>
- and <literal>DataMemory</literal> is that the total
- database size is the sum of all data memory and all index
- memory for each node group. Each node group is used to
- store replicated information, so if there are four nodes
- with two replicas, there will be two node groups. Thus,
- the total data memory available is 2 ×
- <literal>DataMemory</literal> for each data node.
- </para>
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size
+ is the sum of all data memory and all index memory for each
+ node group. Each node group is used to store replicated
+ information, so if there are four nodes with two replicas,
+ there will be two node groups. Thus, the total data memory
+ available is 2 × <literal>DataMemory</literal> for each
+ data node.
+ </para>
- <para>
- It is highly recommended that
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> be set to the same values
- for all nodes. Data distribution is even over all nodes in
- the cluster, so the maximum amount of space available for
- any node can be no greater than that of the smallest node
- in the cluster.
- </para>
+ <para>
+ It is highly recommended that <literal>DataMemory</literal>
+ and <literal>IndexMemory</literal> be set to the same values
+ for all nodes. Data distribution is even over all nodes in the
+ cluster, so the maximum amount of space available for any node
+ can be no greater than that of the smallest node in the
+ cluster.
+ </para>
- <para>
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> can be changed, but
- decreasing either of these can be risky; doing so can
- easily lead to a node or even an entire MySQL Cluster that
- is unable to restart due to there being insufficient
- memory space. Increasing these values should be
- acceptable, but it is recommended that such upgrades are
- performed in the same manner as a software upgrade,
- beginning with an update of the configuration file, and
- then restarting the management server followed by
- restarting each data node in turn.
- </para>
+ <para>
+ <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> can be changed, but decreasing
+ either of these can be risky; doing so can easily lead to a
+ node or even an entire MySQL Cluster that is unable to restart
+ due to there being insufficient memory space. Increasing these
+ values should be acceptable, but it is recommended that such
+ upgrades are performed in the same manner as a software
+ upgrade, beginning with an update of the configuration file,
+ and then restarting the management server followed by
+ restarting each data node in turn.
+ </para>
- <para>
- Updates do not increase the amount of index memory used.
- Inserts take effect immediately; however, rows are not
- actually deleted until the transaction is committed.
- </para>
+ <para>
+ Updates do not increase the amount of index memory used.
+ Inserts take effect immediately; however, rows are not
+ actually deleted until the transaction is committed.
+ </para>
- <para>
- The default value for <literal>IndexMemory</literal> is
- 18MB. The minimum is 1MB.
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
<emphasis role="bold">Transaction Parameters</emphasis>
</para>
@@ -5120,7 +5119,7 @@
<listitem>
<para>
- <literal>[TCP]ReceiveBufferMemory</literal>
+ <literal>ReceiveBufferMemory</literal>
</para>
<para>
@@ -6474,7 +6473,7 @@
</orderedlist>
<para>
- Once each data node has been initialized, the cluster startup
+ After each data node has been initialized, the cluster startup
process can proceed. The stages which the cluster goes through
during this process are listed here:
</para>
@@ -6487,7 +6486,7 @@
</para>
<para>
- Clear the cluster filesystem. This occurs
+ Clear the cluster filesystem. This stage occurs
<emphasis>only</emphasis> if the cluster was started with
the <literal>--initial</literal> option.
</para>
@@ -6499,8 +6498,9 @@
</para>
<para>
- Cluster connections are set up; inter-node communications
- are established. Cluster heartbeats are started.
+ This stage sets up Cluster connections, establishes
+ inter-node communications are established, and starts
+ Cluster heartbeats.
</para>
</listitem>
@@ -6510,13 +6510,10 @@
</para>
<para>
- The arbitrator node is elected.
+ The arbitrator node is elected. If this is a system restart,
+ the cluster determines the latest restorable global
+ checkpoint.
</para>
-
- <para>
- If this is a system restart, the cluster determines the
- latest restorable global checkpoint.
- </para>
</listitem>
<listitem>
@@ -6525,8 +6522,8 @@
</para>
<para>
- This stage consists of the initialization of a number of
- internal cluster variables.
+ This stage initializes a number of internal cluster
+ variables.
</para>
</listitem>
@@ -6588,7 +6585,7 @@
For a node restart or an initial node restart:
</para>
- <itemizedlist>
+ <orderedlist>
<listitem>
<para>
@@ -6598,8 +6595,8 @@
<listitem>
<para>
- The node's schema is compared with the master'
- and synchronized with it.
+ The node schema is compared with that of the master and
+ synchronized with it.
</para>
</listitem>
@@ -6618,7 +6615,7 @@
</para>
</listitem>
- </itemizedlist>
+ </orderedlist>
</listitem>
<listitem>
@@ -6688,9 +6685,9 @@
</itemizedlist>
<para>
- Once this process is completed for an initial start or system
- restart, handling of transactions is enabled. For a node restart
- or initial node restart, completion of the startup process means
+ After this process is completed for an initial start or system
+ restart, transactions handling is enabled. For a node restart or
+ initial node restart, completion of the startup process means
that the node may now act as a transaction coordinator.
</para>
@@ -6708,6 +6705,13 @@
</para>
<para>
+ Commands for the event logs are given in
+ <xref linkend="mysql-cluster-event-reports"/>. commands for
+ creating backups and restoring from backup are provided in
+ <xref linkend="mysql-cluster-backup"/>.
+ </para>
+
+ <para>
The management client has the following basic commands. In the
listing that follows, <replaceable>node_id</replaceable> denotes
either a database node ID or the keyword <literal>ALL</literal>,
@@ -6841,12 +6845,6 @@
</itemizedlist>
- <para>
- Commands for the event logs are given in the next section;
- commands for creating backups and restoring from backup are
- provided in a separate section on these topics.
- </para>
-
</section>
<section id="mysql-cluster-event-reports">
@@ -6874,7 +6872,7 @@
</para>
<para>
- Both sorts of event logs can be set to log different subsets of
+ Both types of event logs can be set to log different subsets of
events.
</para>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-01-31 23:51:53 UTC (rev 1159)
+++ trunk/refman-5.0/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
@@ -2633,9 +2633,9 @@
bytes) to which the file can grow before logging
rolls over to a new file. When this occurs, the
old logfile is renamed by appending
- <filename>.x</filename> to the filename, where
- <literal>x</literal> is the next number not yet
- used with this name.
+ <replaceable>.N</replaceable> to the filename,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
</para>
</listitem>
@@ -2653,8 +2653,8 @@
</programlisting>
<para>
- It is possible to specify multiple log destinations as
- shown here, using a semicolon-delimited string:
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
</para>
<programlisting>
@@ -2739,13 +2739,13 @@
</para>
<para>
- This sets the directory where output files from the
+ This specifies the directory where output files from the
management server will be placed. These files include
cluster log files, process output files, and the daemon's
- pid file. (For log files, this can be overridden by
- setting the <literal>FILE</literal> parameter for
- <literal>[NDB_MGMD]LogDestination</literal> as discussed
- previously in this section.)
+ process ID (PID) file. (For log files, this location can
+ be overridden by setting the <literal>FILE</literal>
+ parameter for <literal>LogDestination</literal> as
+ discussed previously in this section.)
</para>
</listitem>
@@ -2782,8 +2782,8 @@
</itemizedlist>
<para>
- These need to be defined in the <literal>[NDBD
- DEFAULT]</literal> section.
+ These mandatory parameters must be defined in the
+ <literal>[NDBD DEFAULT]</literal> section.
</para>
<para>
@@ -2849,10 +2849,9 @@
Specifying this parameter has an effect similar to
specifying <literal>ExecuteOnComputer</literal>. It
defines the hostname of the computer the storage node on
- which is to reside. Either this parameter or
- <literal>ExecuteOnComputer</literal> is required to
- specify a hostname other than
- <literal>localhost</literal>.
+ which is to reside. To specify a hostname other than
+ <literal>localhost</literal>, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required..
</para>
</listitem>
@@ -2898,8 +2897,8 @@
and the second node group by nodes 4 and 5. It is
important to configure the cluster in such a manner that
nodes in the same node groups are not placed on the same
- computer, as in this situation a single hardware failure
- would cause the entire cluster to crash.
+ computer because a single hardware failure would cause the
+ entire cluster to crash.
</para>
<para>
@@ -2959,10 +2958,11 @@
</para>
<para>
- It is also possible to specify the directory in which
- backups are placed. By default, this directory is
- <filename><replaceable>FileSystemPath/</replaceable>BACKUP</filename>.
- (See above.)
+ This parameter specifies the directory in which backups
+ are placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the
+ <literal>FileSystemPath</literal> parameter. (See above.)
</para>
</listitem>
@@ -3022,7 +3022,7 @@
ordered index. A common error among users is to assume
that all indexes are stored in the memory allocated by
<literal>IndexMemory</literal>, but this is not the case:
- only primary key and unique hash indexes use this memory;
+ Only primary key and unique hash indexes use this memory;
ordered indexes use the memory allocated by
<literal>DataMemory</literal>. However, creating a primary
key or unique hash index also creates an ordered index on
@@ -3044,9 +3044,9 @@
<literal>NoOfReplicas</literal>. Once a page has been
allocated, it is currently not possible to return it to
the pool of free pages, except by deleting the table.
- Performing a node recovery also will compress the
- partition because all records are inserted into empty
- partitions from other live nodes.
+ Performing a node recovery also compresses the partition
+ because all records are inserted into empty partitions
+ from other live nodes.
</para>
<para>
@@ -3130,9 +3130,18 @@
</para>
<para>
- Consider a table defined by
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
<programlisting>
CREATE TABLE example (
a INT NOT NULL,
@@ -3143,96 +3152,86 @@
) ENGINE=NDBCLUSTER;
</programlisting>
- <para>
- There are 12 bytes overhead (having no nullable columns
- saves 4 bytes of overhead) plus 12 bytes of data per
- record. In addition we have two ordered indexes on columns
- <literal>a</literal> and <literal>b</literal> consuming
- roughly 10 bytes each per record. There is a primary key
- hash index on the base table using roughly 29 bytes per
- record. The unique constraint is implemented by a separate
- table with <literal>b</literal> as primary key and
- <literal>a</literal> as a column. This table will consume
- an additional 29 bytes of index memory per record in the
- <literal>example</literal> table as well as 12 bytes of
- overhead, plus 8 bytes of record data.
- </para>
+ <para>
+ There are 12 bytes overhead (having no nullable columns saves
+ 4 bytes of overhead) plus 12 bytes of data per record. In
+ addition we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming
+ roughly 10 bytes each per record. There is a primary key hash
+ index on the base table using roughly 29 bytes per record. The
+ unique constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal>
+ as a column. This table will consume an additional 29 bytes of
+ index memory per record in the <literal>example</literal>
+ table as well as 12 bytes of overhead, plus 8 bytes of record
+ data.
+ </para>
- <para>
- Thus, for one million records, we need 58MB for index
- memory to handle the hash indexes for the primary key and
- the unique constraint. We also need 64MB for the records
- of the base table and the unique index table, plus the two
- ordered index tables.
- </para>
+ <para>
+ Thus, for one million records, we need 58MB for index memory
+ to handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base
+ table and the unique index table, plus the two ordered index
+ tables.
+ </para>
- <para>
- You can see that hash indexes takes up a fair amount of
- memory space; however, they provide very fast access to
- the data in return. They are also used in MySQL Cluster to
- handle uniqueness constraints.
- </para>
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle
+ uniqueness constraints.
+ </para>
- <remark role="todo">
- [js] Still true in 5.0?
- </remark>
+ <remark role="todo">
+ [js] Still true in 5.0?
+ </remark>
- <para>
- Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered
- indexes cannot be used to handle uniqueness constraints in
- the general case.
- </para>
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
- <para>
- An important point for both <literal>IndexMemory</literal>
- and <literal>DataMemory</literal> is that the total
- database size is the sum of all data memory and all index
- memory for each node group. Each node group is used to
- store replicated information, so if there are four nodes
- with two replicas, there will be two node groups. Thus,
- the total data memory available is 2 ×
- <literal>DataMemory</literal> for each data node.
- </para>
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size
+ is the sum of all data memory and all index memory for each
+ node group. Each node group is used to store replicated
+ information, so if there are four nodes with two replicas,
+ there will be two node groups. Thus, the total data memory
+ available is 2 × <literal>DataMemory</literal> for each
+ data node.
+ </para>
- <para>
- It is highly recommended that
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> be set to the same values
- for all nodes. Data distribution is even over all nodes in
- the cluster, so the maximum amount of space available for
- any node can be no greater than that of the smallest node
- in the cluster.
- </para>
+ <para>
+ It is highly recommended that <literal>DataMemory</literal>
+ and <literal>IndexMemory</literal> be set to the same values
+ for all nodes. Data distribution is even over all nodes in the
+ cluster, so the maximum amount of space available for any node
+ can be no greater than that of the smallest node in the
+ cluster.
+ </para>
- <para>
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> can be changed, but
- decreasing either of these can be risky; doing so can
- easily lead to a node or even an entire MySQL Cluster that
- is unable to restart due to there being insufficient
- memory space. Increasing these values should be
- acceptable, but it is recommended that such upgrades are
- performed in the same manner as a software upgrade,
- beginning with an update of the configuration file, and
- then restarting the management server followed by
- restarting each data node in turn.
- </para>
+ <para>
+ <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> can be changed, but decreasing
+ either of these can be risky; doing so can easily lead to a
+ node or even an entire MySQL Cluster that is unable to restart
+ due to there being insufficient memory space. Increasing these
+ values should be acceptable, but it is recommended that such
+ upgrades are performed in the same manner as a software
+ upgrade, beginning with an update of the configuration file,
+ and then restarting the management server followed by
+ restarting each data node in turn.
+ </para>
- <para>
- Updates do not increase the amount of index memory used.
- Inserts take effect immediately; however, rows are not
- actually deleted until the transaction is committed.
- </para>
+ <para>
+ Updates do not increase the amount of index memory used.
+ Inserts take effect immediately; however, rows are not
+ actually deleted until the transaction is committed.
+ </para>
- <para>
- The default value for <literal>IndexMemory</literal> is
- 18MB. The minimum is 1MB.
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
<emphasis role="bold">Transaction Parameters</emphasis>
</para>
@@ -5128,7 +5127,7 @@
<listitem>
<para>
- <literal>[TCP]ReceiveBufferMemory</literal>
+ <literal>ReceiveBufferMemory</literal>
</para>
<para>
@@ -6450,7 +6449,7 @@
</orderedlist>
<para>
- Once each data node has been initialized, the cluster startup
+ After each data node has been initialized, the cluster startup
process can proceed. The stages which the cluster goes through
during this process are listed here:
</para>
@@ -6463,7 +6462,7 @@
</para>
<para>
- Clear the cluster filesystem. This occurs
+ Clear the cluster filesystem. This stage occurs
<emphasis>only</emphasis> if the cluster was started with
the <literal>--initial</literal> option.
</para>
@@ -6475,8 +6474,9 @@
</para>
<para>
- Cluster connections are set up; inter-node communications
- are established. Cluster heartbeats are started.
+ This stage sets up Cluster connections, establishes
+ inter-node communications are established, and starts
+ Cluster heartbeats.
</para>
</listitem>
@@ -6486,13 +6486,10 @@
</para>
<para>
- The arbitrator node is elected.
+ The arbitrator node is elected. If this is a system restart,
+ the cluster determines the latest restorable global
+ checkpoint.
</para>
-
- <para>
- If this is a system restart, the cluster determines the
- latest restorable global checkpoint.
- </para>
</listitem>
<listitem>
@@ -6501,8 +6498,8 @@
</para>
<para>
- This stage consists of the initialization of a number of
- internal cluster variables.
+ This stage initializes a number of internal cluster
+ variables.
</para>
</listitem>
@@ -6564,7 +6561,7 @@
For a node restart or an initial node restart:
</para>
- <itemizedlist>
+ <orderedlist>
<listitem>
<para>
@@ -6574,8 +6571,8 @@
<listitem>
<para>
- The node's schema is compared with the master'
- and synchronized with it.
+ The node schema is compared with that of the master and
+ synchronized with it.
</para>
</listitem>
@@ -6594,7 +6591,7 @@
</para>
</listitem>
- </itemizedlist>
+ </orderedlist>
</listitem>
<listitem>
@@ -6664,9 +6661,9 @@
</itemizedlist>
<para>
- Once this process is completed for an initial start or system
- restart, handling of transactions is enabled. For a node restart
- or initial node restart, completion of the startup process means
+ After this process is completed for an initial start or system
+ restart, transactions handling is enabled. For a node restart or
+ initial node restart, completion of the startup process means
that the node may now act as a transaction coordinator.
</para>
@@ -6684,6 +6681,13 @@
</para>
<para>
+ Commands for the event logs are given in
+ <xref linkend="mysql-cluster-event-reports"/>. commands for
+ creating backups and restoring from backup are provided in
+ <xref linkend="mysql-cluster-backup"/>.
+ </para>
+
+ <para>
The management client has the following basic commands. In the
listing that follows, <replaceable>node_id</replaceable> denotes
either a database node ID or the keyword <literal>ALL</literal>,
@@ -6817,12 +6821,6 @@
</itemizedlist>
- <para>
- Commands for the event logs are given in the next section;
- commands for creating backups and restoring from backup are
- provided in a separate section on these topics.
- </para>
-
</section>
<section id="mysql-cluster-event-reports">
@@ -6850,7 +6848,7 @@
</para>
<para>
- Both sorts of event logs can be set to log different subsets of
+ Both types of event logs can be set to log different subsets of
events.
</para>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-01-31 23:51:53 UTC (rev 1159)
+++ trunk/refman-5.1/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
@@ -2631,9 +2631,9 @@
bytes) to which the file can grow before logging
rolls over to a new file. When this occurs, the
old logfile is renamed by appending
- <filename>.x</filename> to the filename, where
- <literal>x</literal> is the next number not yet
- used with this name.
+ <replaceable>.N</replaceable> to the filename,
+ where <replaceable>N</replaceable> is the next
+ number not yet used with this name.
</para>
</listitem>
@@ -2651,8 +2651,8 @@
</programlisting>
<para>
- It is possible to specify multiple log destinations as
- shown here, using a semicolon-delimited string:
+ It is possible to specify multiple log destinations
+ separated by semicolons as shown here:
</para>
<programlisting>
@@ -2737,13 +2737,13 @@
</para>
<para>
- This sets the directory where output files from the
+ This specifies the directory where output files from the
management server will be placed. These files include
cluster log files, process output files, and the daemon's
- pid file. (For log files, this can be overridden by
- setting the <literal>FILE</literal> parameter for
- <literal>[NDB_MGMD]LogDestination</literal> as discussed
- previously in this section.)
+ process ID (PID) file. (For log files, this location can
+ be overridden by setting the <literal>FILE</literal>
+ parameter for <literal>LogDestination</literal> as
+ discussed previously in this section.)
</para>
</listitem>
@@ -2780,8 +2780,8 @@
</itemizedlist>
<para>
- These need to be defined in the <literal>[NDBD
- DEFAULT]</literal> section.
+ These mandatory parameters must be defined in the
+ <literal>[NDBD DEFAULT]</literal> section.
</para>
<para>
@@ -2847,10 +2847,9 @@
Specifying this parameter has an effect similar to
specifying <literal>ExecuteOnComputer</literal>. It
defines the hostname of the computer the storage node on
- which is to reside. Either this parameter or
- <literal>ExecuteOnComputer</literal> is required to
- specify a hostname other than
- <literal>localhost</literal>.
+ which is to reside. To specify a hostname other than
+ <literal>localhost</literal>, either this parameter or
+ <literal>ExecuteOnComputer</literal> is required..
</para>
</listitem>
@@ -2896,8 +2895,8 @@
and the second node group by nodes 4 and 5. It is
important to configure the cluster in such a manner that
nodes in the same node groups are not placed on the same
- computer, as in this situation a single hardware failure
- would cause the entire cluster to crash.
+ computer because a single hardware failure would cause the
+ entire cluster to crash.
</para>
<para>
@@ -2957,10 +2956,11 @@
</para>
<para>
- It is also possible to specify the directory in which
- backups are placed. By default, this directory is
- <filename><replaceable>FileSystemPath/</replaceable>BACKUP</filename>.
- (See above.)
+ This parameter specifies the directory in which backups
+ are placed. If omitted, the default backup location is the
+ directory named <filename>BACKUP</filename> under the
+ location specified by the
+ <literal>FileSystemPath</literal> parameter. (See above.)
</para>
</listitem>
@@ -3020,7 +3020,7 @@
ordered index. A common error among users is to assume
that all indexes are stored in the memory allocated by
<literal>IndexMemory</literal>, but this is not the case:
- only primary key and unique hash indexes use this memory;
+ Only primary key and unique hash indexes use this memory;
ordered indexes use the memory allocated by
<literal>DataMemory</literal>. However, creating a primary
key or unique hash index also creates an ordered index on
@@ -3042,9 +3042,9 @@
<literal>NoOfReplicas</literal>. Once a page has been
allocated, it is currently not possible to return it to
the pool of free pages, except by deleting the table.
- Performing a node recovery also will compress the
- partition because all records are inserted into empty
- partitions from other live nodes.
+ Performing a node recovery also compresses the partition
+ because all records are inserted into empty partitions
+ from other live nodes.
</para>
<para>
@@ -3128,9 +3128,18 @@
</para>
<para>
- Consider a table defined by
+ The default value for <literal>IndexMemory</literal> is
+ 18MB. The minimum is 1MB.
</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>
+ The following example illustrates how memory is used for a
+ table. Consider this table definition:
+ </para>
+
<programlisting>
CREATE TABLE example (
a INT NOT NULL,
@@ -3141,96 +3150,86 @@
) ENGINE=NDBCLUSTER;
</programlisting>
- <para>
- There are 12 bytes overhead (having no nullable columns
- saves 4 bytes of overhead) plus 12 bytes of data per
- record. In addition we have two ordered indexes on columns
- <literal>a</literal> and <literal>b</literal> consuming
- roughly 10 bytes each per record. There is a primary key
- hash index on the base table using roughly 29 bytes per
- record. The unique constraint is implemented by a separate
- table with <literal>b</literal> as primary key and
- <literal>a</literal> as a column. This table will consume
- an additional 29 bytes of index memory per record in the
- <literal>example</literal> table as well as 12 bytes of
- overhead, plus 8 bytes of record data.
- </para>
+ <para>
+ There are 12 bytes overhead (having no nullable columns saves
+ 4 bytes of overhead) plus 12 bytes of data per record. In
+ addition we have two ordered indexes on columns
+ <literal>a</literal> and <literal>b</literal> consuming
+ roughly 10 bytes each per record. There is a primary key hash
+ index on the base table using roughly 29 bytes per record. The
+ unique constraint is implemented by a separate table with
+ <literal>b</literal> as primary key and <literal>a</literal>
+ as a column. This table will consume an additional 29 bytes of
+ index memory per record in the <literal>example</literal>
+ table as well as 12 bytes of overhead, plus 8 bytes of record
+ data.
+ </para>
- <para>
- Thus, for one million records, we need 58MB for index
- memory to handle the hash indexes for the primary key and
- the unique constraint. We also need 64MB for the records
- of the base table and the unique index table, plus the two
- ordered index tables.
- </para>
+ <para>
+ Thus, for one million records, we need 58MB for index memory
+ to handle the hash indexes for the primary key and the unique
+ constraint. We also need 64MB for the records of the base
+ table and the unique index table, plus the two ordered index
+ tables.
+ </para>
- <para>
- You can see that hash indexes takes up a fair amount of
- memory space; however, they provide very fast access to
- the data in return. They are also used in MySQL Cluster to
- handle uniqueness constraints.
- </para>
+ <para>
+ You can see that hash indexes takes up a fair amount of memory
+ space; however, they provide very fast access to the data in
+ return. They are also used in MySQL Cluster to handle
+ uniqueness constraints.
+ </para>
- <remark role="todo">
- [js] Still true in 5.0?
- </remark>
+ <remark role="todo">
+ [js] Still true in 5.0?
+ </remark>
- <para>
- Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered
- indexes cannot be used to handle uniqueness constraints in
- the general case.
- </para>
+ <para>
+ Currently, the only partitioning algorithm is hashing and
+ ordered indexes are local to each node. Thus ordered indexes
+ cannot be used to handle uniqueness constraints in the general
+ case.
+ </para>
- <para>
- An important point for both <literal>IndexMemory</literal>
- and <literal>DataMemory</literal> is that the total
- database size is the sum of all data memory and all index
- memory for each node group. Each node group is used to
- store replicated information, so if there are four nodes
- with two replicas, there will be two node groups. Thus,
- the total data memory available is 2 ×
- <literal>DataMemory</literal> for each data node.
- </para>
+ <para>
+ An important point for both <literal>IndexMemory</literal> and
+ <literal>DataMemory</literal> is that the total database size
+ is the sum of all data memory and all index memory for each
+ node group. Each node group is used to store replicated
+ information, so if there are four nodes with two replicas,
+ there will be two node groups. Thus, the total data memory
+ available is 2 × <literal>DataMemory</literal> for each
+ data node.
+ </para>
- <para>
- It is highly recommended that
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> be set to the same values
- for all nodes. Data distribution is even over all nodes in
- the cluster, so the maximum amount of space available for
- any node can be no greater than that of the smallest node
- in the cluster.
- </para>
+ <para>
+ It is highly recommended that <literal>DataMemory</literal>
+ and <literal>IndexMemory</literal> be set to the same values
+ for all nodes. Data distribution is even over all nodes in the
+ cluster, so the maximum amount of space available for any node
+ can be no greater than that of the smallest node in the
+ cluster.
+ </para>
- <para>
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal> can be changed, but
- decreasing either of these can be risky; doing so can
- easily lead to a node or even an entire MySQL Cluster that
- is unable to restart due to there being insufficient
- memory space. Increasing these values should be
- acceptable, but it is recommended that such upgrades are
- performed in the same manner as a software upgrade,
- beginning with an update of the configuration file, and
- then restarting the management server followed by
- restarting each data node in turn.
- </para>
+ <para>
+ <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal> can be changed, but decreasing
+ either of these can be risky; doing so can easily lead to a
+ node or even an entire MySQL Cluster that is unable to restart
+ due to there being insufficient memory space. Increasing these
+ values should be acceptable, but it is recommended that such
+ upgrades are performed in the same manner as a software
+ upgrade, beginning with an update of the configuration file,
+ and then restarting the management server followed by
+ restarting each data node in turn.
+ </para>
- <para>
- Updates do not increase the amount of index memory used.
- Inserts take effect immediately; however, rows are not
- actually deleted until the transaction is committed.
- </para>
+ <para>
+ Updates do not increase the amount of index memory used.
+ Inserts take effect immediately; however, rows are not
+ actually deleted until the transaction is committed.
+ </para>
- <para>
- The default value for <literal>IndexMemory</literal> is
- 18MB. The minimum is 1MB.
- </para>
- </listitem>
-
- </itemizedlist>
-
<para>
<emphasis role="bold">Transaction Parameters</emphasis>
</para>
@@ -5126,7 +5125,7 @@
<listitem>
<para>
- <literal>[TCP]ReceiveBufferMemory</literal>
+ <literal>ReceiveBufferMemory</literal>
</para>
<para>
@@ -6448,7 +6447,7 @@
</orderedlist>
<para>
- Once each data node has been initialized, the cluster startup
+ After each data node has been initialized, the cluster startup
process can proceed. The stages which the cluster goes through
during this process are listed here:
</para>
@@ -6461,7 +6460,7 @@
</para>
<para>
- Clear the cluster filesystem. This occurs
+ Clear the cluster filesystem. This stage occurs
<emphasis>only</emphasis> if the cluster was started with
the <literal>--initial</literal> option.
</para>
@@ -6473,8 +6472,9 @@
</para>
<para>
- Cluster connections are set up; inter-node communications
- are established. Cluster heartbeats are started.
+ This stage sets up Cluster connections, establishes
+ inter-node communications are established, and starts
+ Cluster heartbeats.
</para>
</listitem>
@@ -6484,13 +6484,10 @@
</para>
<para>
- The arbitrator node is elected.
+ The arbitrator node is elected. If this is a system restart,
+ the cluster determines the latest restorable global
+ checkpoint.
</para>
-
- <para>
- If this is a system restart, the cluster determines the
- latest restorable global checkpoint.
- </para>
</listitem>
<listitem>
@@ -6499,8 +6496,8 @@
</para>
<para>
- This stage consists of the initialization of a number of
- internal cluster variables.
+ This stage initializes a number of internal cluster
+ variables.
</para>
</listitem>
@@ -6562,7 +6559,7 @@
For a node restart or an initial node restart:
</para>
- <itemizedlist>
+ <orderedlist>
<listitem>
<para>
@@ -6572,8 +6569,8 @@
<listitem>
<para>
- The node's schema is compared with the master'
- and synchronized with it.
+ The node schema is compared with that of the master and
+ synchronized with it.
</para>
</listitem>
@@ -6592,7 +6589,7 @@
</para>
</listitem>
- </itemizedlist>
+ </orderedlist>
</listitem>
<listitem>
@@ -6662,9 +6659,9 @@
</itemizedlist>
<para>
- Once this process is completed for an initial start or system
- restart, handling of transactions is enabled. For a node restart
- or initial node restart, completion of the startup process means
+ After this process is completed for an initial start or system
+ restart, transactions handling is enabled. For a node restart or
+ initial node restart, completion of the startup process means
that the node may now act as a transaction coordinator.
</para>
@@ -6682,6 +6679,13 @@
</para>
<para>
+ Commands for the event logs are given in
+ <xref linkend="mysql-cluster-event-reports"/>. commands for
+ creating backups and restoring from backup are provided in
+ <xref linkend="mysql-cluster-backup"/>.
+ </para>
+
+ <para>
The management client has the following basic commands. In the
listing that follows, <replaceable>node_id</replaceable> denotes
either a database node ID or the keyword <literal>ALL</literal>,
@@ -6815,12 +6819,6 @@
</itemizedlist>
- <para>
- Commands for the event logs are given in the next section;
- commands for creating backups and restoring from backup are
- provided in a separate section on these topics.
- </para>
-
</section>
<section id="mysql-cluster-event-reports">
@@ -6848,7 +6846,7 @@
</para>
<para>
- Both sorts of event logs can be set to log different subsets of
+ Both types of event logs can be set to log different subsets of
events.
</para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1160 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 1 Feb |
