Author: paul
Date: 2006-02-01 03:02:30 +0100 (Wed, 01 Feb 2006)
New Revision: 1161
Log:
r7014@frost: paul | 2006-01-31 20:02:19 -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:7012
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2749
+ b5ec3a16-e900-0410-9ad2-d183a3acac99:/mysqldoc-local/mysqldoc/trunk:7014
bf112a9c-6c03-0410-a055-ad865cd57414:/mysqldoc-local/mysqldoc/trunk:2749
Modified: trunk/refman-4.1/ndbcluster.xml
===================================================================
--- trunk/refman-4.1/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
+++ trunk/refman-4.1/ndbcluster.xml 2006-02-01 02:02:30 UTC (rev 1161)
@@ -3157,18 +3157,18 @@
</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
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of
+ overhead. 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.
+ as a column. This other table consumes an additional 29 bytes
+ of index memory per record in the <literal>example</literal>
+ table as well 8 bytes of record data plus 12 bytes of
+ overhead.
</para>
<para>
@@ -3188,7 +3188,7 @@
<para>
Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered indexes
+ ordered indexes are local to each node. Thus, ordered indexes
cannot be used to handle uniqueness constraints in the general
case.
</para>
@@ -3242,7 +3242,7 @@
parallel transactions and the sizes of transactions that can
be handled by the system.
<literal>MaxNoOfConcurrentTransactions</literal> sets the
- number of parallel transactions possible in a node;
+ number of parallel transactions possible in a node.
<literal>MaxNoOfConcurrentOperations</literal> sets the number
of records that can be in update phase or locked
simultaneously.
@@ -3267,7 +3267,7 @@
<para>
For each active transaction in the cluster there must be a
record in one of the cluster nodes. The task of
- coordinating transactions is spread among the nodes: the
+ coordinating transactions is spread among the nodes. The
total number of transaction records in the cluster is the
number of transactions in any given node times the number
of nodes in the cluster.
@@ -3295,7 +3295,7 @@
<para>
Changing this parameter is never safe and doing so can
- cause a cluster to crash. When a node crashes one of the
+ cause a cluster to crash. When a node crashes, one of the
nodes (actually the oldest surviving node) will build up
the transaction state of all transactions ongoing in the
crashed node at the time of the crash. It is thus
@@ -3335,7 +3335,7 @@
This parameter should be set to the number of records to
be updated simultaneously in transactions, divided by the
number of cluster data nodes. For example, in a cluster
- which has 4 data nodes and which is expected to handle
+ which has four data nodes and which is expected to handle
1,000,000 concurrent updates using transactions, you
should set this value to 1000000 / 4 = 250000.
</para>
@@ -3368,17 +3368,17 @@
</para>
<para>
- A very large transaction performed on an 8-node cluster
- requires as many operation records in the transaction
- coordinator as there are reads, updates, and deletes
- involved in the transaction. However, the operation
- records of the are spread over all 8 nodes. Thus, if it is
- necessary to configure the system for one very large
- transaction, it is a good idea to configure the two parts
- separately. <literal>MaxNoOfConcurrentOperations</literal>
- will always be used to calculate the number of operation
- records in the transaction coordinator portion of the
- node.
+ A very large transaction performed on an eight-node
+ cluster requires as many operation records in the
+ transaction coordinator as there are reads, updates, and
+ deletes involved in the transaction. However, the
+ operation records of the are spread over all eight nodes.
+ Thus, if it is necessary to configure the system for one
+ very large transaction, it is a good idea to configure the
+ two parts separately.
+ <literal>MaxNoOfConcurrentOperations</literal> will always
+ be used to calculate the number of operation records in
+ the transaction coordinator portion of the node.
</para>
<para>
@@ -3395,7 +3395,7 @@
<para>
By default, this parameter is calculated as 1.1 ×
- <literal>MaxNoOfConcurrentOperations</literal> which fits
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
systems with many simultaneous transactions, none of them
being very large. If there is a need to handle one very
large transaction at a time and there are many nodes, it
@@ -3412,19 +3412,19 @@
<para>
The next set of <literal>[NDBD]</literal> parameters is used
- to determine temporary storage when executing a query which is
- part of a Cluster transaction. All records are released when
- the query is completed and the cluster is waiting for the
- commit or rollback.
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
</para>
<para>
The default values for these parameters are adequate for most
situations. However, users with a need to support transactions
involving large numbers of rows or operations may need to
- increase these to enable better parallelism in the system,
- while users whose applications require relatively small
- transactions can decrease the values to save memory.
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
</para>
<itemizedlist>
@@ -3435,14 +3435,14 @@
</para>
<para>
- For queries using a unique hash index another, temporary
+ For queries using a unique hash index, another temporary
set of operation records is used during a query's
execution phase. This parameter sets the size of that pool
- of records. Thus this record is only allocated while
- executing a part of a query, as soon as this part has been
- executed the record is released. The state needed to
+ of records. Thus, this record is allocated only while
+ executing a part of a query. As soon as this part has been
+ executed, the record is released. The state needed to
handle aborts and commits is handled by the normal
- operation records where the pool size is set by the
+ operation records, where the pool size is set by the
parameter <literal>MaxNoOfConcurrentOperations</literal>.
</para>
@@ -3477,7 +3477,7 @@
or a delete in the index table. The resulting record is
used to represent this index table operation while waiting
for the original operation that fired it to complete. This
- operation is short lived but can still require a large
+ operation is short-lived but can still require a large
number of records in its pool for situations with many
parallel write operations on a base table containing a set
of unique hash indexes.
@@ -3503,11 +3503,11 @@
whose usage is even more short-lived. The compile-time
parameter <literal>ZATTRBUF_FILESIZE</literal> (found in
<filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
- set to 4000*128 bytes (500KB). A similar buffer for key
- info, <literal>ZDATABUF_FILESIZE</literal> (also in
- <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
- 62.5KB of buffer space. <literal>Dbtc</literal> is the
- module which handles transaction coordination.
+ set to 4000 × 128 bytes (500KB). A similar buffer
+ for key info, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16
+ = 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
</para>
</listitem>
@@ -3523,9 +3523,9 @@
There are additional <literal>[NDBD]</literal> parameters in
the <literal>Dblqh</literal> module (in
<filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
- which affect reads and updates. These include
+ that affect reads and updates. These include
<literal>ZATTRINBUF_FILESIZE</literal>, set by default to
- 10000*128 bytes (1250KB) and
+ 10000 × 128 bytes (1250KB) and
<literal>ZDATABUF_FILE_SIZE</literal>, set by default to
10000*16 bytes (roughly 156KB) of buffer space. To date,
there have been neither any reports from users nor any
@@ -3602,8 +3602,8 @@
<para>
This parameter is used to calculate the number of lock
- records which needs to be there to handle many concurrent
- scan operations.
+ records which must be there to handle many concurrent scan
+ operations.
</para>
<remark role="todo">
@@ -3626,7 +3626,7 @@
This is an internal buffer used for passing messages
within individual nodes and between nodes. Although it is
highly unlikely that this would need to be changed, it is
- configurable. By default it is set to 1MB.
+ configurable. By default, it is set to 1MB.
</para>
</listitem>
@@ -3653,9 +3653,9 @@
REDO log files are organized in a ring. It is extremely
important that the first and last log files (sometimes
referred to as the <quote>head</quote> and
- <quote>tail</quote> log files, respectively) do not meet;
- when these approach one another too closely, the node will
- begin aborting all transactions encompassing updates due
+ <quote>tail</quote> log files, respectively) do not meet.
+ When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due
to a lack of room for new log records.
</para>
@@ -3693,9 +3693,9 @@
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
tail cannot be cut without jeopardizing recovery, all
- updating transactions will be aborted with internal error
- code 410, or <literal>Out of log file space
- temporarily</literal>. This condition will prevail until a
+ updating transactions are aborted with internal error code
+ 410, or <literal>Out of log file space
+ temporarily</literal>. This condition prevails until a
checkpoint has completed and the log tail can be moved
forward.
</para>
@@ -3714,7 +3714,7 @@
<para>
This parameter sets a ceiling on how many internal threads
- will be allocated for open files. <emphasis>Any situation
+ to allocate for open files. <emphasis>Any situation
requiring a change in this parameter should be reported as a
bug</emphasis>.
</para>
@@ -3732,7 +3732,7 @@
<para>
This parameter sets the maximum number of trace files that
- will be kept before overwriting old ones. Trace files are
+ are kept before overwriting old ones. Trace files are
generated when, for whatever reason, the node crashes.
</para>
@@ -3787,15 +3787,15 @@
are used. For example, if a table requires 100 attributes,
and you want to be able to alter it later, you need to set
the value of <literal>MaxNoOfAttributes</literal> to 300.
- A good rule of thumb is that, if you can create all
- desired tables without any problems, add 2 times the
+ Assuming that you can create all desired tables without
+ any problems, a good rule of thumb is to add two times the
number of attributes in the largest table to
<literal>MaxNoOfAttributes</literal> to be sure. You
should also verify that this number is sufficient by
trying an actual <literal>ALTER TABLE</literal> after
- doing so. If this is not successful, increase
- <literal>MaxNoOfAttributes</literal> by another multiple
- of the original value and test it again.
+ configuring the parameter. If this is not successful,
+ increase <literal>MaxNoOfAttributes</literal> by another
+ multiple of the original value and test it again.
</para>
</listitem>
@@ -3833,9 +3833,9 @@
<para>
For each ordered index in the cluster, an object is
allocated describing what is being indexed and its storage
- segments. By default each index so defined also defines an
- ordered index. Each unique index and primary key has both
- an ordered index and a hash index.
+ segments. By default, each index so defined also defines
+ an ordered index. Each unique index and primary key has
+ both an ordered index and a hash index.
</para>
<para>
@@ -3852,10 +3852,10 @@
<para>
For each unique index that is not a primary key, a special
table is allocated that maps the unique key to the primary
- key of the indexed table. By default there an ordered
- index is also defined for each unique index. To prevent
- this, you must use the <literal>USING HASH</literal>
- option when defining the unique index.
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
</para>
<para>
@@ -3871,11 +3871,11 @@
<para>
Internal update, insert, and delete triggers are allocated
- for each unique hash index. (This means that 3 triggers
- are created for each unique hash index.) However, an
- <emphasis>ordered</emphasis> index requires only a single
- trigger object. Backups also use three trigger objects for
- each normal table in the cluster.
+ for each unique hash index. (This means that three
+ triggers are created for each unique hash index.) However,
+ an <emphasis>ordered</emphasis> index requires only a
+ single trigger object. Backups also use three trigger
+ objects for each normal table in the cluster.
</para>
<para>
Modified: trunk/refman-5.0/ndbcluster.xml
===================================================================
--- trunk/refman-5.0/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
+++ trunk/refman-5.0/ndbcluster.xml 2006-02-01 02:02:30 UTC (rev 1161)
@@ -3153,18 +3153,18 @@
</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
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of
+ overhead. 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.
+ as a column. This other table consumes an additional 29 bytes
+ of index memory per record in the <literal>example</literal>
+ table as well 8 bytes of record data plus 12 bytes of
+ overhead.
</para>
<para>
@@ -3188,7 +3188,7 @@
<para>
Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered indexes
+ ordered indexes are local to each node. Thus, ordered indexes
cannot be used to handle uniqueness constraints in the general
case.
</para>
@@ -3242,7 +3242,7 @@
parallel transactions and the sizes of transactions that can
be handled by the system.
<literal>MaxNoOfConcurrentTransactions</literal> sets the
- number of parallel transactions possible in a node;
+ number of parallel transactions possible in a node.
<literal>MaxNoOfConcurrentOperations</literal> sets the number
of records that can be in update phase or locked
simultaneously.
@@ -3267,7 +3267,7 @@
<para>
For each active transaction in the cluster there must be a
record in one of the cluster nodes. The task of
- coordinating transactions is spread among the nodes: the
+ coordinating transactions is spread among the nodes. The
total number of transaction records in the cluster is the
number of transactions in any given node times the number
of nodes in the cluster.
@@ -3295,7 +3295,7 @@
<para>
Changing this parameter is never safe and doing so can
- cause a cluster to crash. When a node crashes one of the
+ cause a cluster to crash. When a node crashes, one of the
nodes (actually the oldest surviving node) will build up
the transaction state of all transactions ongoing in the
crashed node at the time of the crash. It is thus
@@ -3335,7 +3335,7 @@
This parameter should be set to the number of records to
be updated simultaneously in transactions, divided by the
number of cluster data nodes. For example, in a cluster
- which has 4 data nodes and which is expected to handle
+ which has four data nodes and which is expected to handle
1,000,000 concurrent updates using transactions, you
should set this value to 1000000 / 4 = 250000.
</para>
@@ -3368,17 +3368,17 @@
</para>
<para>
- A very large transaction performed on an 8-node cluster
- requires as many operation records in the transaction
- coordinator as there are reads, updates, and deletes
- involved in the transaction. However, the operation
- records of the are spread over all 8 nodes. Thus, if it is
- necessary to configure the system for one very large
- transaction, it is a good idea to configure the two parts
- separately. <literal>MaxNoOfConcurrentOperations</literal>
- will always be used to calculate the number of operation
- records in the transaction coordinator portion of the
- node.
+ A very large transaction performed on an eight-node
+ cluster requires as many operation records in the
+ transaction coordinator as there are reads, updates, and
+ deletes involved in the transaction. However, the
+ operation records of the are spread over all eight nodes.
+ Thus, if it is necessary to configure the system for one
+ very large transaction, it is a good idea to configure the
+ two parts separately.
+ <literal>MaxNoOfConcurrentOperations</literal> will always
+ be used to calculate the number of operation records in
+ the transaction coordinator portion of the node.
</para>
<para>
@@ -3395,7 +3395,7 @@
<para>
By default, this parameter is calculated as 1.1 ×
- <literal>MaxNoOfConcurrentOperations</literal> which fits
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
systems with many simultaneous transactions, none of them
being very large. If there is a need to handle one very
large transaction at a time and there are many nodes, it
@@ -3412,19 +3412,19 @@
<para>
The next set of <literal>[NDBD]</literal> parameters is used
- to determine temporary storage when executing a query which is
- part of a Cluster transaction. All records are released when
- the query is completed and the cluster is waiting for the
- commit or rollback.
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
</para>
<para>
The default values for these parameters are adequate for most
situations. However, users with a need to support transactions
involving large numbers of rows or operations may need to
- increase these to enable better parallelism in the system,
- while users whose applications require relatively small
- transactions can decrease the values to save memory.
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
</para>
<itemizedlist>
@@ -3435,14 +3435,14 @@
</para>
<para>
- For queries using a unique hash index another, temporary
+ For queries using a unique hash index, another temporary
set of operation records is used during a query's
execution phase. This parameter sets the size of that pool
- of records. Thus this record is only allocated while
- executing a part of a query, as soon as this part has been
- executed the record is released. The state needed to
+ of records. Thus, this record is allocated only while
+ executing a part of a query. As soon as this part has been
+ executed, the record is released. The state needed to
handle aborts and commits is handled by the normal
- operation records where the pool size is set by the
+ operation records, where the pool size is set by the
parameter <literal>MaxNoOfConcurrentOperations</literal>.
</para>
@@ -3477,7 +3477,7 @@
or a delete in the index table. The resulting record is
used to represent this index table operation while waiting
for the original operation that fired it to complete. This
- operation is short lived but can still require a large
+ operation is short-lived but can still require a large
number of records in its pool for situations with many
parallel write operations on a base table containing a set
of unique hash indexes.
@@ -3507,11 +3507,11 @@
whose usage is even more short-lived. The compile-time
parameter <literal>ZATTRBUF_FILESIZE</literal> (found in
<filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
- set to 4000*128 bytes (500KB). A similar buffer for key
- info, <literal>ZDATABUF_FILESIZE</literal> (also in
- <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
- 62.5KB of buffer space. <literal>Dbtc</literal> is the
- module which handles transaction coordination.
+ set to 4000 × 128 bytes (500KB). A similar buffer
+ for key info, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16
+ = 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
</para>
</listitem>
@@ -3527,9 +3527,9 @@
There are additional <literal>[NDBD]</literal> parameters in
the <literal>Dblqh</literal> module (in
<filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
- which affect reads and updates. These include
+ that affect reads and updates. These include
<literal>ZATTRINBUF_FILESIZE</literal>, set by default to
- 10000*128 bytes (1250KB) and
+ 10000 × 128 bytes (1250KB) and
<literal>ZDATABUF_FILE_SIZE</literal>, set by default to
10000*16 bytes (roughly 156KB) of buffer space. To date,
there have been neither any reports from users nor any
@@ -3606,8 +3606,8 @@
<para>
This parameter is used to calculate the number of lock
- records which needs to be there to handle many concurrent
- scan operations.
+ records which must be there to handle many concurrent scan
+ operations.
</para>
<remark role="todo">
@@ -3630,7 +3630,7 @@
This is an internal buffer used for passing messages
within individual nodes and between nodes. Although it is
highly unlikely that this would need to be changed, it is
- configurable. By default it is set to 1MB.
+ configurable. By default, it is set to 1MB.
</para>
</listitem>
@@ -3657,9 +3657,9 @@
REDO log files are organized in a ring. It is extremely
important that the first and last log files (sometimes
referred to as the <quote>head</quote> and
- <quote>tail</quote> log files, respectively) do not meet;
- when these approach one another too closely, the node will
- begin aborting all transactions encompassing updates due
+ <quote>tail</quote> log files, respectively) do not meet.
+ When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due
to a lack of room for new log records.
</para>
@@ -3697,9 +3697,9 @@
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
tail cannot be cut without jeopardizing recovery, all
- updating transactions will be aborted with internal error
- code 410, or <literal>Out of log file space
- temporarily</literal>. This condition will prevail until a
+ updating transactions are aborted with internal error code
+ 410, or <literal>Out of log file space
+ temporarily</literal>. This condition prevails until a
checkpoint has completed and the log tail can be moved
forward.
</para>
@@ -3718,7 +3718,7 @@
<para>
This parameter sets a ceiling on how many internal threads
- will be allocated for open files. <emphasis>Any situation
+ to allocate for open files. <emphasis>Any situation
requiring a change in this parameter should be reported as a
bug</emphasis>.
</para>
@@ -3736,7 +3736,7 @@
<para>
This parameter sets the maximum number of trace files that
- will be kept before overwriting old ones. Trace files are
+ are kept before overwriting old ones. Trace files are
generated when, for whatever reason, the node crashes.
</para>
@@ -3791,15 +3791,15 @@
are used. For example, if a table requires 100 attributes,
and you want to be able to alter it later, you need to set
the value of <literal>MaxNoOfAttributes</literal> to 300.
- A good rule of thumb is that, if you can create all
- desired tables without any problems, add 2 times the
+ Assuming that you can create all desired tables without
+ any problems, a good rule of thumb is to add two times the
number of attributes in the largest table to
<literal>MaxNoOfAttributes</literal> to be sure. You
should also verify that this number is sufficient by
trying an actual <literal>ALTER TABLE</literal> after
- doing so. If this is not successful, increase
- <literal>MaxNoOfAttributes</literal> by another multiple
- of the original value and test it again.
+ configuring the parameter. If this is not successful,
+ increase <literal>MaxNoOfAttributes</literal> by another
+ multiple of the original value and test it again.
</para>
</listitem>
@@ -3837,9 +3837,9 @@
<para>
For each ordered index in the cluster, an object is
allocated describing what is being indexed and its storage
- segments. By default each index so defined also defines an
- ordered index. Each unique index and primary key has both
- an ordered index and a hash index.
+ segments. By default, each index so defined also defines
+ an ordered index. Each unique index and primary key has
+ both an ordered index and a hash index.
</para>
<para>
@@ -3856,10 +3856,10 @@
<para>
For each unique index that is not a primary key, a special
table is allocated that maps the unique key to the primary
- key of the indexed table. By default there an ordered
- index is also defined for each unique index. To prevent
- this, you must use the <literal>USING HASH</literal>
- option when defining the unique index.
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
</para>
<para>
@@ -3875,11 +3875,11 @@
<para>
Internal update, insert, and delete triggers are allocated
- for each unique hash index. (This means that 3 triggers
- are created for each unique hash index.) However, an
- <emphasis>ordered</emphasis> index requires only a single
- trigger object. Backups also use three trigger objects for
- each normal table in the cluster.
+ for each unique hash index. (This means that three
+ triggers are created for each unique hash index.) However,
+ an <emphasis>ordered</emphasis> index requires only a
+ single trigger object. Backups also use three trigger
+ objects for each normal table in the cluster.
</para>
<para>
Modified: trunk/refman-5.1/ndbcluster.xml
===================================================================
--- trunk/refman-5.1/ndbcluster.xml 2006-02-01 01:39:33 UTC (rev 1160)
+++ trunk/refman-5.1/ndbcluster.xml 2006-02-01 02:02:30 UTC (rev 1161)
@@ -3151,18 +3151,18 @@
</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
+ For each record, there are 12 bytes of data plus 12 bytes
+ overhead. Having no nullable columns saves 4 bytes of
+ overhead. 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.
+ as a column. This other table consumes an additional 29 bytes
+ of index memory per record in the <literal>example</literal>
+ table as well 8 bytes of record data plus 12 bytes of
+ overhead.
</para>
<para>
@@ -3186,7 +3186,7 @@
<para>
Currently, the only partitioning algorithm is hashing and
- ordered indexes are local to each node. Thus ordered indexes
+ ordered indexes are local to each node. Thus, ordered indexes
cannot be used to handle uniqueness constraints in the general
case.
</para>
@@ -3240,7 +3240,7 @@
parallel transactions and the sizes of transactions that can
be handled by the system.
<literal>MaxNoOfConcurrentTransactions</literal> sets the
- number of parallel transactions possible in a node;
+ number of parallel transactions possible in a node.
<literal>MaxNoOfConcurrentOperations</literal> sets the number
of records that can be in update phase or locked
simultaneously.
@@ -3265,7 +3265,7 @@
<para>
For each active transaction in the cluster there must be a
record in one of the cluster nodes. The task of
- coordinating transactions is spread among the nodes: the
+ coordinating transactions is spread among the nodes. The
total number of transaction records in the cluster is the
number of transactions in any given node times the number
of nodes in the cluster.
@@ -3293,7 +3293,7 @@
<para>
Changing this parameter is never safe and doing so can
- cause a cluster to crash. When a node crashes one of the
+ cause a cluster to crash. When a node crashes, one of the
nodes (actually the oldest surviving node) will build up
the transaction state of all transactions ongoing in the
crashed node at the time of the crash. It is thus
@@ -3333,7 +3333,7 @@
This parameter should be set to the number of records to
be updated simultaneously in transactions, divided by the
number of cluster data nodes. For example, in a cluster
- which has 4 data nodes and which is expected to handle
+ which has four data nodes and which is expected to handle
1,000,000 concurrent updates using transactions, you
should set this value to 1000000 / 4 = 250000.
</para>
@@ -3366,17 +3366,17 @@
</para>
<para>
- A very large transaction performed on an 8-node cluster
- requires as many operation records in the transaction
- coordinator as there are reads, updates, and deletes
- involved in the transaction. However, the operation
- records of the are spread over all 8 nodes. Thus, if it is
- necessary to configure the system for one very large
- transaction, it is a good idea to configure the two parts
- separately. <literal>MaxNoOfConcurrentOperations</literal>
- will always be used to calculate the number of operation
- records in the transaction coordinator portion of the
- node.
+ A very large transaction performed on an eight-node
+ cluster requires as many operation records in the
+ transaction coordinator as there are reads, updates, and
+ deletes involved in the transaction. However, the
+ operation records of the are spread over all eight nodes.
+ Thus, if it is necessary to configure the system for one
+ very large transaction, it is a good idea to configure the
+ two parts separately.
+ <literal>MaxNoOfConcurrentOperations</literal> will always
+ be used to calculate the number of operation records in
+ the transaction coordinator portion of the node.
</para>
<para>
@@ -3393,7 +3393,7 @@
<para>
By default, this parameter is calculated as 1.1 ×
- <literal>MaxNoOfConcurrentOperations</literal> which fits
+ <literal>MaxNoOfConcurrentOperations</literal>. This fits
systems with many simultaneous transactions, none of them
being very large. If there is a need to handle one very
large transaction at a time and there are many nodes, it
@@ -3410,19 +3410,19 @@
<para>
The next set of <literal>[NDBD]</literal> parameters is used
- to determine temporary storage when executing a query which is
- part of a Cluster transaction. All records are released when
- the query is completed and the cluster is waiting for the
- commit or rollback.
+ to determine temporary storage when executing a statement that
+ is part of a Cluster transaction. All records are released
+ when the statement is completed and the cluster is waiting for
+ the commit or rollback.
</para>
<para>
The default values for these parameters are adequate for most
situations. However, users with a need to support transactions
involving large numbers of rows or operations may need to
- increase these to enable better parallelism in the system,
- while users whose applications require relatively small
- transactions can decrease the values to save memory.
+ increase these values to enable better parallelism in the
+ system, whereas users whose applications require relatively
+ small transactions can decrease the values to save memory.
</para>
<itemizedlist>
@@ -3433,14 +3433,14 @@
</para>
<para>
- For queries using a unique hash index another, temporary
+ For queries using a unique hash index, another temporary
set of operation records is used during a query's
execution phase. This parameter sets the size of that pool
- of records. Thus this record is only allocated while
- executing a part of a query, as soon as this part has been
- executed the record is released. The state needed to
+ of records. Thus, this record is allocated only while
+ executing a part of a query. As soon as this part has been
+ executed, the record is released. The state needed to
handle aborts and commits is handled by the normal
- operation records where the pool size is set by the
+ operation records, where the pool size is set by the
parameter <literal>MaxNoOfConcurrentOperations</literal>.
</para>
@@ -3475,7 +3475,7 @@
or a delete in the index table. The resulting record is
used to represent this index table operation while waiting
for the original operation that fired it to complete. This
- operation is short lived but can still require a large
+ operation is short-lived but can still require a large
number of records in its pool for situations with many
parallel write operations on a base table containing a set
of unique hash indexes.
@@ -3505,11 +3505,11 @@
whose usage is even more short-lived. The compile-time
parameter <literal>ZATTRBUF_FILESIZE</literal> (found in
<filename>ndb/src/kernel/blocks/Dbtc/Dbtc.hpp</filename>)
- set to 4000*128 bytes (500KB). A similar buffer for key
- info, <literal>ZDATABUF_FILESIZE</literal> (also in
- <filename>Dbtc.hpp</filename>) contains 4000 × 16 =
- 62.5KB of buffer space. <literal>Dbtc</literal> is the
- module which handles transaction coordination.
+ set to 4000 × 128 bytes (500KB). A similar buffer
+ for key info, <literal>ZDATABUF_FILESIZE</literal> (also
+ in <filename>Dbtc.hpp</filename>) contains 4000 × 16
+ = 62.5KB of buffer space. <literal>Dbtc</literal> is the
+ module that handles transaction coordination.
</para>
</listitem>
@@ -3525,9 +3525,9 @@
There are additional <literal>[NDBD]</literal> parameters in
the <literal>Dblqh</literal> module (in
<filename>ndb/src/kernel/blocks/Dblqh/Dblqh.hpp</filename>)
- which affect reads and updates. These include
+ that affect reads and updates. These include
<literal>ZATTRINBUF_FILESIZE</literal>, set by default to
- 10000*128 bytes (1250KB) and
+ 10000 × 128 bytes (1250KB) and
<literal>ZDATABUF_FILE_SIZE</literal>, set by default to
10000*16 bytes (roughly 156KB) of buffer space. To date,
there have been neither any reports from users nor any
@@ -3604,8 +3604,8 @@
<para>
This parameter is used to calculate the number of lock
- records which needs to be there to handle many concurrent
- scan operations.
+ records which must be there to handle many concurrent scan
+ operations.
</para>
<remark role="todo">
@@ -3628,7 +3628,7 @@
This is an internal buffer used for passing messages
within individual nodes and between nodes. Although it is
highly unlikely that this would need to be changed, it is
- configurable. By default it is set to 1MB.
+ configurable. By default, it is set to 1MB.
</para>
</listitem>
@@ -3655,9 +3655,9 @@
REDO log files are organized in a ring. It is extremely
important that the first and last log files (sometimes
referred to as the <quote>head</quote> and
- <quote>tail</quote> log files, respectively) do not meet;
- when these approach one another too closely, the node will
- begin aborting all transactions encompassing updates due
+ <quote>tail</quote> log files, respectively) do not meet.
+ When these approach one another too closely, the node
+ begins aborting all transactions encompassing updates due
to a lack of room for new log records.
</para>
@@ -3695,9 +3695,9 @@
If the checkpointing is slow and there are so many writes
to the database that the log files are full and the log
tail cannot be cut without jeopardizing recovery, all
- updating transactions will be aborted with internal error
- code 410, or <literal>Out of log file space
- temporarily</literal>. This condition will prevail until a
+ updating transactions are aborted with internal error code
+ 410, or <literal>Out of log file space
+ temporarily</literal>. This condition prevails until a
checkpoint has completed and the log tail can be moved
forward.
</para>
@@ -3716,7 +3716,7 @@
<para>
This parameter sets a ceiling on how many internal threads
- will be allocated for open files. <emphasis>Any situation
+ to allocate for open files. <emphasis>Any situation
requiring a change in this parameter should be reported as a
bug</emphasis>.
</para>
@@ -3734,7 +3734,7 @@
<para>
This parameter sets the maximum number of trace files that
- will be kept before overwriting old ones. Trace files are
+ are kept before overwriting old ones. Trace files are
generated when, for whatever reason, the node crashes.
</para>
@@ -3789,15 +3789,15 @@
are used. For example, if a table requires 100 attributes,
and you want to be able to alter it later, you need to set
the value of <literal>MaxNoOfAttributes</literal> to 300.
- A good rule of thumb is that, if you can create all
- desired tables without any problems, add 2 times the
+ Assuming that you can create all desired tables without
+ any problems, a good rule of thumb is to add two times the
number of attributes in the largest table to
<literal>MaxNoOfAttributes</literal> to be sure. You
should also verify that this number is sufficient by
trying an actual <literal>ALTER TABLE</literal> after
- doing so. If this is not successful, increase
- <literal>MaxNoOfAttributes</literal> by another multiple
- of the original value and test it again.
+ configuring the parameter. If this is not successful,
+ increase <literal>MaxNoOfAttributes</literal> by another
+ multiple of the original value and test it again.
</para>
</listitem>
@@ -3835,9 +3835,9 @@
<para>
For each ordered index in the cluster, an object is
allocated describing what is being indexed and its storage
- segments. By default each index so defined also defines an
- ordered index. Each unique index and primary key has both
- an ordered index and a hash index.
+ segments. By default, each index so defined also defines
+ an ordered index. Each unique index and primary key has
+ both an ordered index and a hash index.
</para>
<para>
@@ -3854,10 +3854,10 @@
<para>
For each unique index that is not a primary key, a special
table is allocated that maps the unique key to the primary
- key of the indexed table. By default there an ordered
- index is also defined for each unique index. To prevent
- this, you must use the <literal>USING HASH</literal>
- option when defining the unique index.
+ key of the indexed table. By default, an ordered index is
+ also defined for each unique index. To prevent this, you
+ must specify the <literal>USING HASH</literal> option when
+ defining the unique index.
</para>
<para>
@@ -3873,11 +3873,11 @@
<para>
Internal update, insert, and delete triggers are allocated
- for each unique hash index. (This means that 3 triggers
- are created for each unique hash index.) However, an
- <emphasis>ordered</emphasis> index requires only a single
- trigger object. Backups also use three trigger objects for
- each normal table in the cluster.
+ for each unique hash index. (This means that three
+ triggers are created for each unique hash index.) However,
+ an <emphasis>ordered</emphasis> index requires only a
+ single trigger object. Backups also use three trigger
+ objects for each normal table in the cluster.
</para>
<para>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r1161 - in trunk: . refman-4.1 refman-5.0 refman-5.1 | paul | 1 Feb |
