Author: jstephens
Date: 2007-05-17 17:59:37 +0200 (Thu, 17 May 2007)
New Revision: 6514
Log:
More edits of Cluster 5.1 Limitations (end of first pass).
Modified:
trunk/refman-5.1/mysql-cluster-limitations-working.xml
Modified: trunk/refman-5.1/mysql-cluster-limitations-working.xml
===================================================================
--- trunk/refman-5.1/mysql-cluster-limitations-working.xml 2007-05-17 15:57:52 UTC (rev 6513)
+++ trunk/refman-5.1/mysql-cluster-limitations-working.xml 2007-05-17 15:59:37 UTC (rev 6514)
Changed blocks: 7, Lines Added: 491, Lines Deleted: 417; 38032 bytes
@@ -416,6 +416,51 @@
</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 in MySQL
+ ¤t-series; Cluster and &mccge-series; is
+ 20320. This limit is hard-coded.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <note>
+ <para role="mccge-warning">
+ &mccge-series; users should see
+ <xref linkend="mysql-cluster-limitations-resolved"/>,
+ for more information.
+ </para>
+ </note>
+ </para>
+ </formalpara></listitem>
+
+
</itemizedlist>
</para>
</formalpara>
@@ -671,15 +716,17 @@
</para>
</section>
- <section id="mysql-cluster-limitations-unsupported-features">
- <title>Features Not Supported</title>
+ <section id="mysql-cluster-limitations-unsupported-missing">
+ <title>Unsupported Or Missing Features</title>
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>unsupported features</secondary>
</indexterm>
- <para>
+ <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
@@ -717,23 +764,57 @@
</itemizedlist>
- </para>
+ </para>
+ </formalpara>
+
+ <formalpara>
+ <title>Missing Features</title>
+ <para>
+
+
+ <itemizedlist>
+
+ <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>
+
+ <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>
+
+ </itemizedlist>
+ </para>
+ </formalpara>
+
+
+ </section>
- <itemizedlist>
-
-
-
- <listitem>
+ <section id="mysql-cluster-limitations-performance">
+ <title>Limitations Relating to Performance</title>
<indexterm>
<primary>MySQL Cluster limitations</primary>
<secondary>performance</secondary>
</indexterm>
-
- <para>
- <emphasis role="bold">Performance and limitation-related
- issues</emphasis>:
- </para>
-
+
+
+
+ <para>
+ The following performance issues are specific to or especially
+ pronounced in MySQL Cluster:
+
<itemizedlist>
<listitem>
@@ -749,11 +830,12 @@
<listitem>
<para>
The <literal>Records in range</literal> statistic is
- available but not completely tested or officially
+ 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>
@@ -857,58 +939,149 @@
</listitem>
</itemizedlist>
- </listitem>
+
+
+ </para>
+
+ </section>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>unsupported features</secondary>
- </indexterm>
+ <section id="mysql-cluster-limitations-exclusive-to-cluster">
+
+ <title>Issues Exclusive to MySQL Cluster</title>
- <para>
- <emphasis role="bold">Missing features</emphasis>:
- </para>
-
- <itemizedlist>
-
- <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>
-
- <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>
-
- </itemizedlist>
- </listitem>
-
- <listitem>
+
<indexterm>
<primary>MySQL Cluster limitations</primary>
- <secondary>multiple MySQL servers</secondary>
+ <secondary>implementation</secondary>
</indexterm>
<para>
- <emphasis role="bold">Problems relating to multiple MySQL
- servers</emphasis> (not relating to <literal>MyISAM</literal>
- or <literal>InnoDB</literal>):
+ 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>
+ 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>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>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; or
+ &mccge-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.
+ </para>
+ </formalpara>
+
+ <para>
+ We may support multiple data nodes per host in a future
+ MySQL release, following additional testing. However, in
+ MySQL ¤t-series; and &mccge-series;, such
+ configurations can be considered experimental only.
+ </para>
+ </listitem>
+ </itemizedlist>
</para>
-
+ </section>
+
+ <section id="mysql-cluster-limitations-disk-data">
+
+ <title>Limitation Relating to Disk Data Storage</title>
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>Disk Data storage</secondary>
+ </indexterm><itemizedlist>
+ <listitem>
+ <para>
+ Disk data objects are subject to the following
+ maximums:
+
+ <itemizedlist>
+
+ <listitem>
+ <para>
+ Maxmimum number of tablespaces: 2^32
+ (4294967296)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Maximum number of data files per tablespace:
+ 2^16 (65535)
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Maxmimum data file size: 2^47 (128GB)
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Use of Disk Data tables is not supported when
+ running the cluster in diskless mode. Beginning with
+ MySQL 5.1.12, it is disallowed altogether. (Bug
+ #20008)
+ </para>
+ </listitem>
+
+
+ </itemizedlist>
+
+ </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>
<literal>ALTER TABLE</literal> is not fully locking when
@@ -916,378 +1089,238 @@
lock).
</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.
+ DDL operations (such as <literal>CREATE TABLE</literal> or
+ <literal>ALTER TABLE</literal>) are not safe from data node
+ failures. If a data node fails while trying to peform one of
+ these, the data dictionary is locked and no further DDL
+ statements can be executed without restarting the cluster.
</para>
</listitem>
-
+
</itemizedlist>
- </listitem>
+ </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>
+ 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.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </para>
+
+ </formalpara>
+ <itemizedlist>
+
+
+ <listitem>
+ <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.
+ </para>
+ </formalpara>
+
+ <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>
+ </listitem>
+
+ </itemizedlist>
+
+
+ </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>
+ A number of limitations and related issues existing in earlier
+ versions of MySQL Cluster have been resolved over the course of
+ development of MySQL ¤t-series; or &mccge-series;:
+
+ <itemizedlist>
+
<listitem>
+ <para>
+ The <literal>NDB Cluster</literal> storage engine now
+ supports variable-length column types for in-memory
+ tables.
+ </para>
+
+ <para>
+ Previously, for example, any Cluster table having one or more
+ <literal>VARCHAR</literal> fields which contained only
+ relatively small values, much more memory and disk space
+ were required when using the <literal>NDBCLUSTER</literal>
+ storage engine than would have been 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, such a column required
+ the same amount of storage as a <literal>CHAR</literal>
+ column of the same size. In MySQL 5.1, this is no longer
+ the case for in-memory tables, where storage requirements
+ for variable-length column types such as
+ <literal>VARCHAR</literal> and <literal>BINARY</literal>
+ are comparable to those for these column types when used
+ in <literal>MyISAM</literal> tables (see
+ <xref linkend="storage-requirements"/>).
+ </para>
+
+ <important>
+ <para>
+ For MySQL Cluster Disk Data tables, the fixed-width
+ limitation continues to apply. See
+ <xref linkend="mysql-cluster-disk-data"/>.
+ </para>
+ </important>
+ </listitem>
+
+ <listitem>
<indexterm>
<primary>MySQL Cluster limitations</primary>
- <secondary>implementation</secondary>
+ <secondary>replication</secondary>
</indexterm>
-
- <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>
+ It is now possible to use MySQL replication with Cluster
+ databases. For details, see
+ <xref linkend="mysql-cluster-replication"/>.
</para>
-
- <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>
- <para>
- Online adding or dropping of nodes is not possible (the
- cluster must be restarted in such cases).
- </para>
- </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>
-
- <para>
- We may support multiple data nodes per host in a future
- MySQL release, following additional testing. However, in
- MySQL ¤t-series; and &mccge-series;, such
- configurations can be considered experimental only.
- </para>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>Disk Data tables</secondary>
- </indexterm>
-
- <para>
- <emphasis role="bold">Issues relating to Disk Data
- tables</emphasis>:
-
- <itemizedlist>
-
- <listitem>
- <para>
- Disk data objects are subject to the following
- maximums:
-
- <itemizedlist>
-
- <listitem>
- <para>
- Maxmimum number of tablespaces: 2^32
- (4294967296)
- </para>
- </listitem>
-
- <listitem>
- <para>
- Maximum number of data files per tablespace:
- 2^16 (65535)
- </para>
- </listitem>
-
- <listitem>
- <para>
- Maxmimum data file size: 2^47 (128GB)
- </para>
- </listitem>
-
- </itemizedlist>
- </para>
- </listitem>
-
- <listitem>
- <para>
- Use of Disk Data tables is not supported when
- running the cluster in diskless mode. Beginning with
- MySQL 5.1.12, it is disallowed altogether. (Bug
- #20008)
- </para>
- </listitem>
-
- </itemizedlist>
- </para>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>multiple management servers</secondary>
- </indexterm>
-
- <para>
- When using multiple management servers:
- </para>
-
- <itemizedlist>
-
- <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>
-
- <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>
-
- </itemizedlist>
- </listitem>
-
- <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.
- </para>
-
- <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.
- </para>
- </listitem>
-
- <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>
-
- &mccge-warning-begin;
-
- <para>
- Prior to MySQL 5.1.15-ndb-6.1.1, the total maximum number
- of nodes in a MySQL Cluster was 63, including all SQL
- nodes (MySQL Servers), API nodes (applications accessing
- the cluster other than MySQL servers), data nodes, and
- management servers.
- </para>
-
- <para>
- Starting with MySQL 5.1.15-ndb-6.1.1, up to 255 API nodes
- (including MySQL servers acting as cluster SQL nodes) are
- supported by a single cluster. The total number of data
- nodes and management nodes beginning with this version is
- 63, of which up to 48 can be data nodes.
- </para>
-
- &mccge-warning-end-cluster;
-
- </listitem>
-
- <listitem>
- <para>
- The maximum number of metadata objects in MySQL
- ¤t-series; Cluster and &mccge-series; is 20320. This
- limit is hard-coded.
- </para>
- </listitem>
-
- </itemizedlist>
+
+ <para>
+ However, circular replication is <emphasis>not</emphasis>
+ currently supported for MySQL Cluster. See
+ <xref linkend="mysql-cluster-replication-issues"/>.
+ </para>
</listitem>
-
+
<listitem>
<indexterm>
<primary>MySQL Cluster limitations</primary>
- <secondary>resolved in current version from previous versions</secondary>
+ <secondary>autodiscovery</secondary>
</indexterm>
-
- <para id="mysql-cluster-limitations-resolved-in-5-1">
- <emphasis role="bold">MySQL Cluster issues from previous
- versions that have been resolved in MySQL 5.1</emphasis>:
+
+ <para>
+ Autodiscovery of databases is now supported for multiple
+ MySQL servers accessing the same MySQL Cluster, provided
+ that a given <command>mysqld</command> is already running
+ and is connected to the cluster at the time that the
+ database is created on a different
+ <command>mysqld</command>.
</para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- The <literal>NDB Cluster</literal> storage engine now
- supports variable-length column types for in-memory
- tables.
- </para>
-
- <para>
- Previously, this meant that — for example —
- any Cluster table having one or more
- <literal>VARCHAR</literal> fields which contained only
- relatively small values, much more memory and disk space
- were required when using the <literal>NDBCluster</literal>
- storage engine than would have been 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, such a column required
- the same amount of storage as a <literal>CHAR</literal>
- column of the same size. In MySQL 5.1, this is no longer
- the case for in-memory tables, where storage requirements
- for variable-length column types such as
- <literal>VARCHAR</literal> and <literal>BINARY</literal>
- are comparable to those for these column types when used
- in <literal>MyISAM</literal> tables (see
- <xref linkend="storage-requirements"/>).
- </para>
-
- <para>
- <emphasis role="bold">Important</emphasis>: For MySQL
- Cluster Disk Data tables, the fixed-width limitation
- continues to apply. See
- <xref linkend="mysql-cluster-disk-data"/>.
- </para>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>replication</secondary>
- </indexterm>
-
- <para>
- It is now possible to use MySQL replication with Cluster
- databases. For details, see
- <xref linkend="mysql-cluster-replication"/>.
- </para>
-
- <para>
- However, circular replication is <emphasis>not</emphasis>
- currently supported for MySQL Cluster. See
- <xref linkend="mysql-cluster-replication-issues"/>.
- </para>
- </listitem>
-
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>autodiscovery</secondary>
- </indexterm>
-
- <para>
- Autodiscovery of databases is now supported for multiple
- MySQL servers accessing the same MySQL Cluster, provided
- that a given <command>mysqld</command> is already running
- and is connected to the cluster at the time that the
- database is created on a different
- <command>mysqld</command>.
- </para>
-
- <para>
- What this means is that if a <command>mysqld</command>
- process first connects to the cluster after a database
- named <replaceable>db_name</replaceable> has been created,
- you should issue a <literal>CREATE SCHEMA
- <replaceable>db_name</replaceable></literal> statement on
- the <quote>new</quote> MySQL server when it first accesses
- that MySQL Cluster. Once this has been done, the
- <quote>new</quote> <command>mysqld</command> should be
- able to detect any tables in that database tables without
- errors.
- </para>
-
- <para>
- This also means that online schema changes in
- <literal>NDB</literal> tables are now possible. That is,
- the result of operations such as <literal>ALTER
- TABLE</literal> and <literal>CREATE INDEX</literal>
- performed on one SQL node in the cluster are now visible
- to the cluster's other SQL nodes without any additional
- action being taken.
- </para>
- </listitem>
-
- <listitem>
- <para>
- Beginning with MySQL 5.1.10, it is possible to perform a
- Cluster backup and restore between different
- architectures. Previously — for example — you
- could not 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>
- </listitem>
-
- <listitem>
- <para>
- Beginning with MySQL 5.1.10, 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.1 searched
- only the default path — typically
- <filename>/usr/local/mysql/share/mysql/charsets</filename>
- — for character sets.)
- </para>
- </listitem>
-
- <listitem>
- <para>
- In MySQL 5.1, it is no longer necessary, when running
- multiple management servers, to restart all the cluster's
- data nodes to enable the management nodes to see one
- another.
- </para>
- </listitem>
-
- </itemizedlist>
+
+ <para>
+ What this means is that if a <command>mysqld</command>
+ process first connects to the cluster after a database
+ named <replaceable>db_name</replaceable> has been created,
+ you should issue a <literal>CREATE SCHEMA
+ <replaceable>db_name</replaceable></literal> statement on
+ the <quote>new</quote> MySQL server when it first accesses
+ that MySQL Cluster. Once this has been done, the
+ <quote>new</quote> <command>mysqld</command> should be
+ able to detect any tables in that database tables without
+ errors.
+ </para>
+
+ <para>
+ This also means that online schema changes in
+ <literal>NDB</literal> tables are now possible. That is,
+ the result of operations such as <literal>ALTER
+ TABLE</literal> and <literal>CREATE INDEX</literal>
+ performed on one SQL node in the cluster are now visible
+ to the cluster's other SQL nodes without any additional
+ action being taken.
+ </para>
</listitem>
<listitem>
+ <para>
+ Beginning with MySQL 5.1.10, it is possible to perform a
+ Cluster backup and restore between different
+ architectures. Previously — for example — you
+ could not 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>
+ </listitem>
+
+ <listitem>
<formalpara>
+ <title>Character sets</title>
+
+ <indexterm>
+ <primary>MySQL Cluster limitations</primary>
+ <secondary>character sets</secondary>
+ </indexterm>
+ <para>
+ Beginning with MySQL 5.1.10, 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.1 searched
+ only the default path — typically
+ <filename>/usr/local/mysql/share/mysql/charsets</filename>
+ — for character sets.)
+ </para></formalpara>
+ </listitem>
+
+ <listitem>
+ <para>
+ In MySQL 5.1, it is no longer necessary, when running
+ multiple management servers, to restart all the cluster's
+ data nodes to enable the management nodes to see one
+ another.
+ </para>
+ </listitem>
+
+
+ <listitem>
+ <formalpara>
<title>Length of <literal>CREATE TABLE</literal> statements</title>
<indexterm>
@@ -1303,35 +1336,76 @@
</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.1.7 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.
- </para>
+ </para></formalpara>
<para>
This limitation was removed for <literal>INSERT
- IGNORE</literal> and <literal>REPLACE</literal> in MySQL
- 5.1.8. (Bug #17431)
+ IGNORE</literal> and <literal>REPLACE</literal> in MySQL
+ 5.1.8. (See Bug #17431.)
</para>
</listitem>
-
+
<listitem>
+ <formalpara>
+ <title><literal>AUTO_INCREMENT</literal> columns</title>
<para>
In MySQL 5.1.10 and earlier versions, the maximum number
of tables having <literal>AUTO_INCREMENT</literal> columns
— including those belonging to hidden primary keys
— was 2048.
</para>
+ </formalpara>
<para>
This limitation was lifted in MySQL 5.1.11.
</para>
</listitem>
-
+
+ <listitem>
+
+ &mccge-warning-begin;
+ <formalpara>
+ <title>Maximum number of cluster nodes</title>
+ <para>
+ Prior to MySQL 5.1.15-ndb-6.1.1, the total maximum number
+ of nodes in a MySQL Cluster was 63, including all SQL
+ nodes (MySQL Servers), API nodes (applications accessing
+ the cluster other than MySQL servers), data nodes, and
+ management servers.
+ </para>
+ </formalpara>
+ <para>
+ Starting with MySQL 5.1.15-ndb-6.1.1, up to 255 API nodes
+ (including MySQL servers acting as cluster SQL nodes) are
+ supported by a single cluster. The total number of data
+ nodes and management nodes beginning with this version is
+ 63, of which up to 48 can be data nodes.
+ </para>
+
+ &mccge-warning-end-cluster;
+ </listitem>
+
</itemizedlist>
+ </para>
+
+
+
+
+
+
</section>
+</section>
\ No newline at end of file
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6514 - trunk/refman-5.1 | jon | 17 May |
