Author: jstephens
Date: 2007-05-18 11:33:19 +0200 (Fri, 18 May 2007)
New Revision: 6521
Log:
Start reworking of 5.0 Cluster Limitations.
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 09:32:26 UTC (rev 6520)
+++ trunk/refman-5.0/mysql-cluster-limitations-working.xml 2007-05-18 09:33:19 UTC (rev 6521)
Changed blocks: 6, Lines Added: 258, Lines Deleted: 155; 16979 bytes
@@ -20,16 +20,16 @@
<para>
In this section, we provide a list of known limitations in MySQL
- Cluster releases in the ¤t-series;.x series compared to
+ Cluster releases in the 5.0.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
+ 5.0; 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;.
+ which (if marked <quote>5.0</quote>) we intend to
+ correct in upcoming releases of MySQL 5.0.
</para>
<para>
@@ -37,12 +37,12 @@
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.
+ the problem in MySQL 5.0, we will add it to the list.
</para>
<para>
(<emphasis role="bold">Note</emphasis>: See the end of this
- section for a list of issues in MySQL &previous-series; Cluster
+ section for a list of issues in MySQL 4.1 Cluster
that have been resolved in the current version.)
</para>
@@ -741,70 +741,7 @@
</itemizedlist>
</listitem>
- <listitem>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>multiple MySQL servers</secondary>
- </indexterm>
- <para>
- <emphasis role="bold">Problems relating to multiple MySQL
- servers</emphasis> (not relating to <literal>MyISAM</literal>
- or <literal>InnoDB</literal>):
- </para>
-
- <itemizedlist>
-
- <listitem>
- <para>
- <literal>ALTER TABLE</literal> is not fully locking when
- running multiple MySQL servers (no distributed table
- lock).
- </para>
- </listitem>
-
- <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>
-
- <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. (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>
-
- <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>
-
- </itemizedlist>
- </listitem>
-
<listitem>
<indexterm>
<primary>MySQL Cluster limitations</primary>
@@ -868,69 +805,6 @@
<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;, such configurations can be
- considered experimental only.
- </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>
-
- <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.
- </para>
-
- <para>
- (See Bug #12307 and Bug #13070 for more information.)
- </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
@@ -971,51 +845,278 @@
</listitem>
</itemizedlist>
-
+
+ <section id="mysql-cluster-limitations-syntax">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-limits">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-transactions">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-error-handling">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-database-objects">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-unsupported-missing">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-performance">
+ <title></title>
+ </section>
+
+ <section id="mysql-cluster-limitations-exclusive-to-cluster">
+ <title></title>
+ </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>
+
+ <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
+ <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>
+ </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
+ TABLE</literal>), the data dictionary is locked and no
+ 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:
+
+
+ <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>
+
+ <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.
+ </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.
+ <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 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>
- <indexterm>
- <primary>MySQL Cluster limitations</primary>
- <secondary>resolved in current version from previous versions</secondary>
- </indexterm>
-
+
<para>
The <literal>NDB Cluster</literal> storage engine supports all
character sets and collations available in MySQL
- ¤t-series;.
+ 5.0.
</para>
</listitem>
-
+
<listitem>
<para>
Prior to MySQL 5.0.6, the maximum number of metadata objects
- possible was 1600. Beginning with 5.0.6, this limit is
+ possible was 1600. Beginning with MySQL 5.0.6, this limit is
increased to 20320.
</para>
</listitem>
-
+
<listitem>
<para>
- Cluster in MySQL ¤t-series; supports column indexes that
+ MySQL Cluster in MySQL 5.0 supports column indexes that
make use of prefixes.
</para>
</listitem>
-
- <listitem>
+
+ <listitem><formalpara>
+ <title>Query cache</title>
<para>
- Unlike the case in MySQL &previous-series;, the Cluster
- storage engine in MySQL ¤t-series; supports MySQL'
+ 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>
+ </para></formalpara>
</listitem>
-
- <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
@@ -1026,9 +1127,11 @@
path — typically
<filename>/usr/local/mysql/share/mysql/charsets</filename>
— for character sets.)
- </para>
+ </para></formalpara>
</listitem>
-
+
</itemizedlist>
-
</section>
+
+
+ </section>
| Thread |
|---|
| • svn commit - mysqldoc@docsrva: r6521 - trunk/refman-5.0 | jon | 18 May |
