Author: js221926
Date: 2011-06-30 17:40:01 +0200 (Thu, 30 Jun 2011)
New Revision: 26654
Log:
De-gunking in 5.1 Cluster chapter
Modified:
trunk/refman-5.1/mysql-cluster-management.xml
trunk/refman-5.1/mysql-cluster-overview.xml
Modified: trunk/refman-5.1/mysql-cluster-management.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-management.xml 2011-06-30 15:23:11 UTC (rev 26653)
+++ trunk/refman-5.1/mysql-cluster-management.xml 2011-06-30 15:40:01 UTC (rev 26654)
Changed blocks: 6, Lines Added: 145, Lines Deleted: 149; 14252 bytes
@@ -6128,38 +6128,37 @@
<para>
Any of the following:
+ </para>
- <orderedlist>
+ </formalpara>
- <listitem>
- <para>
- <literal>Node
- <replaceable>node_id</replaceable>: Node
- <replaceable>node1_id</replaceable> completed
- failure of Node
- <replaceable>node2_id</replaceable></literal>
- </para>
- </listitem>
+ <orderedlist>
- <listitem>
- <para>
- <literal>All nodes completed failure of Node
- <replaceable>node_id</replaceable></literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>Node <replaceable>node_id</replaceable>:
+ Node <replaceable>node1_id</replaceable> completed
+ failure of Node
+ <replaceable>node2_id</replaceable></literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>Node failure of
- <replaceable>node_id</replaceable><replaceable>block</replaceable>
- completed</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>All nodes completed failure of Node
+ <replaceable>node_id</replaceable></literal>
+ </para>
+ </listitem>
- </orderedlist>
- </para>
+ <listitem>
+ <para>
+ <literal>Node failure of
+ <replaceable>node_id</replaceable><replaceable>block</replaceable>
+ completed</literal>
+ </para>
+ </listitem>
- </formalpara>
+ </orderedlist>
<formalpara>
@@ -6168,45 +6167,44 @@
<para>
One of the following (each corresponding to the
same-numbered message listed above):
+ </para>
- <orderedlist>
+ </formalpara>
- <listitem>
- <para>
- Data node <replaceable>node1_id</replaceable>
- has detected the failure of data node
- <replaceable>node2_id</replaceable>
- </para>
- </listitem>
+ <orderedlist>
- <listitem>
- <para>
- All (remaining) data nodes have detected the
- failure of data node
- <replaceable>node_id</replaceable>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Data node <replaceable>node1_id</replaceable> has
+ detected the failure of data node
+ <replaceable>node2_id</replaceable>
+ </para>
+ </listitem>
- <listitem>
- <para>
- The failure of data node
- <replaceable>node_id</replaceable> has been
- detected in the
- <replaceable>block</replaceable><literal role="se">NDB</literal>
- kernel block, where block is 1 of
- <literal>DBTC</literal>,
- <literal>DBDICT</literal>,
- <literal>DBDIH</literal>, or
- <literal>DBLQH</literal>; for more
- information, see
- <xref linkend="ndb-internals-kernel-blocks"/>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ All (remaining) data nodes have detected the
+ failure of data node
+ <replaceable>node_id</replaceable>
+ </para>
+ </listitem>
- </orderedlist>
- </para>
+ <listitem>
+ <para>
+ The failure of data node
+ <replaceable>node_id</replaceable> has been
+ detected in the
+ <replaceable>block</replaceable><literal role="se">NDB</literal>
+ kernel block, where block is 1 of
+ <literal>DBTC</literal>,
+ <literal>DBDICT</literal>,
+ <literal>DBDIH</literal>, or
+ <literal>DBLQH</literal>; for more information,
+ see <xref linkend="ndb-internals-kernel-blocks"/>
+ </para>
+ </listitem>
- </formalpara></entry>
+ </orderedlist></entry>
<entry><formalpara>
<title>Event Name</title>
@@ -12579,39 +12577,39 @@
<title>If the master fails:</title>
- <para>
- <itemizedlist>
+ <para></para>
- <listitem>
- <formalpara>
+ </formalpara>
- <title>If the internal commit point has been reached:</title>
+ <itemizedlist>
- <para>
- The creation of the node group is rolled
- forward.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has been reached:</title>
- <listitem>
- <formalpara>
+ <para>
+ The creation of the node group is rolled
+ forward.
+ </para>
- <title>If the internal commit point has not yet been reached</title>
+ </formalpara>
+ </listitem>
- <para>
- The creation of the node group is rolled
- back
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has not yet been reached</title>
- </itemizedlist>
- </para>
+ <para>
+ The creation of the node group is rolled
+ back
+ </para>
- </formalpara>
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
</listitem>
</itemizedlist></entry>
@@ -12635,39 +12633,39 @@
<title>If the master fails:</title>
- <para>
- <itemizedlist>
+ <para></para>
- <listitem>
- <formalpara>
+ </formalpara>
- <title>If the internal commit point has been reached:</title>
+ <itemizedlist>
- <para>
- The creation of the node group is rolled
- forward.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has been reached:</title>
- <listitem>
- <formalpara>
+ <para>
+ The creation of the node group is rolled
+ forward.
+ </para>
- <title>If the internal commit point has not yet been reached</title>
+ </formalpara>
+ </listitem>
- <para>
- The creation of the node group is rolled
- back
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has not yet been reached</title>
- </itemizedlist>
- </para>
+ <para>
+ The creation of the node group is rolled
+ back
+ </para>
- </formalpara>
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
</listitem>
</itemizedlist></entry>
@@ -12725,38 +12723,37 @@
<title>If the master fails:</title>
- <para>
- <itemizedlist>
+ <para></para>
- <listitem>
- <formalpara>
+ </formalpara>
- <title>If the internal commit point has been reached:</title>
+ <itemizedlist>
- <para>
- The table reorganization is rolled
- forward.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has been reached:</title>
- <listitem>
- <formalpara>
+ <para>
+ The table reorganization is rolled forward.
+ </para>
- <title>If the internal commit point has not yet been reached</title>
+ </formalpara>
+ </listitem>
- <para>
- The table reorganization is rolled back.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has not yet been reached</title>
- </itemizedlist>
- </para>
+ <para>
+ The table reorganization is rolled back.
+ </para>
- </formalpara>
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
</listitem>
</itemizedlist></entry>
@@ -12780,38 +12777,37 @@
<title>If the master fails:</title>
- <para>
- <itemizedlist>
+ <para></para>
- <listitem>
- <formalpara>
+ </formalpara>
- <title>If the internal commit point has been reached:</title>
+ <itemizedlist>
- <para>
- The table reorganization is rolled
- forward.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has been reached:</title>
- <listitem>
- <formalpara>
+ <para>
+ The table reorganization is rolled forward.
+ </para>
- <title>If the internal commit point has not yet been reached</title>
+ </formalpara>
+ </listitem>
- <para>
- The table reorganization is rolled back.
- </para>
+ <listitem>
+ <formalpara>
- </formalpara>
- </listitem>
+ <title>If the internal commit point has not yet been reached</title>
- </itemizedlist>
- </para>
+ <para>
+ The table reorganization is rolled back.
+ </para>
- </formalpara>
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
</listitem>
</itemizedlist></entry>
Modified: trunk/refman-5.1/mysql-cluster-overview.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-overview.xml 2011-06-30 15:23:11 UTC (rev 26653)
+++ trunk/refman-5.1/mysql-cluster-overview.xml 2011-06-30 15:40:01 UTC (rev 26654)
Changed blocks: 3, Lines Added: 138, Lines Deleted: 139; 14013 bytes
@@ -2790,65 +2790,63 @@
number of messages passed between data nodes, and between
data nodes and API nodes, which can increase MySQL Cluster
and application performance:
+ </para>
- <itemizedlist>
+ </formalpara>
- <listitem>
- <formalpara>
+ <itemizedlist>
- <title>Packed reads</title>
+ <listitem>
+ <formalpara>
- <para>
- Formerly, each read request signal contained a
- list of columns to be retrieved, each of these
- column identifiers using 4 bytes within the
- message. This meant that the message size
- increased as the number of columns being fetched
- increased. In addition, in the response from the
- data node, each column result was packed to a
- 4-byte boundary, which resulted in wasted space.
- In MySQL Cluster NDB 7.0, messaging for read
- operations is optimized in both directions, using
- a bitmap in the read request to specify the
- columns to be fetched. Where many fields are
- requested, this can result in a significant
- message size reduction as compared with the old
- method. In addition, the 4-byte packing in
- responses is no longer used, which means that
- smaller fields consume less space.
- </para>
+ <title>Packed reads</title>
- </formalpara>
- </listitem>
+ <para>
+ Formerly, each read request signal contained a list of
+ columns to be retrieved, each of these column
+ identifiers using 4 bytes within the message. This
+ meant that the message size increased as the number of
+ columns being fetched increased. In addition, in the
+ response from the data node, each column result was
+ packed to a 4-byte boundary, which resulted in wasted
+ space. In MySQL Cluster NDB 7.0, messaging for read
+ operations is optimized in both directions, using a
+ bitmap in the read request to specify the columns to
+ be fetched. Where many fields are requested, this can
+ result in a significant message size reduction as
+ compared with the old method. In addition, the 4-byte
+ packing in responses is no longer used, which means
+ that smaller fields consume less space.
+ </para>
- <listitem>
- <formalpara>
+ </formalpara>
+ </listitem>
- <title>Long signal transactions</title>
+ <listitem>
+ <formalpara>
- <para>
- This enhancement reduces the number of messages
- and signals that are sent to data nodes for
- complex requests. Prior to MySQL Cluster NDB 7.0,
- there was a 100 byte limit on the size of the
- request signal, which meant that complex requests
- had to be split up between multiple messages prior
- to transmission, then reassembled on the receiving
- end. In addition to actual payload data, each
- message required its own operating system and
- protocol overhead such as header information. This
- often wasted network bandwidth and data node CPU.
- The maximum size of the message is now 32 KB,
- which is sufficient to accommodate most queries.
- </para>
+ <title>Long signal transactions</title>
- </formalpara>
- </listitem>
+ <para>
+ This enhancement reduces the number of messages and
+ signals that are sent to data nodes for complex
+ requests. Prior to MySQL Cluster NDB 7.0, there was a
+ 100 byte limit on the size of the request signal,
+ which meant that complex requests had to be split up
+ between multiple messages prior to transmission, then
+ reassembled on the receiving end. In addition to
+ actual payload data, each message required its own
+ operating system and protocol overhead such as header
+ information. This often wasted network bandwidth and
+ data node CPU. The maximum size of the message is now
+ 32 KB, which is sufficient to accommodate most
+ queries.
+ </para>
- </itemizedlist>
- </para>
+ </formalpara>
+ </listitem>
- </formalpara>
+ </itemizedlist>
<para>
Both of these optimizations are internal to the NDB API, and
@@ -4663,53 +4661,54 @@
<literal role="stmt">ALTER TABLE</literal> is noncopying,
which means that indexes do not have to be re-created,
which provides these benefits:
+ </para>
- <itemizedlist>
+ </formalpara>
- <listitem>
- <para>
- Single user mode is no longer required for
- <literal role="stmt">ALTER TABLE</literal>
- operations that can be performed online.
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- Transactions can continue during
- <literal role="stmt">ALTER TABLE</literal>
- operations that can be performed online.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Single user mode is no longer required for
+ <literal role="stmt">ALTER TABLE</literal> operations
+ that can be performed online.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Tables being altered online are not locked against
- access by other SQL nodes.
- </para>
+ <listitem>
+ <para>
+ Transactions can continue during
+ <literal role="stmt">ALTER TABLE</literal> operations
+ that can be performed online.
+ </para>
+ </listitem>
- <para>
- However, such tables are locked against other
- operations on the <emphasis>same</emphasis> SQL node
- for the duration of the <literal role="stmt">ALTER
- TABLE</literal>. We are working to overcome this
- limitation in a future MySQL Cluster release.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Tables being altered online are not locked against
+ access by other SQL nodes.
+ </para>
- </itemizedlist>
+ <para>
+ However, such tables are locked against other operations
+ on the <emphasis>same</emphasis> SQL node for the
+ duration of the <literal role="stmt">ALTER
+ TABLE</literal>. We are working to overcome this
+ limitation in a future MySQL Cluster release.
+ </para>
+ </listitem>
- Online <literal role="stmt">CREATE INDEX</literal> and
- <literal role="stmt">DROP INDEX</literal> statements are
- also supported. Online changes can be suppressed using the
- <literal>OFFLINE</literal> key word. See
- <xref linkend="alter-table"/>,
- <xref linkend="create-index"/>, and
- <xref linkend="drop-index"/>, for more detailed
- information.
- </para>
+ </itemizedlist>
- </formalpara>
+ <para>
+ Online <literal role="stmt">CREATE INDEX</literal> and
+ <literal role="stmt">DROP INDEX</literal> statements are
+ also supported. Online changes can be suppressed using the
+ <literal>OFFLINE</literal> key word. See
+ <xref linkend="alter-table"/>,
+ <xref linkend="create-index"/>, and
+ <xref linkend="drop-index"/>, for more detailed information.
+ </para>
</listitem>
<listitem>
@@ -5168,68 +5167,68 @@
is similar in some ways to partition pruning (see
<xref linkend="partitioning-pruning"/>). To take advantage
of distribution awareness, you should do the following:
+ </para>
- <orderedlist>
+ </formalpara>
- <listitem>
- <para>
- Determine which table column is most likely to be
- used for finding matching records.
- </para>
- </listitem>
+ <orderedlist>
- <listitem>
- <para>
- Make this column part of the table's primary
- key.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Determine which table column is most likely to be used
+ for finding matching records.
+ </para>
+ </listitem>
- <listitem>
- <para>
- Explicitly partition the table by
- <literal>KEY</literal>, using this column as the
- table' partitioning key.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ Make this column part of the table's primary key.
+ </para>
+ </listitem>
- </orderedlist>
+ <listitem>
+ <para>
+ Explicitly partition the table by
+ <literal>KEY</literal>, using this column as the
+ table' partitioning key.
+ </para>
+ </listitem>
- Following these steps causes records with the same value
- for the partitioning column to be stored on the same
- partition (that is, in the same node group). When reading
- data, transactions are begun on the data node actually
- having the desired rows instead of this node being
- determined by the usual round-robin mechanism.
+ </orderedlist>
- <important>
- <para>
- To see a measureable impact on performance, the
- cluster must have at least four data nodes, since,
- with only two data nodes, both data nodes have exactly
- the same data.
- </para>
- </important>
+ <para>
+ Following these steps causes records with the same value for
+ the partitioning column to be stored on the same partition
+ (that is, in the same node group). When reading data,
+ transactions are begun on the data node actually having the
+ desired rows instead of this node being determined by the
+ usual round-robin mechanism.
+ </para>
- Using distribution awareness can yield performance
- increase of as great as 45% when using four data nodes,
- and possibly more when using a greater number of data
- nodes.
-
- <note>
- <para>
- In mainline MySQL 5.1 releases, distribution awareness
- was supported only when using the NDB API; support was
- added for SQL and API nodes in MySQL Cluster NDB 6.3
- (see
- <xref linkend="mysql-cluster-development-5-1-ndb-6-3"/>,
- which includes an example showing how to create a
- table to take advantage of distribution awareness).
- </para>
- </note>
+ <important>
+ <para>
+ To see a measureable impact on performance, the cluster
+ must have at least four data nodes, since, with only two
+ data nodes, both data nodes have exactly the same data.
</para>
+ </important>
- </formalpara>
+ <para>
+ Using distribution awareness can yield performance increase
+ of as great as 45% when using four data nodes, and possibly
+ more when using a greater number of data nodes.
+ </para>
+
+ <note>
+ <para>
+ In mainline MySQL 5.1 releases, distribution awareness was
+ supported only when using the NDB API; support was added
+ for SQL and API nodes in MySQL Cluster NDB 6.3 (see
+ <xref linkend="mysql-cluster-development-5-1-ndb-6-3"/>,
+ which includes an example showing how to create a table to
+ take advantage of distribution awareness).
+ </para>
+ </note>
</listitem>
</itemizedlist>
| Thread |
|---|
| • svn commit - mysqldoc@oter02: r26654 - trunk/refman-5.1 | jon.stephens | 4 Jul |
