(mysql.info) mysql-cluster-limitations
Info Catalog
(mysql.info) mysql-cluster-interconnects
(mysql.info) ndbcluster
(mysql.info) mysql-cluster-roadmap
15.8 Known Limitations of MySQL Cluster
=======================================
In this section, we provide a list of known limitations in MySQL
Cluster releases in the 5.0.x series compared to features available
when using the `MyISAM' and `InnoDB' storage engines. Currently, there
are no plans to address these in coming releases of MySQL 5.0; however,
we will attempt to supply fixes for these issues in subsequent release
series. If you check the `Cluster' category in the MySQL bugs database
at `http://bugs.mysql.com', you can find known bugs which (if marked
`5.0') we intend to correct in upcoming releases of MySQL 5.0.
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
bug-reports. If we do not plan to fix the problem in MySQL 5.0, we
will add it to the list.
(* See the end of this section for a list of issues in MySQL 4.1
Cluster that have been resolved in the current version.)
* *Noncompliance in syntax* (resulting in errors when running
existing applications):
* Text indexes are not supported.
* A `BIT' column cannot be a primary key or part of a composite
primary key.
* Geometry datatypes (`WKT' and `WKB') are not supported by the
NDB storage engine prior to MySQL 5.0.16. (Note that spatial
indexes are still not supported in MySQL 5.0.16 and newer.)
* *Non-compliance in limits or behavior* (may result in errors when
running existing applications):
* *Error Reporting*:
* A duplicate key error returns the error message ERROR
23000: Can't write; duplicate key in table 'TBL_NAME'.
* *Transaction Handling*:
* `NDB Cluster' supports only the `READ COMMITTED'
transaction isolation level.
* There is no partial rollback of transactions. A
duplicate key or similar error results in a rollback of
the entire transaction.
* *Important*: If a `SELECT' from a Cluster table includes
a `BLOB', `TEXT', or `VARCHAR' column, the `READ
COMMITTED' 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.
* 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
mysql-cluster-config-file. Most configuration parameters
can be upgraded online. These hard limits include:
* Database memory size and index memory size (`DataMemory'
and `IndexMemory', respectively).
* The maximum number of transactions that can be performed
is set using the configuration parameters
`MaxNoOfConcurrentOperations' and
`MaxNoOfLocalOperations'. Note that bulk loading,
`TRUNCATE TABLE', and `ALTER TABLE' are handled as
special cases by running multiple transactions, and so
are not subject to this limitation.
* Different limits related to tables and indexes. For
example, the maximum number of ordered indexes per table
is determined by `MaxNoOfOrderedIndexes'.
* Database names, table names and attribute names cannot be as
long in `NDB' tables as with 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 `NDB Cluster' table name is 122
characters less the number of characters in the name of the
database of which that table is a part.)
* All Cluster table rows are of fixed length. This means (for
example) that if a table has one or more `VARCHAR' fields
containing only relatively small values, more memory and disk
space is required when using the `NDB' storage engine than
would be the case for the same table and data using the
`MyISAM' engine. (In other words, in the case of a `VARCHAR'
column, the column requires the same amount of storage as a
`CHAR' column of the same size.)
* The maximum number of tables in a Cluster database is limited
to 1792.
* The maximum number of attributes per table is limited to 128.
* The maximum permitted size of any one row is 8KB, _not
including data stored in `BLOB' columns_.
* The maximum number of attributes per key is 32.
* *Unsupported features* (do not cause errors, but are not supported
or enforced):
* The foreign key construct is ignored, just as it is in
`MyISAM' tables.
* Savepoints and rollbacks to savepoints are ignored as in
`MyISAM'.
* *Performance and limitation-related issues*:
* There are query performance issues due to sequential access
to the `NDB' storage engine; it is also relatively more
expensive to do many range scans than it is with either
`MyISAM' or `InnoDB'.
* The `Records in range' statistic is not supported, resulting
in non-optimal query plans in some cases. Employ `USE INDEX'
or `FORCE INDEX' as a workaround.
* Unique hash indexes created with `USING HASH' cannot be used
for accessing a table if `NULL' is given as part of the key.
* MySQL Cluster does not support durable commits on disk.
Commits are replicated, but there is no guarantee that logs
are flushed to disk on commit.
* *Missing features*:
* The only supported isolation level is `READ COMMITTED'.
(InnoDB supports `READ COMMITTED', `READ COMMITTED',
`REPEATABLE READ', and `SERIALIZABLE'.) See
mysql-cluster-backup-troubleshooting, for information on
how this can effect backup and restore of Cluster databases.
* No durable commits on disk. Commits are replicated, but there
is no guarantee that logs are flushed to disk on commit.
* *Problems relating to multiple MySQL servers* (not relating to
`MyISAM' or `InnoDB'):
* `ALTER TABLE' is not fully locking when running multiple
MySQL servers (no distributed table lock).
* 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.
* 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 DB_NAME is created or
imported using one MySQL server, you should issue a `CREATE
DATABASE DB_NAME' statement on each additional MySQL server
that accesses the same MySQL Cluster. (As of MySQL 5.0.2, you
may also use `CREATE SCHEMA DB_NAME'.) Once this has been
done for a given MySQL server, that server should be able to
detect the database tables without error.
* *Issues exclusive to MySQL Cluster* (not related to `MyISAM' or
`InnoDB'):
* 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 `mysql' or other clients that may be
accessing the cluster's SQL nodes.
* It is not possible to make online schema changes such as
those accomplished using `ALTER TABLE' or `CREATE INDEX', as
the `NDB Cluster' does not support autodiscovery of such
changes. (However, you can import or create a table that uses
a different storage engine, and then convert it to `NDB'
using `ALTER TABLE TBL_NAME ENGINE=NDBCLUSTER'. In such a
case, you must issue a `FLUSH TABLES' statement to force the
cluster to pick up the change.)
* Online adding or dropping of nodes is not possible (the
cluster must be restarted in such cases).
* When using multiple management servers:
* You must give nodes explicit IDs in connectstrings
because automatic allocation of node IDs does not work
across multiple management servers.
* You must take extreme care to have the same
configurations for all management servers. No special
checks for this are performed by the cluster.
* In order that management nodes be able to see one
another, you must restart all data nodes after bringing
up the cluster. (See Bug #13070
(http://bugs.mysql.com/13070) for a detailed
explanation.)
* Multiple network interfaces for data nodes 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.
* The maximum number of data nodes is 48.
* The total maximum number of nodes in a MySQL Cluster is 63.
This number includes all MySQL Servers (SQL nodes), data
nodes, and management servers.
The following Cluster limitations in MySQL 4.1 have been resolved in
MySQL 5.0 as shown below:
* The `NDB Cluster' storage engine supports all character sets and
collations available in MySQL 5.0.
* Prior to MySQL 5.0.6, the maximum number of metadata objects
possible was 1600. Beginning with 5.0.6, this limit is increased
to 20320.
* Cluster in MySQL 5.0 supports column indexes that make use of
prefixes.
* Unlike the case in MySQL 4.1, the Cluster storage engine in MySQL
5.0 supports MySQL' query cache. See query-cache.
Info Catalog
(mysql.info) mysql-cluster-interconnects
(mysql.info) ndbcluster
(mysql.info) mysql-cluster-roadmap
automatically generated byinfo2html