Author: jstephens
Date: 2007-05-18 18:02:12 +0200 (Fri, 18 May 2007)
New Revision: 6534
Log:
Rework Cluster 4.1 Limitations section.
Modified:
trunk/refman-4.1/mysql-cluster-limitations-working.xml
Modified: trunk/refman-4.1/mysql-cluster-limitations-working.xml
===================================================================
--- trunk/refman-4.1/mysql-cluster-limitations-working.xml 2007-05-18 16:01:17 UTC (rev 6533)
+++ trunk/refman-4.1/mysql-cluster-limitations-working.xml 2007-05-18 16:02:12 UTC (rev 6534)
Changed blocks: 3, Lines Added: 1168, Lines Deleted: 708; 77189 bytes
@@ -6,614 +6,993 @@
%all.entities;
]>
<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 releases as compared with the features
+ available when using the <literal>MyISAM</literal> and
+ <literal>InnoDB</literal> storage engines. Currently, there are no
+ plans to address these in coming releases of MySQL ¤t-series;;
+ however, we will attempt to supply fixes for these issues in
+ subsequent release series. If you check the <quote>Cluster</quote>
+ category in the MySQL bugs database at
+ <ulink url="http://bugs.mysql.com"/>, you can find known bugs which
+ (if marked <quote>¤t-series;</quote>) we intend to correct in
+ upcoming releases of MySQL ¤t-series;.
+ </para>
+
+ <para>
+ This information is intended to be complete with respect to the
+ conditions just set forth. You can report any discrepancies that you
+ encounter to the MySQL bugs database using the instructions given in
+ <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>
- <title>Known Limitations of MySQL Cluster</title>
+
+
+
+ <section id="mysql-cluster-limitations-syntax">
+ <title>Non-Compliance In SQL Syntax</title>
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
+ <secondary>syntax</secondary>
</indexterm>
- <indexterm>
- <primary>limitations of MySQL Cluster</primary>
-<!-- <see>MySQL Cluster limitations</see> -->
- </indexterm>
-
<para>
- In this section, we provide a list of known limitations in MySQL
- Cluster releases in the ¤t-series;.x series compared to
- features available when using the <literal>MyISAM</literal> and
- <literal>InnoDB</literal> storage engines. Currently, there are no
- plans to address these in coming releases of MySQL
- ¤t-series;; however, we will attempt to supply fixes for
- these issues in subsequent release series. If you check the
- <quote>Cluster</quote> category in the MySQL bugs database at
- <ulink url="http://bugs.mysql.com"/>, you can find known bugs
- which (if marked <quote>¤t-series;</quote>) we intend to
- correct in upcoming releases of MySQL ¤t-series;.
- </para>
+ Some SQL statements relating to certain MySQL features produce
+ errors when used with <literal>NDB</literal> tables, as described
+ in the following list:
- <para>
- The list here is intended to be complete with respect to the
- conditions just set forth. You can report any discrepancies that
- you encounter to the MySQL bugs database using the instructions
- given in <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>
+ <itemizedlist>
- <itemizedlist>
+ <listitem>
+ <formalpara>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>syntax</secondary>
- </indexterm>
+ <title>Temporary tables</title>
- <para>
- <emphasis role="bold">Noncompliance in syntax</emphasis>
- (resulting in errors when running existing applications):
- </para>
-
- <itemizedlist>
-
- <listitem>
<para>
- Temporary tables are not supported.
+ 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>.
</para>
- </listitem>
- <listitem>
- <para>
- Not all charsets and collations are supported; see
- <xref linkend="mysql-cluster-news-4-1-6"/>, for a list of
- those that are supported.
- </para>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- There are no prefix indexes; only entire fields can be
- indexed.
- </para>
- </listitem>
+ <listitem>
+ <formalpara>
- <listitem>
+ <title>Indexes and keys in <literal>NDB</literal> tables</title>
+
<para>
- You cannot create indexes on <literal>NDB</literal> table
- columns that use any of the <literal>TEXT</literal> or
- <literal>BLOB</literal> data types.
- </para>
+ Keys and indexes on MySQL Cluster tables are subject to
+ the following limitations:
- <para>
- The <literal>NDB</literal> storage engine also does not
- support <literal>FULLTEXT</literal> indexes (these are
- supported by <literal>MyISAM</literal> only).
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ You cannot create indexes on <literal>NDB</literal>
+ table columns that use any of the
+ <literal>TEXT</literal> or <literal>BLOB</literal>
+ data types.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The <literal>NDB</literal> storage engine does not
+ support <literal>FULLTEXT</literal> indexes, which
+ 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>
+ There are no prefix indexes; only entire fields can be
+ indexed.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ A <literal>BIT</literal> column cannot be a primary
+ key, unique key, or index, nor can it be part of a
+ 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>.
+ </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
+ maximum of one <literal>AUTO_INCREMENT</literal>
+ column per table. However, in the case of a
+ Cluster table with no explicit primary key, an
+ <literal>AUTO_INCREMENT</literal> column is
+ automatically defined and used as a
+ <quote>hidden</quote> primary key. For this
+ reason, you cannot define a table that has an
+ explicit <literal>AUTO_INCREMENT</literal> column
+ unless that column is also declared using the
+ <literal>PRIMARY KEY</literal> option. Attempting
+ to create a table with an
+ <literal>AUTO_INCREMENT</literal> column that is
+ not the table's primary key, and using the
+ <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>
- However, you can index <literal>VARCHAR</literal> columns
- of <literal>NDB</literal> tables.
+ 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>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>Character set support</title>
<para>
- A <literal>BIT</literal> column cannot be a primary key,
- unique key, or index, nor can it be part of a composite
- primary key, unique key, or index.
- </para>
- </listitem>
+
+ Not all charsets and collations are supported; see
+ <xref linkend="mysql-cluster-news-4-1-6"/>, for a list of
+ those that are supported.
+ </para>
+ </formalpara>
+
+ <formalpara>
+ <title>Character set directory</title>
+ <para>
+
+
+
+ <command>ndbd</command> searches only the default path
+ (typically
+ <filename>/usr/local/mysql/share/mysql/charsets</filename>)
+ for character sets. Thus, it is not possible to install
+ MySQL with Cluster support in a different path (in the
+ case of the <filename>.tar.gz</filename> archives, other
+ than <filename>/usr/local/mysql</filename>) if character
+ sets that are not compiled into the MySQL Server need to
+ be used.
+
+ </para>
+ </formalpara>
+
+
+ </listitem>
- <listitem>
+ <listitem>
+ <formalpara>
+
+ <title>Row-based replication</title>
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
- <secondary>geometry datatypes</secondary>
+ <secondary>replication</secondary>
</indexterm>
<para>
- Geometry datatypes (<literal>WKT</literal> and
- <literal>WKB</literal>) are not supported.
+ 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>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>auto_increment_increment</literal> and
+ <literal>auto_increment_offset</literal></title>
+
<para>
- <literal>INSERT IGNORE</literal> is supported only for
- primary keys, but not for unique keys. One possible
- workaround is to remove the constraint by dropping the
- unique index, perform any inserts, and then add the unique
- index again. (Bug #17431)
+ The <literal>auto_increment_increment</literal> and
+ <literal>auto_increment_offset</literal> server system
+ variables are not supported for Cluster replication.
</para>
- </listitem>
- </itemizedlist>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>causing errors</secondary>
- </indexterm>
+ </itemizedlist>
+ </para>
- <para>
- <emphasis role="bold">Non-compliance in limits or
- behavior</emphasis> (may result in errors when running
- existing applications):
- </para>
+ </section>
- <itemizedlist>
+ <section id="mysql-cluster-limitations-limits">
- <listitem>
- <indexterm>
- <primary>memory use</primary>
- <secondary>in MySQL Cluster</secondary>
- </indexterm>
+ <title>Limits and Differences from Standard MySQL Limits</title>
- <indexterm>
- <primary>MySQL Cluster</primary>
- <secondary>memory usage and recovery</secondary>
- </indexterm>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>and differences from standard MySQL limits</secondary>
+ </indexterm>
- <indexterm>
- <primary><literal>DELETE</literal></primary>
- <secondary>and MySQL Cluster</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.
- <indexterm>
- <primary><literal>DROP TABLE</literal></primary>
- <secondary>and MySQL Cluster</secondary>
- </indexterm>
+ <itemizedlist>
- <indexterm>
- <primary><literal>TRUNCATE</literal></primary>
- <secondary>and MySQL Cluster</secondary>
- </indexterm>
+ <listitem>
+ <indexterm>
+ <primary>memory use</primary>
+ <secondary>in MySQL Cluster</secondary>
+ </indexterm>
- <para>
- <emphasis role="bold">Memory Usage</emphasis>:
- </para>
+ <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:
- </para>
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- A <literal>DELETE</literal> statement on an
- <literal>NDB</literal> table makes the memory formerly
- used by the deleted rows available for re-use by
- inserts on the same table only. The memory cannot be
- used by other <literal>NDB</literal> tables.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ A <literal>DELETE</literal> statement on an
+ <literal>NDB</literal> table makes the memory
+ formerly used by the deleted rows available for
+ re-use by inserts on the same table only. This
+ memory cannot be used by other
+ <literal>NDB</literal> tables.
+ </para>
+ </listitem>
- <listitem>
- <para>
- A <literal>DROP TABLE</literal> or
- <literal>TRUNCATE</literal> operation on an
- <literal>NDB</literal> table frees the memory that was
- used by this table for re-use by any
- <literal>NDB</literal> table — either by the
- same table or by another <literal>NDB</literal> table.
- </para>
+ <listitem>
+ <para>
+ A <literal>DROP TABLE</literal> or
+ <literal>TRUNCATE</literal> operation on an
+ <literal>NDB</literal> table frees the memory that
+ was used by this table for re-use by any
+ <literal>NDB</literal> table, either by the same
+ table or by another <literal>NDB</literal> table.
+ </para>
- <para>
- (Recall that <literal>TRUNCATE</literal> drops and
- re-creates the table. See <xref linkend="truncate"/>.)
- </para>
+ <note>
+ <para>
+ Recall that <literal>TRUNCATE</literal> drops and
+ re-creates the table. See
+ <xref linkend="truncate"/>.
+ </para>
+ </note>
- <para>
- Memory freed by <literal>DELETE</literal> operations
- but still allocated to a specific table can also be
- made available for general re-use by performing a
- rolling restart of the cluster. See
- <xref linkend="mysql-cluster-rolling-restart"/>.
- </para>
- </listitem>
+ <para>
+ Memory freed by <literal>DELETE</literal> operations
+ but still allocated to a specific table can also be
+ made available for general re-use by performing a
+ rolling restart of the cluster. See
+ <xref linkend="mysql-cluster-rolling-restart"/>.
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ <listitem>
+ <formalpara>
- <listitem>
- <para>
- <emphasis role="bold">Error Reporting</emphasis>:
+ <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
+ cluster sets limits. See the complete list of
+ configuration parameters in
+ <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
+ (<literal>DataMemory</literal> and
+ <literal>IndexMemory</literal>,
+ respectively).
+ </para>
+
+ <para>
+ <literal>DataMemory</literal> is allocated
+ as 32KB pages. As each
+ <literal>DataMemory</literal> page is used,
+ it is assigned to a specific table; once
+ allocated, this memory cannot be freed
+ except by dropping the table.
+ </para>
+
+ <para>
+ See
+ <xref linkend="mysql-cluster-ndbd-definition"/>,
+ for further information about
+ <literal>DataMemory</literal> and
+ <literal>IndexMemory</literal>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The maximum number of operations that can be
+ performed per transaction is set using the
+ configuration parameters
+ <literal>MaxNoOfConcurrentOperations</literal>
+ and
+ <literal>MaxNoOfLocalOperations</literal>.
+ </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>
+ </listitem>
+
+ <listitem>
+ <para>
+ Different limits related to tables and
+ indexes. For example, the maximum number of
+ ordered indexes per table is determined by
+ <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>
+ </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
+ Cluster is 63. This number includes all SQL
+ nodes (MySQL Servers), API nodes
+ (applications accessing the cluster other
+ than MySQL servers), data nodes, and
+ management servers.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+
+
+
+ The maximum number of metadata objects is limited to 1600,
+ including database tables, system tables, indexes and
+ <literal>BLOB</literal> columns.
+
+
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ </listitem>
+
+ </itemizedlist>
</para>
- <itemizedlist>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- A duplicate key error returns the error message
- <errortext>ERROR 23000: Can't write; duplicate key in
- table
- '<replaceable>tbl_name</replaceable>'</errortext>.
- </para>
- </listitem>
+ </itemizedlist>
+ </para>
- <listitem>
- <para>
- Like other MySQL storage engines, the
- <literal>NDB</literal> storage engine can handle a
- maximum of one <literal>AUTO_INCREMENT</literal>
- column per table. However, in the case of a Cluster
- table with no explicit primary key, an
- <literal>AUTO_INCREMENT</literal> column is
- automatically defined and used as a
- <quote>hidden</quote> primary key. For this reason,
- you cannot define a table that has an explicit
- <literal>AUTO_INCREMENT</literal> column unless that
- column is also declared using the <literal>PRIMARY
- KEY</literal> option.
- </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>
- Attempting to create a table with an
- <literal>AUTO_INCREMENT</literal> column that is not
- the table's primary key, and using the
- <literal>NDB</literal> storage engine, fails with an
- error.
+ 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
+ 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.
</para>
- </listitem>
+ </important>
+ </para>
- </itemizedlist>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>transactions</secondary>
- </indexterm>
+ <listitem>
+ <formalpara>
+ <title>Rollbacks</title>
+
<para>
- <emphasis role="bold">Transaction Handling</emphasis>:
+ There is no partial rollback of transactions. A duplicate
+ key or similar error rolls back the entire transaction.
</para>
- <itemizedlist>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- <literal>NDB Cluster</literal> supports only the
- <literal>READ COMMITTED</literal> transaction
- isolation level.
- </para>
- </listitem>
+ <listitem>
+ <formalpara>
- <listitem>
- <para>
- There is no partial rollback of transactions. A
- duplicate key or similar error results in a rollback
- of the entire transaction.
- </para>
- </listitem>
+ <title>Transactions and memory usage</title>
- <listitem>
- <para>
- <emphasis role="bold">Important</emphasis>: If a
- <literal>SELECT</literal> from a Cluster table
- includes a <literal>BLOB</literal>,
- <literal>TEXT</literal>, or <literal>VARCHAR</literal>
- column, the <literal>READ 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.
- </para>
- </listitem>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>memory usage and transaction handling</secondary>
+ </indexterm>
- <listitem>
- <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.
- </para>
+ <indexterm>
+ <primary>MySQL Cluster</primary>
+ <secondary>transaction handling</secondary>
+ </indexterm>
- <para>
- 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:
- </para>
+ <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
+ 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>
+ <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.
- </para>
- </listitem>
+ <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.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>DELETE FROM</literal> (even with no
- <literal>WHERE</literal> clause)
- <emphasis>is</emphasis> transactional. For tables
- containing a great many rows, you may find that
- performance is improved by using several
- <literal>DELETE FROM ... LIMIT ...</literal>
- statements to <quote>chunk</quote> the delete
- operation. If the objective is to empty the table,
- then you may wish to use
- <literal>TRUNCATE</literal> instead.
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>DELETE FROM</literal> (even with no
+ <literal>WHERE</literal> clause)
+ <emphasis>is</emphasis> transactional. For tables
+ containing a great many rows, you may find that
+ performance is improved by using several
+ <literal>DELETE FROM ... LIMIT ...</literal>
+ statements to <quote>chunk</quote> the delete
+ operation. If your objective is to empty the table,
+ then you may wish to use <literal>TRUNCATE</literal>
+ instead.
+ </para>
+ </listitem>
- <listitem>
+ <listitem>
+ <formalpara>
+
+ <title><literal>LOAD DATA</literal> statements</title>
+
<para>
<literal>LOAD DATA INFILE</literal> is not
- transactional. During such an operation the
- <literal>NDB</literal> engine can and does commit
- at will.
- </para>
+ transactional when used on <literal>NDB</literal>
+ tables.
- <para>
+ <important>
+ <para>
+ When executing a <literal>LOAD DATA
+ 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>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title><literal>ALTER TABLE</literal> and transactions</title>
+
<para>
- When copying a 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>
- </listitem>
- </itemizedlist>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- <emphasis role="bold">Node Start, Stop, or
- Restart:</emphasis>: Starting, stopping, or restarting
- a node may give rise to temporary errors causing some
- transactions to fail. These include the following
- cases:
- </para>
+ </itemizedlist>
+ </para>
- <itemizedlist>
+ </formalpara>
+ </listitem>
- <listitem>
- <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>
- </listitem>
+ </itemizedlist>
+ </para>
- <listitem>
- <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>
- </listitem>
+ </section>
- </itemizedlist>
+ <section id="mysql-cluster-limitations-error-handling">
- <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>
- </listitem>
+ <title>Error Handling</title>
- </itemizedlist>
- </listitem>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>error handling and reporting</secondary>
+ </indexterm>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>imposed by configuration</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>
- A number of hard limits exist which are configurable, but
- available main memory in the cluster sets limits. See the
- complete list of configuration parameters in
- <xref linkend="mysql-cluster-config-file"/>. Most
- configuration parameters can be upgraded online. These
- hard limits include:
+ 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>
- <itemizedlist>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- Database memory size and index memory size
- (<literal>DataMemory</literal> and
- <literal>IndexMemory</literal>, respectively).
- </para>
+ <listitem>
+ <formalpara>
- <para>
- <literal>DataMemory</literal> is allocated as 32KB
- pages. As each <literal>DataMemory</literal> page is
- used, it is assigned to a specific table; once
- allocated, this memory cannot be freed except by
- dropping the table.
- </para>
+ <title>Errors due to node failure</title>
- <para>
- See <xref linkend="mysql-cluster-ndbd-definition"/>,
- for further information about
- <literal>DataMemory</literal> and
- <literal>IndexMemory</literal>.
- </para>
- </listitem>
+ <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>
- <listitem>
- <para>
- The maximum number of operations that can be performed
- per transaction is set using the configuration
- parameters
- <literal>MaxNoOfConcurrentOperations</literal> and
- <literal>MaxNoOfLocalOperations</literal>. Note that
- 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>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <para>
- Different limits related to tables and indexes. For
- example, the maximum number of ordered indexes per
- table is determined by
- <literal>MaxNoOfOrderedIndexes</literal>.
- </para>
- </listitem>
+ </itemizedlist>
+ </para>
- </itemizedlist>
- </listitem>
+ <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>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>database objects</secondary>
- </indexterm>
+ <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 with other
- table handlers. Attribute names are truncated to 31
+ 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. (That is, the maximum length
- for an <literal>NDB Cluster</literal> table name is 122
- characters less the number of characters in the name of
- the database of which that table is a part.)
+ 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>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Number of tables</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.)
+ The maximum number of tables in a Cluster database in
+ MySQL 5.0 is limited to 1792.
</para>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Attributes per table</title>
+
<para>
- The maximum number of metadata objects is limited to 1600,
- including database tables, system tables, indexes and
- <literal>BLOB</literal>s.
+ The maximum number of attributes (that is, columns and
+ indexes) per table is limited to 128.
</para>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+
+ <title>Attributes per key</title>
+
<para>
- The maximum number of attributes per table is limited to
- 128.
+ The maximum number of attributes per key is 32.
</para>
- </listitem>
- <listitem>
+ </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 a maximum of
- 256 bytes towards this total.
+ <literal>TEXT</literal> column contributes 256 + 8 = 264
+ bytes towards this total.
</para>
- </listitem>
- <listitem>
- <para>
- The maximum number of attributes per key is 32.
- </para>
- </listitem>
+ </formalpara>
+ </listitem>
- </itemizedlist>
- </listitem>
+ </itemizedlist>
+ </para>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>unsupported features</secondary>
- </indexterm>
+ </section>
- <para>
- <emphasis role="bold">Unsupported features</emphasis> (do not
- cause errors, but are not supported or enforced):
- </para>
+ <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>
- <para>
- The foreign key construct is ignored, just as it is in
- <literal>MyISAM</literal> tables.
- </para>
+ <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>
- <para>
- Savepoints and rollbacks to savepoints are ignored as in
- <literal>MyISAM</literal>.
- </para>
+ <formalpara>
+
+ <title>Savepoints and rollbacks</title>
+
+ <para>
+ Savepoints and rollbacks to savepoints are ignored as in
+ <literal>MyISAM</literal>.
+ </para>
+
+ </formalpara>
</listitem>
<listitem>
- <para>
- <literal>OPTIMIZE</literal> operations are not supported.
- </para>
+ <formalpara>
+
+ <title><literal>OPTIMIZE</literal> operations</title>
+
+ <para>
+ <literal>OPTIMIZE</literal> operations are not
+ supported.
+ </para>
+
+ </formalpara>
</listitem>
<listitem>
- <para>
- <literal>LOAD TABLE ... FROM MASTER</literal> is not
- supported.
- </para>
+ <formalpara>
+
+ <title><literal>LOAD TABLE ... FROM MASTER</literal></title>
+
+ <para>
+ <literal>LOAD TABLE ... FROM MASTER</literal> is not
+ supported.
+ </para>
+
+ </formalpara>
</listitem>
</itemizedlist>
- </listitem>
+ </para>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>performance</secondary>
- </indexterm>
+ </formalpara>
- <para>
- <emphasis role="bold">Performance and limitation-related
- issues</emphasis>:
- </para>
+ <formalpara>
+ <title>Missing Features</title>
+
+ <para>
<itemizedlist>
<listitem>
- <para>
- The query cache is disabled, since it is not invalidated
- if an update occurs on a different MySQL server.
- </para>
+ <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>
</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>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+
+ <note>
+ <para>
+ See <xref linkend="mysql-cluster-limitations-transactions"/>,
+ for more information relating to limitations on transaction
+ 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
@@ -621,233 +1000,220 @@
it is with either <literal>MyISAM</literal> or
<literal>InnoDB</literal>.
</para>
- </listitem>
- <listitem>
+ </formalpara>
+ </listitem>
+
+ <listitem>
+ <formalpara>
+ <title>Query cache</title>
+
<para>
- The <literal>Records in range</literal> statistic is not
+ The query cache is disabled, since it is not invalidated
+ if an update occurs on a different MySQL server.
+ </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
- the execution plan. See <xref linkend="index-hints"/>.
+ the execution plan. See <xref linkend="index-hints"/>, for
+ more information on how to do this.
</para>
- </listitem>
- <listitem>
+ </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
<literal>NULL</literal> is given as part of the key.
</para>
- </listitem>
- <listitem>
- <para>
- <literal>SQL_LOG_BIN</literal> has no effect on data
- operations; however, it is supported for schema
- operations.
- </para>
+ </formalpara>
+ </listitem>
- <para>
- MySQL Cluster cannot produce a binlog for tables having
- <literal>BLOB</literal> columns but no primary key.
- </para>
+ <listitem>
+ <formalpara>
+ <title>Binary logging</title>
+
<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:
- </para>
+ MySQL Cluster has the following limitations or
+ restrictions with regard to binary logging:
- <itemizedlist>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>CREATE TABLE</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>SQL_LOG_BIN</literal> has no effect on data
+ operations; however, it is supported for schema
+ operations.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>ALTER TABLE</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ MySQL Cluster cannot produce a binlog for tables
+ having <literal>BLOB</literal> columns but no
+ primary key.
+ </para>
+ </listitem>
- <listitem>
- <para>
- <literal>DROP TABLE</literal>
- </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:
- <listitem>
- <para>
- <literal>CREATE DATABASE</literal>
- </para>
- </listitem>
+ <itemizedlist>
- <listitem>
- <para>
- <literal>DROP DATABASE</literal>
- </para>
- </listitem>
+ <listitem>
+ <para>
+ <literal>CREATE TABLE</literal>
+ </para>
+ </listitem>
- </itemizedlist>
- </listitem>
+ <listitem>
+ <para>
+ <literal>ALTER TABLE</literal>
+ </para>
+ </listitem>
- <listitem>
- <para>
- <command>ndbd</command> searches only the default path
- (typically
- <filename>/usr/local/mysql/share/mysql/charsets</filename>)
- for character sets. Thus, it is not possible to install
- MySQL with Cluster support in a different path (in the
- case of the <filename>.tar.gz</filename> archives, other
- than <filename>/usr/local/mysql</filename>) if character
- sets that are not compiled into the MySQL Server need to
- be used.
+ <listitem>
+ <para>
+ <literal>DROP TABLE</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>CREATE DATABASE</literal> /
+ <literal>CREATE SCHEMA</literal>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <literal>DROP DATABASE</literal> /
+ <literal>DROP SCHEMA</literal>
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ </itemizedlist>
</para>
- </listitem>
- </itemizedlist>
- </listitem>
+ </formalpara>
+ </listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>unsupported features</secondary>
- </indexterm>
+ </itemizedlist>
+ </para>
- <para>
- <emphasis role="bold">Missing features</emphasis>:
- </para>
+ </section>
- <itemizedlist>
+ <section id="mysql-cluster-limitations-exclusive-to-cluster">
- <listitem>
- <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>
- </listitem>
+ <title>Issues Exclusive to MySQL Cluster</title>
- <listitem>
- <para>
- No durable commits on disk. Commits are replicated, but
- there is no guarantee that logs are flushed to disk on
- commit.
- </para>
- </listitem>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>implementation</secondary>
+ </indexterm>
- </itemizedlist>
- </listitem>
+ <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>:
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>multiple MySQL servers</secondary>
- </indexterm>
+ <itemizedlist>
- <para>
- <emphasis role="bold">Problems relating to multiple MySQL
- servers</emphasis> (not relating to <literal>MyISAM</literal>
- or <literal>InnoDB</literal>):
- </para>
+ <listitem>
+ <formalpara>
- <itemizedlist>
+ <title>Machine architecture</title>
- <listitem>
<para>
- <literal>ALTER TABLE</literal> is not fully locking when
- running multiple MySQL servers (no distributed table
- lock).
- </para>
- </listitem>
+ The following issues relate to physical architecture of
+ cluster hosts:
- <listitem>
- <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>
- </listitem>
+ <itemizedlist>
- <listitem>
- <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. Once this has been done for a
- given MySQL server, that server should be able to detect
- the database tables without error.
- </para>
- </listitem>
+ <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>
- <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>
- </listitem>
+ <listitem>
+ <formalpara>
- </itemizedlist>
- </listitem>
+ <title>Adding and dropping of data nodes</title>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>implementation</secondary>
- </indexterm>
+ <para>
+ Online adding or dropping of data nodes is not
+ currently possible. In such cases, the entire
+ cluster must be restarted.
+ </para>
- <para id="mysql-cluster-limitations-exclusive-to-cluster">
- <emphasis role="bold">Issues exclusive to MySQL
- Cluster</emphasis> (not related to <literal>MyISAM</literal>
- or <literal>InnoDB</literal>):
- </para>
+ </formalpara>
+ </listitem>
- <itemizedlist>
+ <listitem>
+ <formalpara>
- <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>
+ <title>Backup and restore between architectures</title>
- <listitem>
- <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>
+ 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>
+ </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
@@ -861,119 +1227,213 @@
issue a <literal>FLUSH TABLES</literal> statement to force
the cluster to pick up the change.)
</para>
- </listitem>
+ </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>
- <para>
- Online adding or dropping of nodes is not possible (the
- cluster must be restarted in such cases).
- </para>
+ <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>
- <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, we do not
- in MySQL ¤t-series; support for production use any
- MySQL Cluster deployment in which more than one
- <command>ndbd</command> process is run on a single
- physical machine.
- </para>
+ <formalpara>
- <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.
- </para>
+ <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>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>multiple management servers</secondary>
- </indexterm>
+ <formalpara>
- <para>
- When using multiple management servers:
- </para>
+ <title>Database autodiscovery</title>
- <itemizedlist>
+ <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>
- <listitem>
- <para>
- You must give nodes explicit IDs in connectstrings
- because automatic allocation of node IDs does not work
- across multiple management servers.
- </para>
- </listitem>
+ </formalpara>
+ </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.
- </para>
- </listitem>
+ <listitem>
+ <formalpara>
- <listitem>
- <para>
- Prior to MySQL 4.1.15, 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>
+ <title>DDL operations</title>
- <para>
- (See Bug #12307 and Bug #13070 for more information.)
- </para>
- </listitem>
+ <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>
- </itemizedlist>
+ </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:
+
+ <itemizedlist>
+
<listitem>
<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.
+ 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>
- It is possible to use multiple network hardware interfaces
- (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.
+ 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>
- The maximum number of data nodes is 48.
+ Prior to MySQL 4.1.15, 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>
- </listitem>
- <listitem>
<para>
- The total maximum number of nodes in a MySQL Cluster is
- 63. This number includes all SQL nodes (MySQL Servers),
- API nodes (applications accessing the cluster other than
- MySQL servers), data nodes, and management servers.
+ (See Bug #12307 and Bug #13070 for more information.)
</para>
</listitem>
</itemizedlist>
- </listitem>
+ </para>
- </itemizedlist>
+ </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.
+
+ <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.
+ </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.
+
+ <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
+ <xref linkend="mysql-cluster-tcp-definition"/>, for more
+ information.
+ </para>
+ </note>
+ </para>
+
+ </formalpara>
+
</section>
+
+ </section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6534 - trunk/refman-4.1 | jon | 18 May |
