Author: jstephens
Date: 2007-05-18 16:50:20 +0200 (Fri, 18 May 2007)
New Revision: 6531
Log:
Reformat.
Modified:
trunk/refman-5.0/mysql-cluster-limitations-working.xml
Modified: trunk/refman-5.0/mysql-cluster-limitations-working.xml
===================================================================
--- trunk/refman-5.0/mysql-cluster-limitations-working.xml 2007-05-18 14:49:47 UTC (rev 6530)
+++ trunk/refman-5.0/mysql-cluster-limitations-working.xml 2007-05-18 14:50:20 UTC (rev 6531)
Changed blocks: 22, Lines Added: 703, Lines Deleted: 573; 63290 bytes
@@ -8,15 +8,15 @@
<section id="mysql-cluster-limitations">
<title>Known Limitations of MySQL Cluster</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
</indexterm>
-
+
<indexterm>
<primary>limitations of MySQL Cluster</primary>
</indexterm>
-
+
<para>
In the sections that follow, we discuss known limitations in MySQL
¤t-series; Cluster and &mccge-series; releases as compared
@@ -32,7 +32,7 @@
these issues may be addressed in &mccge-series; and the fixes
included in a future mainline MySQL Cluster version.
</para>
-
+
<para>
This information is intended to be complete with respect to the
conditions just set forth. You can report any discrepancies that you
@@ -40,60 +40,58 @@
<xref linkend="bug-reports"/>. If we do not plan to fix the problem
in MySQL ¤t-series;, we will add it to the list.
</para>
-
+
<para>
See <xref linkend="mysql-cluster-limitations-resolved"/> for a list
of issues in MySQL Cluster in MySQL &previous-series; that have been
resolved in the current version.
</para>
-
-
-
+
<section id="mysql-cluster-limitations-syntax">
-
+
<title>Non-Compliance In SQL Syntax</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>syntax</secondary>
</indexterm>
-
+
<para>
Some SQL statements relating to certain MySQL features produce
errors when used with <literal>NDB</literal> tables, as described
in the following list:
-
+
<itemizedlist>
-
+
<listitem>
<formalpara>
-
+
<title>Temporary tables</title>
-
+
<para>
Temporary tables are not supported. Trying either to
create a temporary table that uses the
<literal>NDB</literal> storage engine or to alter an
existing temporary table to use <literal>NDB</literal>
fails with the error <errortext>Table storage engine
- 'ndbcluster' does not support the create option
- 'TEMPORARY'</errortext>.
+ 'ndbcluster' does not support the create option
+ 'TEMPORARY'</errortext>.
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title>Indexes and keys in <literal>NDB</literal> tables</title>
-
+
<para>
Keys and indexes on MySQL Cluster tables are subject to
the following limitations:
-
+
<itemizedlist>
-
+
<listitem>
<para>
You cannot create indexes on <literal>NDB</literal>
@@ -102,7 +100,7 @@
data types.
</para>
</listitem>
-
+
<listitem>
<para>
The <literal>NDB</literal> storage engine does not
@@ -110,14 +108,14 @@
are possible for <literal>MyISAM</literal> tables
only.
</para>
-
+
<para>
However, you can create indexes on
<literal>VARCHAR</literal> columns of
<literal>NDB</literal> tables.
</para>
</listitem>
-
+
<listitem>
<para>
A <literal>BIT</literal> column cannot be a primary
@@ -125,27 +123,27 @@
composite primary key, unique key, or index.
</para>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title>Duplicate keys</title>
-
+
<para>
A duplicate key error returns the error message
<errortext>ERROR 23000: Can't write; duplicate key
- in table
- '<replaceable>tbl_name</replaceable>'</errortext>.
+ in table
+ '<replaceable>tbl_name</replaceable>'</errortext>.
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title><literal>AUTO_INCREMENT</literal> columns</title>
-
+
<para>
Like other MySQL storage engines, the
<literal>NDB</literal> storage engine can handle a
@@ -165,132 +163,130 @@
<literal>NDB</literal> storage engine, fails with
an error.
</para>
-
+
</formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title>MySQL Cluster and geometry data types</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>geometry data types</secondary>
</indexterm>
-
+
<para>
Geometry datatypes (<literal>WKT</literal> and
<literal>WKB</literal>) are supported in
<literal>NDB</literal> tables in MySQL ¤t-series;.
However, spatial indexes are not supported.
</para>
-
+
</formalpara>
</listitem>
-
-
-
+
<listitem>
<formalpara>
-
+
<title>Row-based replication</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>replication</secondary>
</indexterm>
-
+
<para>
When using row-based replication with MySQL Cluster,
binary logging cannot be disabled. That is, the
<literal>NDB</literal> storage engine ignores the value of
<literal>SQL_LOG_BIN</literal>. (Bug #16680)
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title><literal>auto_increment_increment</literal> and
<literal>auto_increment_offset</literal></title>
-
+
<para>
The <literal>auto_increment_increment</literal> and
<literal>auto_increment_offset</literal> server system
variables are not supported for Cluster replication.
</para>
-
+
</formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</section>
-
+
<section id="mysql-cluster-limitations-limits">
-
+
<title>Limits and Differences from Standard MySQL Limits</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>and differences from standard MySQL limits</secondary>
</indexterm>
-
+
<para>
In this section, we list limits found in MySQL Cluster that either
differ from limits found in, or that are not found in, standard
MySQL.
-
+
<itemizedlist>
-
+
<listitem>
<indexterm>
<primary>memory use</primary>
<secondary>in MySQL Cluster</secondary>
</indexterm>
-
+
<indexterm>
<primary>MySQL Cluster</primary>
<secondary>memory usage and recovery</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>DELETE</literal></primary>
<secondary>and MySQL Cluster</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>DROP TABLE</literal></primary>
<secondary>and MySQL Cluster</secondary>
</indexterm>
-
+
<indexterm>
<primary><literal>TRUNCATE</literal></primary>
<secondary>and MySQL Cluster</secondary>
</indexterm>
-
+
<formalpara>
-
+
<title>Memory usage and recovery</title>
-
+
<para>
Memory comsumed when data is inserted into an
<literal>NDB</literal> table is not automatically
recovered when deleted, as it is with other storage
engines. Instead, the following rules hold true:
-
+
<itemizedlist>
-
+
<listitem>
<para>
A <literal>DELETE</literal> statement on an
@@ -301,7 +297,7 @@
<literal>NDB</literal> tables.
</para>
</listitem>
-
+
<listitem>
<para>
A <literal>DROP TABLE</literal> or
@@ -311,7 +307,7 @@
<literal>NDB</literal> table, either by the same
table or by another <literal>NDB</literal> table.
</para>
-
+
<note>
<para>
Recall that <literal>TRUNCATE</literal> drops and
@@ -319,7 +315,7 @@
<xref linkend="truncate"/>.
</para>
</note>
-
+
<para>
Memory freed by <literal>DELETE</literal> operations
but still allocated to a specific table can also be
@@ -328,17 +324,17 @@
<xref linkend="mysql-cluster-rolling-restart"/>.
</para>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title>Limits imposed by the cluster's configuration</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>imposed by configuration</secondary>
</indexterm>
-
+
<para>
A number of hard limits exist which are
configurable, but available main memory in the
@@ -347,9 +343,9 @@
<xref linkend="mysql-cluster-config-file"/>. Most
configuration parameters can be upgraded online.
These hard limits include:
-
+
<itemizedlist>
-
+
<listitem>
<para>
Database memory size and index memory size
@@ -357,7 +353,7 @@
<literal>IndexMemory</literal>,
respectively).
</para>
-
+
<para>
<literal>DataMemory</literal> is allocated
as 32KB pages. As each
@@ -366,7 +362,7 @@
allocated, this memory cannot be freed
except by dropping the table.
</para>
-
+
<para>
See
<xref linkend="mysql-cluster-ndbd-definition"/>,
@@ -375,7 +371,7 @@
<literal>IndexMemory</literal>.
</para>
</listitem>
-
+
<listitem>
<para>
The maximum number of operations that can be
@@ -384,15 +380,19 @@
<literal>MaxNoOfConcurrentOperations</literal>
and
<literal>MaxNoOfLocalOperations</literal>.
- </para><note><para>
- Bulk loading, <literal>TRUNCATE
+ </para>
+
+ <note>
+ <para>
+ Bulk loading, <literal>TRUNCATE
TABLE</literal>, and <literal>ALTER
- TABLE</literal> are handled as special cases
- by running multiple transactions, and so are
- not subject to this limitation.
- </para></note>
+ TABLE</literal> are handled as special
+ cases by running multiple transactions,
+ and so are not subject to this limitation.
+ </para>
+ </note>
</listitem>
-
+
<listitem>
<para>
Different limits related to tables and
@@ -401,47 +401,53 @@
<literal>MaxNoOfOrderedIndexes</literal>.
</para>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Memory usage</title>
- <para>
- All Cluster table rows are of fixed length. This means
- (for example) that if a table has one or more
- <literal>VARCHAR</literal> fields containing only
- relatively small values, more memory and disk space is
- required when using the <literal>NDB</literal> storage
- engine than would be the case for the same table and data
- using the <literal>MyISAM</literal> engine. (In other
- words, in the case of a <literal>VARCHAR</literal> column,
- the column requires the same amount of storage as a
- <literal>CHAR</literal> column of the same size.)
- </para></formalpara>
+
+ <para>
+ All Cluster table rows are of fixed length. This
+ means (for example) that if a table has one or
+ more <literal>VARCHAR</literal> fields containing
+ only relatively small values, more memory and disk
+ space is required when using the
+ <literal>NDB</literal> storage engine than would
+ be the case for the same table and data using the
+ <literal>MyISAM</literal> engine. (In other words,
+ in the case of a <literal>VARCHAR</literal>
+ column, the column requires the same amount of
+ storage as a <literal>CHAR</literal> column of the
+ same size.)
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title>Node and data object maximums</title>
-
+
<para>
The following limits apply to numbers of cluster
nodes and metadata objects:
-
+
<itemizedlist>
-
+
<listitem>
<para>
The maximum number of data nodes is 48.
</para>
</listitem>
-
+
<listitem>
<para>
The total maximum number of nodes in a MySQL
@@ -452,7 +458,7 @@
management servers.
</para>
</listitem>
-
+
<listitem>
<para>
The maximum number of metadata objects in
@@ -460,109 +466,116 @@
hard-coded.
</para>
</listitem>
-
+
</itemizedlist>
-
-
</para>
-
+
</formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</section>
+
<section id="mysql-cluster-limitations-transactions">
-
+
<title>Limits Relating to Transaction Handling</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>transactions</secondary>
</indexterm>
-
+
<para>
A number of limitations exist in MySQL Cluster with regard to the
handling of transactions. These include the following:
-
+
<itemizedlist>
-
+
<listitem>
<formalpara>
+
<title>Transaction isolation level</title>
+
<para>
The <literal>NDBCLUSTER</literal> storage engine supports
only the <literal>READ COMMITTED</literal> transaction
isolation level.
-
+
<important>
<para>
If a <literal>SELECT</literal> from a Cluster table
includes a <literal>BLOB</literal> or
<literal>TEXT</literal> column, the <literal>READ
- COMMITTED</literal> transaction isolation level is
+ COMMITTED</literal> transaction isolation level is
converted to a read with read lock. This is done to
- guarantee consistency, due to the fact that parts of the
- values stored in columns of these types are actually read
- from a separate table.
+ guarantee consistency, due to the fact that parts of
+ the values stored in columns of these types are
+ actually read from a separate table.
</para>
</important>
- </para></formalpara>
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Rollbacks</title>
-
+
<para>
There is no partial rollback of transactions. A duplicate
key or similar error rolls back the entire transaction.
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Transactions and memory usage</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>memory usage and transaction handling</secondary>
</indexterm>
-
+
<indexterm>
<primary>MySQL Cluster</primary>
<secondary>transaction handling</secondary>
</indexterm>
+
<para>
As noted elsewhere in this chapter, MySQL Cluster does not
handle large transactions well; it is better to perform a
- number of small transactions with a few operations each than
- to attempt a single large transaction containing a great
- many operations. Among other considerations, large
+ number of small transactions with a few operations each
+ than to attempt a single large transaction containing a
+ great many operations. Among other considerations, large
transactions require very large amounts of memory. Because
of this, the transactional behaviour of a number of MySQL
statements is effected as described in the following list:
-
+
<itemizedlist>
-
+
<listitem>
<para>
- <literal>TRUNCATE</literal> is not transactional when
- used on <literal>NDB</literal> tables. If a
- <literal>TRUNCATE</literal> fails to empty the table,
- then it must be re-run until it is successful.
+ <literal>TRUNCATE</literal> is not transactional
+ when used on <literal>NDB</literal> tables. If a
+ <literal>TRUNCATE</literal> fails to empty the
+ table, then it must be re-run until it is
+ successful.
</para>
</listitem>
-
+
<listitem>
<para>
<literal>DELETE FROM</literal> (even with no
@@ -577,276 +590,339 @@
instead.
</para>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title><literal>LOAD DATA</literal> statements</title>
-
+
<para>
<literal>LOAD DATA INFILE</literal> is not
transactional when used on <literal>NDB</literal>
tables.
-
+
<important>
<para>
When executing a <literal>LOAD DATA
- INFILE</literal> statement, the
+ INFILE</literal> statement, the
<literal>NDB</literal> engine can and does
commit at will.
</para>
</important>
-
+
<literal>LOAD DATA FROM MASTER</literal> is not
supported in MySQL Cluster.
</para>
-
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
-
+
<title><literal>ALTER TABLE</literal> and transactions</title>
-
+
<para>
- When copying an <literal>NDB</literal> table as part
- of an <literal>ALTER TABLE</literal>, the creation
- of the copy is non-transactional. (In any case, this
- operation is rolled back when the copy is deleted.)
+ When copying an <literal>NDB</literal> table as
+ part of an <literal>ALTER TABLE</literal>, the
+ creation of the copy is non-transactional. (In any
+ case, this operation is rolled back when the copy
+ is deleted.)
</para>
-
+
</formalpara>
</listitem>
-
+
</itemizedlist>
</para>
- </formalpara>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
-
+
</section>
-
+
<section id="mysql-cluster-limitations-error-handling">
-
+
<title>Error Handling</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>error handling and reporting</secondary>
</indexterm>
-
+
<para>
Starting, stopping, or restarting a node may give rise to
temporary errors causing some transactions to fail. These include
the following cases:
-
+
<itemizedlist>
-
+
<listitem>
<formalpara>
+
<title>Temporary errors</title>
+
<para>
- When first starting a node, it is possible that you may see
- Error 1204 <errortext>Temporary failure, distribution
- changed</errortext> and similar temporary errors.
- </para></formalpara>
+ When first starting a node, it is possible that you may
+ see Error 1204 <errortext>Temporary failure, distribution
+ changed</errortext> and similar temporary errors.
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Errors due to node failure</title>
+
<para>
The stopping or failure of any data node can result in a
number of different node failure errors. (However, there
- should be no aborted transactions when performing a planned
- shutdown of the cluster.)
- </para></formalpara>
+ should be no aborted transactions when performing a
+ planned shutdown of the cluster.)
+ </para>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
<para>
In either of these cases, any errors that are generated must be
handled within the application. This should be done by retrying
the transaction.
</para>
-
+
<para>
See also <xref linkend="mysql-cluster-limitations-limits"/>.
</para>
+
</section>
+
<section id="mysql-cluster-limitations-database-objects">
-
+
<title>Limits Associated with Database Objects</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>database objects</secondary>
</indexterm>
-
+
<para>
Some database objects such as tables and indexes have different
limitations when using the <literal>NDBCLUSTER</literal> storage
engine:
-
+
<itemizedlist>
-
- <listitem><formalpara>
- <title>Identifiers</title>
- <para>
- Database names, table names and attribute names cannot be as
- long in <literal>NDB</literal> tables as when using other
- table handlers. Attribute names are truncated to 31
- characters, and if not unique after truncation give rise to
- errors. Database names and table names can total a maximum
- of 122 characters. In other words, the maximum length for an
- <literal>NDB</literal> table name is 122 characters, less
- the number of characters in the name of the database of
- which that table is a part.
- </para>
- </formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Identifiers</title>
+
+ <para>
+ Database names, table names and attribute names cannot be
+ as long in <literal>NDB</literal> tables as when using
+ other table handlers. Attribute names are truncated to 31
+ characters, and if not unique after truncation give rise
+ to errors. Database names and table names can total a
+ maximum of 122 characters. In other words, the maximum
+ length for an <literal>NDB</literal> table name is 122
+ characters, less the number of characters in the name of
+ the database of which that table is a part.
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Number of tables</title>
-
-
- <para>
- The maximum number of tables in a Cluster database in
- MySQL 5.0 is limited to 1792.
- </para>
- </formalpara>
+
+ <para>
+ The maximum number of tables in a Cluster database in
+ MySQL 5.0 is limited to 1792.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Attributes per table</title>
- <para>
- The maximum number of attributes (that is, columns and
- indexes) per table is limited to 128.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Attributes per table</title>
+
+ <para>
+ The maximum number of attributes (that is, columns and
+ indexes) per table is limited to 128.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Attributes per key</title>
- <para>
- The maximum number of attributes per key is 32.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Attributes per key</title>
+
+ <para>
+ The maximum number of attributes per key is 32.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Row size</title>
- <para>
- The maximum permitted size of any one row is 8KB. Note that
- each <literal>BLOB</literal> or <literal>TEXT</literal>
- column contributes 256 + 8 = 264 bytes towards this total.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Row size</title>
+
+ <para>
+ The maximum permitted size of any one row is 8KB. Note
+ that each <literal>BLOB</literal> or
+ <literal>TEXT</literal> column contributes 256 + 8 = 264
+ bytes towards this total.
+ </para>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</section>
-
+
<section id="mysql-cluster-limitations-unsupported-missing">
-
+
<title>Unsupported Or Missing Features</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>unsupported features</secondary>
</indexterm>
-
+
<formalpara>
-
+
<title>Unsupported Features</title>
-
+
<para>
A number of features supported by other storage engines are not
supported for <literal>NDB</literal> tables. Trying to use any
of these features in MySQL Cluster does not cause errors in or
of itself; however, errors may occur in applications that
expects the features to be supported or enforced:
-
+
<itemizedlist>
-
- <listitem><formalpara>
- <title>Foreign key constraints</title>
- <para>
- The foreign key construct is ignored, just as it is in
- <literal>MyISAM</literal> tables.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Foreign key constraints</title>
+
+ <para>
+ The foreign key construct is ignored, just as it is in
+ <literal>MyISAM</literal> tables.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Savepoints and rollbacks</title>
- <para>
- Savepoints and rollbacks to savepoints are ignored as in
- <literal>MyISAM</literal>.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Savepoints and rollbacks</title>
+
+ <para>
+ Savepoints and rollbacks to savepoints are ignored as in
+ <literal>MyISAM</literal>.
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title><literal>OPTIMIZE</literal> operations</title>
+
<para>
- <literal>OPTIMIZE</literal> operations are not supported.
- </para></formalpara>
+ <literal>OPTIMIZE</literal> operations are not
+ supported.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title><literal>LOAD TABLE ... FROM MASTER</literal></title>
- <para>
- <literal>LOAD TABLE ... FROM MASTER</literal> is not
- supported.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>LOAD TABLE ... FROM MASTER</literal></title>
+
+ <para>
+ <literal>LOAD TABLE ... FROM MASTER</literal> is not
+ supported.
+ </para>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</formalpara>
-
+
<formalpara>
-
+
<title>Missing Features</title>
-
+
<para>
<itemizedlist>
-
- <listitem><formalpara>
- <title>Transaction isolation</title>
- <para>
- The only supported isolation level is <literal>READ
+
+ <listitem>
+ <formalpara>
+
+ <title>Transaction isolation</title>
+
+ <para>
+ The only supported isolation level is <literal>READ
COMMITTED</literal>. (InnoDB supports <literal>READ
- COMMITTED</literal>, <literal>READ UNCOMMITTED</literal>,
- <literal>REPEATABLE READ</literal>, and
- <literal>SERIALIZABLE</literal>.) See
- <xref linkend="mysql-cluster-backup-troubleshooting"/>,
- for information on how this can affect backup and restore
- of Cluster databases.
- </para></formalpara>
+ COMMITTED</literal>, <literal>READ
+ UNCOMMITTED</literal>, <literal>REPEATABLE
+ READ</literal>, and <literal>SERIALIZABLE</literal>.)
+ See
+ <xref linkend="mysql-cluster-backup-troubleshooting"/>,
+ for information on how this can affect backup and
+ restore of Cluster databases.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Durability</title>
- <para>
- No durable commits on disk. Commits are replicated, but
- there is no guarantee that logs are flushed to disk on
- commit.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Durability</title>
+
+ <para>
+ No durable commits on disk. Commits are replicated, but
+ there is no guarantee that logs are flushed to disk on
+ commit.
+ </para>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
+
</formalpara>
-
+
<note>
<para>
See <xref linkend="mysql-cluster-limitations-transactions"/>,
@@ -854,438 +930,484 @@
handling in <literal>NDB</literal>.
</para>
</note>
+
</section>
-
+
<section id="mysql-cluster-limitations-performance">
-
+
<title>Limitations Relating to Performance</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>performance</secondary>
</indexterm>
-
+
<para>
The following performance issues are specific to or especially
pronounced in MySQL Cluster:
-
+
<itemizedlist>
-
- <listitem><formalpara>
- <title>Range scans</title>
- <para>
- There are query performance issues due to sequential access
- to the <literal>NDB</literal> storage engine; it is also
- relatively more expensive to do many range scans than it is
- with either <literal>MyISAM</literal> or
- <literal>InnoDB</literal>.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Range scans</title>
+
+ <para>
+ There are query performance issues due to sequential
+ access to the <literal>NDB</literal> storage engine; it is
+ also relatively more expensive to do many range scans than
+ it is with either <literal>MyISAM</literal> or
+ <literal>InnoDB</literal>.
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Reliability of <literal>Records in range</literal></title>
+
<para>
The <literal>Records in range</literal> statistic is
available but is not completely tested or officially
supported. This may result in non-optimal query plans in
some cases. If necessary, you can employ <literal>USE
- INDEX</literal> or <literal>FORCE INDEX</literal> to alter
+ INDEX</literal> or <literal>FORCE INDEX</literal> to alter
the execution plan. See <xref linkend="index-hints"/>, for
more information on how to do this.
- </para></formalpara>
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Unique hash indexes</title>
+
<para>
Unique hash indexes created with <literal>USING
- HASH</literal> cannot be used for accessing a table if
+ HASH</literal> cannot be used for accessing a table if
<literal>NULL</literal> is given as part of the key.
- </para></formalpara>
+ </para>
+
+ </formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Binary logging</title>
+
<para>
MySQL Cluster has the following limitations or
restrictions with regard to binary logging:
-
+
<itemizedlist>
+
<listitem>
<para>
<literal>SQL_LOG_BIN</literal> has no effect on data
- operations; however, it is supported for schema operations.
+ operations; however, it is supported for schema
+ operations.
</para>
-
</listitem>
-
+
<listitem>
-
<para>
- MySQL Cluster cannot produce a binlog for tables having
- <literal>BLOB</literal> columns but no primary key.
+ MySQL Cluster cannot produce a binlog for tables
+ having <literal>BLOB</literal> columns but no
+ primary key.
</para>
</listitem>
-
+
<listitem>
<para>
- Only the following schema operations are logged in a cluster
- binlog which is <emphasis>not</emphasis> on the
- <command>mysqld</command> executing the statement:<itemizedlist>
-
+ Only the following schema operations are logged in a
+ cluster binlog which is <emphasis>not</emphasis> on
+ the <command>mysqld</command> executing the
+ statement:
+
+ <itemizedlist>
+
<listitem>
<para>
<literal>CREATE TABLE</literal>
</para>
</listitem>
-
+
<listitem>
<para>
<literal>ALTER TABLE</literal>
</para>
</listitem>
-
+
<listitem>
<para>
<literal>DROP TABLE</literal>
</para>
</listitem>
-
+
<listitem>
<para>
- <literal>CREATE DATABASE</literal> / <literal>CREATE
- SCHEMA</literal>
+ <literal>CREATE DATABASE</literal> /
+ <literal>CREATE SCHEMA</literal>
</para>
</listitem>
-
+
<listitem>
<para>
- <literal>DROP DATABASE</literal> / <literal>DROP
- SCHEMA</literal>
+ <literal>DROP DATABASE</literal> /
+ <literal>DROP SCHEMA</literal>
</para>
</listitem>
-
+
</itemizedlist>
</para>
</listitem>
+
</itemizedlist>
-
</para>
+
</formalpara>
-
-
-
-
-
-
</listitem>
-
+
</itemizedlist>
</para>
+
</section>
-
+
<section id="mysql-cluster-limitations-exclusive-to-cluster">
-
+
<title>Issues Exclusive to MySQL Cluster</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>implementation</secondary>
- </indexterm><para>
+ </indexterm>
+
+ <para>
The following are limitations specific to the
<literal>NDBCLUSTER</literal> storage engine, and do not occur
with <literal>MyISAM</literal> or <literal>InnoDB</literal>:
+
<itemizedlist>
-
- <listitem><formalpara>
- <title>Machine architecture</title>
- <para>
- The following issues relate to physical architecture of
- cluster hosts:
- <itemizedlist>
- <listitem>
- <para>
- All machines used in the cluster must have the same
- architecture. That is, all machines hosting nodes must be
- either big-endian or little-endian, and you cannot use a
- mixture of both. For example, you cannot have a management
- node running on a PowerPC which directs a data node that
- is running on an x86 machine. This restriction does not
- apply to machines simply running <command>mysql</command>
- or other clients that may be accessing the cluster's SQL
- nodes.
- </para>
- </listitem>
-
- <listitem>
- <formalpara>
-
- <title>Adding and dropping of data nodes</title>
-
+
+ <listitem>
+ <formalpara>
+
+ <title>Machine architecture</title>
+
+ <para>
+ The following issues relate to physical architecture of
+ cluster hosts:
+
+ <itemizedlist>
+
+ <listitem>
<para>
- Online adding or dropping of data nodes is not currently
- possible. In such cases, the entire cluster must be
- restarted.
+ All machines used in the cluster must have the same
+ architecture. That is, all machines hosting nodes
+ must be either big-endian or little-endian, and you
+ cannot use a mixture of both. For example, you
+ cannot have a management node running on a PowerPC
+ which directs a data node that is running on an x86
+ machine. This restriction does not apply to machines
+ simply running <command>mysql</command> or other
+ clients that may be accessing the cluster's SQL
+ nodes.
</para>
-
- </formalpara>
- </listitem>
-
- <listitem><formalpara>
-
- <title>Backup and restore between architectures</title>
- <para>
- It is also not possible to perform a Cluster backup and
- restore between different architectures. For example, you
- cannot back up a cluster running on a big-endian platform
- and then restore from that backup to a cluster running on
- a little-endian system. (Bug #19255)
- </para></formalpara>
- </listitem>
- </itemizedlist>
-
- </para>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Adding and dropping of data nodes</title>
+
+ <para>
+ Online adding or dropping of data nodes is not
+ currently possible. In such cases, the entire
+ cluster must be restarted.
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Backup and restore between architectures</title>
+
+ <para>
+ It is also not possible to perform a Cluster
+ backup and restore between different
+ architectures. For example, you cannot back up a
+ cluster running on a big-endian platform and then
+ restore from that backup to a cluster running on a
+ little-endian system. (Bug #19255)
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
</formalpara>
</listitem>
-
+
<listitem>
<formalpara>
+
<title>Online schema changes</title>
- <para>
- It is not possible to make online schema changes such as
- those accomplished using <literal>ALTER TABLE</literal> or
- <literal>CREATE INDEX</literal>, as the <literal>NDB
+
+ <para>
+ It is not possible to make online schema changes such as
+ those accomplished using <literal>ALTER TABLE</literal> or
+ <literal>CREATE INDEX</literal>, as the <literal>NDB
Cluster</literal> engine does not support autodiscovery of
- such changes. (However, you can import or create a table
- that uses a different storage engine, and then convert it
- to <literal>NDB</literal> using <literal>ALTER TABLE
+ such changes. (However, you can import or create a table
+ that uses a different storage engine, and then convert it
+ to <literal>NDB</literal> using <literal>ALTER TABLE
<replaceable>tbl_name</replaceable>
ENGINE=NDBCLUSTER</literal>. In such a case, you must
- issue a <literal>FLUSH TABLES</literal> statement to force
- the cluster to pick up the change.)
- </para></formalpara>
+ issue a <literal>FLUSH TABLES</literal> statement to force
+ the cluster to pick up the change.)
+ </para>
+
+ </formalpara>
</listitem>
+
</itemizedlist>
-
</para>
+
</section>
-
+
<section id="mysql-cluster-limitations-multiple-nodes">
+
<title>Limitations Relating to Multiple Cluster Nodes</title>
-
+
<formalpara>
+
<title>Multiple SQL nodes</title>
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>multiple MySQL servers</secondary>
</indexterm>
-
+
<para>
The following are issues relating to the use of multiple MySQL
servers as MySQL Cluster SQL nodes, and are specific to the
<literal>NDBCLUSTER</literal> storage engine:
+
<itemizedlist>
-
- <listitem><formalpara>
- <title><literal>ALTER TABLE</literal> operations</title>
- <para>
- <literal>ALTER TABLE</literal> is not fully locking when
- running multiple MySQL servers (no distributed table
- lock).
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>ALTER TABLE</literal> operations</title>
+
+ <para>
+ <literal>ALTER TABLE</literal> is not fully locking when
+ running multiple MySQL servers (no distributed table
+ lock).
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Replication</title>
- <para>
- MySQL replication will not work correctly if updates are
- done on multiple MySQL servers. However, if the database
- partitioning scheme is done at the application level and
- no transactions take place across these partitions,
- replication can be made to work.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Replication</title>
+
+ <para>
+ MySQL replication will not work correctly if updates are
+ done on multiple MySQL servers. However, if the database
+ partitioning scheme is done at the application level and
+ no transactions take place across these partitions,
+ replication can be made to work.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Database autodiscovery</title>
- <para>
- Autodiscovery of databases is not supported for multiple
- MySQL servers accessing the same MySQL Cluster. However,
- autodiscovery of tables is supported in such cases. What
- this means is that after a database named
- <replaceable>db_name</replaceable> is created or imported
- using one MySQL server, you should issue a <literal>CREATE
- DATABASE <replaceable>db_name</replaceable></literal>
- statement on each additional MySQL server that accesses
- the same MySQL Cluster. (As of MySQL 5.0.2, you may also
- use <literal>CREATE SCHEMA
+
+ <listitem>
+ <formalpara>
+
+ <title>Database autodiscovery</title>
+
+ <para>
+ Autodiscovery of databases is not supported for multiple
+ MySQL servers accessing the same MySQL Cluster. However,
+ autodiscovery of tables is supported in such cases. What
+ this means is that after a database named
+ <replaceable>db_name</replaceable> is created or
+ imported using one MySQL server, you should issue a
+ <literal>CREATE DATABASE
+ <replaceable>db_name</replaceable></literal> statement
+ on each additional MySQL server that accesses the same
+ MySQL Cluster. (As of MySQL 5.0.2, you may also use
+ <literal>CREATE SCHEMA
<replaceable>db_name</replaceable></literal>.) Once this
- has been done for a given MySQL server, that server should
- be able to detect the database tables without error.
- </para></formalpara>
+ has been done for a given MySQL server, that server
+ should be able to detect the database tables without
+ error.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>DDL operations</title>
- <para>
- DDL operations are not node failure safe. If a node fails
- while trying to peform one of these (such as
- <literal>CREATE TABLE</literal> or <literal>ALTER
+
+ <listitem>
+ <formalpara>
+
+ <title>DDL operations</title>
+
+ <para>
+ DDL operations are not node failure safe. If a node
+ fails while trying to peform one of these (such as
+ <literal>CREATE TABLE</literal> or <literal>ALTER
TABLE</literal>), the data dictionary is locked and no
- further DDL statements can be executed without restarting
- the cluster.
- </para></formalpara>
+ further DDL statements can be executed without
+ restarting the cluster.
+ </para>
+
+ </formalpara>
</listitem>
-
+
</itemizedlist>
</para>
-
-
+
</formalpara>
-
+
<formalpara>
-
+
<title>Multiple management nodes</title>
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>multiple management servers</secondary>
</indexterm>
-
-
+
<para>
- When using multiple management servers:
-
-
+ When using multiple management servers:
+
<itemizedlist>
-
+
<listitem>
<para>
- You must give nodes explicit IDs in connectstrings
- because automatic allocation of node IDs does not work
- across multiple management servers.
+ You must give nodes explicit IDs in connectstrings because
+ automatic allocation of node IDs does not work across
+ multiple management servers.
</para>
</listitem>
-
+
<listitem>
<para>
- You must take extreme care to have the same
- configurations for all management servers. No special
- checks for this are performed by the cluster.
+ You must take extreme care to have the same configurations
+ for all management servers. No special checks for this are
+ performed by the cluster.
</para>
</listitem>
-
+
<listitem>
<para>
- Prior to MySQL 5.0.14, all data nodes had to be
- restarted after bringing up the cluster in order for
- the management nodes to be able to see one another.
+ Prior to MySQL 5.0.14, all data nodes had to be restarted
+ after bringing up the cluster in order for the management
+ nodes to be able to see one another.
</para>
-
+
<para>
(See Bug #12307 and Bug #13070 for more information.)
</para>
</listitem>
-
+
</itemizedlist>
</para>
+
</formalpara>
-
-
-
-
+
<formalpara>
-
+
<title>Multiple data node processes</title>
-
+
<para>
While it is possible to run multiple cluster processes
- concurrently on a single host, it is not always advisable
- to do so for reasons of performance and high availability,
- as well as other considerations. In particular, in MySQL
- ¤t-series;, we do not support for production use any MySQL
- Cluster deployment in which more than one
- <command>ndbd</command> process is run on a single physical
- machine.
+ concurrently on a single host, it is not always advisable to do
+ so for reasons of performance and high availability, as well as
+ other considerations. In particular, in MySQL ¤t-series;,
+ we do not support for production use any MySQL Cluster
+ deployment in which more than one <command>ndbd</command>
+ process is run on a single physical machine.
+
<note>
-
-
<para>
We may support multiple data nodes per host in a future
MySQL release, following additional testing. However, in
- MySQL ¤t-series;, such
- configurations can be considered experimental only.
+ MySQL ¤t-series;, such configurations can be
+ considered experimental only.
</para>
</note>
</para>
-
-
-
+
</formalpara>
-
-
-
-
+
<formalpara>
-
+
<title>Multiple network addresses</title>
-
+
<para>
- Multiple network addresses per data node are not supported.
- Use of these is liable to cause problems: In the event of a
- data node failure, an SQL node waits for confirmation that
- the data node went down but never receives it because
- another route to that data node remains open. This can
- effectively make the cluster inoperable.
-
+ Multiple network addresses per data node are not supported. Use
+ of these is liable to cause problems: In the event of a data
+ node failure, an SQL node waits for confirmation that the data
+ node went down but never receives it because another route to
+ that data node remains open. This can effectively make the
+ cluster inoperable.
+
<note>
-
<para>
It is possible to use multiple network hardware
- <emphasis>interfaces</emphasis> (such as Ethernet cards) for a
- single data node, but these must be bound to the same address.
- This also means that it not possible to use more than one
- <literal>[TCP]</literal> section per connection in the
- <literal>config.ini</literal> file. See
+ <emphasis>interfaces</emphasis> (such as Ethernet cards) for
+ a single data node, but these must be bound to the same
+ address. This also means that it not possible to use more
+ than one <literal>[TCP]</literal> section per connection in
+ the <literal>config.ini</literal> file. See
<xref linkend="mysql-cluster-tcp-definition"/>, for more
information.
</para>
</note>
</para>
-
+
</formalpara>
-
-
-
+
</section>
-
+
<section id="mysql-cluster-limitations-resolved">
+
<title>Previous MySQL Cluster Issues Resolved in MySQL 5.1</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>resolved in current version from previous versions</secondary>
</indexterm>
-
-
+
<para>
The following Cluster limitations in MySQL 4.1 have been resolved
in MySQL 5.0 as shown below:
</para>
-
+
<itemizedlist>
-
+
<listitem>
-
<para>
The <literal>NDB Cluster</literal> storage engine supports all
- character sets and collations available in MySQL
- 5.0.
+ character sets and collations available in MySQL 5.0.
</para>
</listitem>
-
+
<listitem>
<para>
Prior to MySQL 5.0.6, the maximum number of metadata objects
@@ -1293,71 +1415,79 @@
increased to 20320.
</para>
</listitem>
-
+
<listitem>
<para>
- MySQL Cluster in MySQL 5.0 supports column indexes that
- make use of prefixes.
+ MySQL Cluster in MySQL 5.0 supports column indexes that make
+ use of prefixes.
</para>
</listitem>
-
- <listitem><formalpara>
- <title>Query cache</title>
- <para>
- Unlike the case in MySQL 4.1, the Cluster
- storage engine in MySQL 5.0 supports MySQL's
- query cache. See <xref linkend="query-cache"/>.
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Query cache</title>
+
+ <para>
+ Unlike the case in MySQL 4.1, the Cluster storage engine in
+ MySQL 5.0 supports MySQL's query cache. See
+ <xref linkend="query-cache"/>.
+ </para>
+
+ </formalpara>
</listitem>
-
- <listitem><formalpara>
- <title>Character sets</title>
- <para>
- Beginning with MySQL 5.0.21, it is possible to install MySQL
- with Cluster support to a non-default location and change the
- search path for font description files using either the
- <option>--basedir</option> or
- <option>--character-sets-dir</option> options. (Previously,
- <command>ndbd</command> in MySQL 5.0 searched only the default
- path — typically
- <filename>/usr/local/mysql/share/mysql/charsets</filename>
- — for character sets.)
- </para></formalpara>
+
+ <listitem>
+ <formalpara>
+
+ <title>Character sets</title>
+
+ <para>
+ Beginning with MySQL 5.0.21, it is possible to install MySQL
+ with Cluster support to a non-default location and change
+ the search path for font description files using either the
+ <option>--basedir</option> or
+ <option>--character-sets-dir</option> options. (Previously,
+ <command>ndbd</command> in MySQL 5.0 searched only the
+ default path — typically
+ <filename>/usr/local/mysql/share/mysql/charsets</filename>
+ — for character sets.)
+ </para>
+
+ </formalpara>
</listitem>
-
-
-
+
<listitem>
<formalpara>
-
+
<title><literal>IGNORE</literal> and <literal>REPLACE</literal> functionality</title>
-
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>INSERT IGNORE, UPDATE IGNORE, and REPLACE statements</secondary>
</indexterm>
-
+
<para>
In MySQL 5.0.19 and earlier, <literal>INSERT
- IGNORE</literal>, <literal>UPDATE IGNORE</literal>, and
+ IGNORE</literal>, <literal>UPDATE IGNORE</literal>, and
<literal>REPLACE</literal> were supported only for primary
keys, but not for unique keys. It was possible to work
- around this issue by removing the constraint, then
- dropping the unique index, performing any inserts, and
- then adding the unique index again.
+ around this issue by removing the constraint, then dropping
+ the unique index, performing any inserts, and then adding
+ the unique index again.
</para>
-
+
</formalpara>
-
+
<para>
This limitation was removed for <literal>INSERT
- IGNORE</literal> and <literal>REPLACE</literal> in MySQL
+ IGNORE</literal> and <literal>REPLACE</literal> in MySQL
5.0.20. (See Bug #17431.)
</para>
</listitem>
-
+
</itemizedlist>
+
</section>
-
-
+
</section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6531 - trunk/refman-5.0 | jon | 18 May |
