From: jon
Date: May 18 2007 4:02pm
Subject: svn commit - mysqldoc@docsrva: r6534 - trunk/refman-4.1
List-Archive: http://lists.mysql.com/commits/27004
Message-Id: <200705181602.l4IG2C2x009353@docsrva.mysql.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
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;
]>
+
+ Known Limitations of MySQL Cluster
+
+
+ MySQL Cluster limitations
+
+
+
+ limitations of MySQL Cluster
+
+
+
+ In the sections that follow, we discuss known limitations in MySQL
+ ¤t-series; Cluster releases as compared with the features
+ available when using the MyISAM and
+ InnoDB 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 Cluster
+ category in the MySQL bugs database at
+ , you can find known bugs which
+ (if marked ¤t-series;
) we intend to correct in
+ upcoming releases of MySQL ¤t-series;.
+
+
+
+ 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
+ . If we do not plan to fix the problem
+ in MySQL ¤t-series;, we will add it to the list.
+
- Known Limitations of MySQL Cluster
+
+
+
+
+ Non-Compliance In SQL Syntax
+
MySQL Cluster limitations
+ syntax
-
- limitations of MySQL Cluster
-
-
-
- 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 MyISAM and
- InnoDB 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
- Cluster
category in the MySQL bugs database at
- , you can find known bugs
- which (if marked ¤t-series;
) we intend to
- correct in upcoming releases of MySQL ¤t-series;.
-
+ Some SQL statements relating to certain MySQL features produce
+ errors when used with NDB tables, as described
+ in the following list:
-
- 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 . If we do not plan to fix
- the problem in MySQL ¤t-series;, we will add it to the list.
-
+
-
+
+
-
-
- MySQL Cluster limitations
- syntax
-
+ Temporary tables
-
- Noncompliance in syntax
- (resulting in errors when running existing applications):
-
-
-
-
-
- Temporary tables are not supported.
+ Temporary tables are not supported. Trying either to
+ create a temporary table that uses the
+ NDB storage engine or to alter an
+ existing temporary table to use NDB
+ fails with the error Table storage engine
+ 'ndbcluster' does not support the create option
+ 'TEMPORARY'.
-
-
-
- Not all charsets and collations are supported; see
- , for a list of
- those that are supported.
-
-
+
+
-
-
- There are no prefix indexes; only entire fields can be
- indexed.
-
-
+
+
-
+ Indexes and keys in <literal>NDB</literal> tables
+
- You cannot create indexes on NDB table
- columns that use any of the TEXT or
- BLOB data types.
-
+ Keys and indexes on MySQL Cluster tables are subject to
+ the following limitations:
-
- The NDB storage engine also does not
- support FULLTEXT indexes (these are
- supported by MyISAM only).
+
+
+
+
+ You cannot create indexes on NDB
+ table columns that use any of the
+ TEXT or BLOB
+ data types.
+
+
+
+
+
+ The NDB storage engine does not
+ support FULLTEXT indexes, which
+ are possible for MyISAM tables
+ only.
+
+
+
+ However, you can create indexes on
+ VARCHAR columns of
+ NDB tables.
+
+
+
+
+
+ There are no prefix indexes; only entire fields can be
+ indexed.
+
+
+
+
+
+ A BIT column cannot be a primary
+ key, unique key, or index, nor can it be part of a
+ composite primary key, unique key, or index.
+
+
+
+
+
+
+ Duplicate keys
+
+
+ A duplicate key error returns the error message
+ ERROR 23000: Can't write; duplicate key
+ in table
+ 'tbl_name'.
+
+
+
+
+
+
+
+
+ <literal>AUTO_INCREMENT</literal> columns
+
+
+ Like other MySQL storage engines, the
+ NDB storage engine can handle a
+ maximum of one AUTO_INCREMENT
+ column per table. However, in the case of a
+ Cluster table with no explicit primary key, an
+ AUTO_INCREMENT column is
+ automatically defined and used as a
+ hidden
primary key. For this
+ reason, you cannot define a table that has an
+ explicit AUTO_INCREMENT column
+ unless that column is also declared using the
+ PRIMARY KEY option. Attempting
+ to create a table with an
+ AUTO_INCREMENT column that is
+ not the table's primary key, and using the
+ NDB storage engine, fails with
+ an error.
+
+
+
+
+
+
+
+
+
+
+
+
+ MySQL Cluster and geometry data types
+
+
+ MySQL Cluster limitations
+ geometry data types
+
+
- However, you can index VARCHAR columns
- of NDB tables.
+ Geometry datatypes (WKT and
+ WKB) are supported in
+ NDB tables in MySQL ¤t-series;.
+ However, spatial indexes are not supported.
-
-
+
+
+
+
+
+ Character set support
- A BIT column cannot be a primary key,
- unique key, or index, nor can it be part of a composite
- primary key, unique key, or index.
-
-
+
+ Not all charsets and collations are supported; see
+ , for a list of
+ those that are supported.
+
+
+
+
+ Character set directory
+
+
+
+
+ ndbd searches only the default path
+ (typically
+ /usr/local/mysql/share/mysql/charsets)
+ for character sets. Thus, it is not possible to install
+ MySQL with Cluster support in a different path (in the
+ case of the .tar.gz archives, other
+ than /usr/local/mysql) if character
+ sets that are not compiled into the MySQL Server need to
+ be used.
+
+
+
+
+
+
-
+
+
+
+ Row-based replication
+
MySQL Cluster limitations
- geometry datatypes
+ replication
- Geometry datatypes (WKT and
- WKB) are not supported.
+ When using row-based replication with MySQL Cluster,
+ binary logging cannot be disabled. That is, the
+ NDB storage engine ignores the value of
+ SQL_LOG_BIN. (Bug #16680)
-
-
+
+
+
+
+
+
+ <literal>auto_increment_increment</literal> and
+ <literal>auto_increment_offset</literal>
+
- INSERT IGNORE 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 auto_increment_increment and
+ auto_increment_offset server system
+ variables are not supported for Cluster replication.
-
-
-
+
+
-
-
- MySQL Cluster limitations
- causing errors
-
+
+
-
- Non-compliance in limits or
- behavior (may result in errors when running
- existing applications):
-
+
-
+
-
-
- memory use
- in MySQL Cluster
-
+ Limits and Differences from Standard MySQL Limits
-
- MySQL Cluster
- memory usage and recovery
-
+
+ MySQL Cluster limitations
+ and differences from standard MySQL limits
+
-
- DELETE
- and MySQL Cluster
-
+
+ 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.
-
- DROP TABLE
- and MySQL Cluster
-
+
-
- TRUNCATE
- and MySQL Cluster
-
+
+
+ memory use
+ in MySQL Cluster
+
-
- Memory Usage:
-
+
+ MySQL Cluster
+ memory usage and recovery
+
+
+ DELETE
+ and MySQL Cluster
+
+
+
+ DROP TABLE
+ and MySQL Cluster
+
+
+
+ TRUNCATE
+ and MySQL Cluster
+
+
+
+
+ Memory usage and recovery
+
Memory comsumed when data is inserted into an
NDB table is not automatically
recovered when deleted, as it is with other storage
engines. Instead, the following rules hold true:
-
-
+
-
-
- A DELETE statement on an
- NDB 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 NDB tables.
-
-
+
+
+ A DELETE statement on an
+ NDB 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
+ NDB tables.
+
+
-
-
- A DROP TABLE or
- TRUNCATE operation on an
- NDB table frees the memory that was
- used by this table for re-use by any
- NDB table — either by the
- same table or by another NDB table.
-
+
+
+ A DROP TABLE or
+ TRUNCATE operation on an
+ NDB table frees the memory that
+ was used by this table for re-use by any
+ NDB table, either by the same
+ table or by another NDB table.
+
-
- (Recall that TRUNCATE drops and
- re-creates the table. See .)
-
+
+
+ Recall that TRUNCATE drops and
+ re-creates the table. See
+ .
+
+
-
- Memory freed by DELETE 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
- .
-
-
+
+ Memory freed by DELETE 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
+ .
+
+
-
-
+
+
-
-
- Error Reporting:
+ Limits imposed by the cluster's configuration
+
+
+ MySQL Cluster limitations
+ imposed by configuration
+
+
+
+ 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
+ . Most
+ configuration parameters can be upgraded online.
+ These hard limits include:
+
+
+
+
+
+ Database memory size and index memory size
+ (DataMemory and
+ IndexMemory,
+ respectively).
+
+
+
+ DataMemory is allocated
+ as 32KB pages. As each
+ DataMemory page is used,
+ it is assigned to a specific table; once
+ allocated, this memory cannot be freed
+ except by dropping the table.
+
+
+
+ See
+ ,
+ for further information about
+ DataMemory and
+ IndexMemory.
+
+
+
+
+
+ The maximum number of operations that can be
+ performed per transaction is set using the
+ configuration parameters
+ MaxNoOfConcurrentOperations
+ and
+ MaxNoOfLocalOperations.
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+ Memory usage
+
+
+ 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.)
+
+
+
+
+
+
+
+
+ Node and data object maximums
+
+
+ The following limits apply to numbers of cluster
+ nodes and metadata objects:
+
+
+
+
+
+ The maximum number of data nodes is 48.
+
+
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ The maximum number of metadata objects is limited to 1600,
+ including database tables, system tables, indexes and
+ BLOB columns.
+
+
+
+
+
+
+
+
+
+
+
+
-
+
+
-
-
- A duplicate key error returns the error message
- ERROR 23000: Can't write; duplicate key in
- table
- 'tbl_name'.
-
-
+
+
-
-
- Like other MySQL storage engines, the
- NDB storage engine can handle a
- maximum of one AUTO_INCREMENT
- column per table. However, in the case of a Cluster
- table with no explicit primary key, an
- AUTO_INCREMENT column is
- automatically defined and used as a
- hidden
primary key. For this reason,
- you cannot define a table that has an explicit
- AUTO_INCREMENT column unless that
- column is also declared using the PRIMARY
- KEY option.
-
+
+
+
+ Limits Relating to Transaction Handling
+
+
+ MySQL Cluster limitations
+ transactions
+
+
+
+ A number of limitations exist in MySQL Cluster with regard to the
+ handling of transactions. These include the following:
+
+
+
+
+
+
+ Transaction isolation level
+
+
+ The NDBCLUSTER storage engine supports
+ only the READ COMMITTED transaction
+ isolation level.
+
+
- Attempting to create a table with an
- AUTO_INCREMENT column that is not
- the table's primary key, and using the
- NDB storage engine, fails with an
- error.
+ If a SELECT from a Cluster table
+ includes a BLOB or
+ TEXT 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.
-
+
+
-
-
+
+
-
-
- MySQL Cluster limitations
- transactions
-
+
+
+ Rollbacks
+
- Transaction Handling:
+ There is no partial rollback of transactions. A duplicate
+ key or similar error rolls back the entire transaction.
-
+
+
-
-
- 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.
-
-
+ Transactions and memory usage
-
-
- 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.
-
-
+
+ MySQL Cluster limitations
+ memory usage and transaction handling
+
-
-
- 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.
-
+
+ MySQL Cluster
+ transaction handling
+
-
- 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:
-
+
+ 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:
-
+
-
-
- TRUNCATE is not transactional
- when used on NDB tables. If a
- TRUNCATE fails to empty the
- table, then it must be re-run until it is
- successful.
-
-
+
+
+ TRUNCATE is not transactional
+ when used on NDB tables. If a
+ TRUNCATE fails to empty the
+ table, then it must be re-run until it is
+ successful.
+
+
-
-
- DELETE FROM (even with no
- WHERE clause)
- is transactional. For tables
- containing a great many rows, you may find that
- performance is improved by using several
- DELETE FROM ... LIMIT ...
- statements to chunk
the delete
- operation. If the objective is to empty the table,
- then you may wish to use
- TRUNCATE instead.
-
-
+
+
+ DELETE FROM (even with no
+ WHERE clause)
+ is transactional. For tables
+ containing a great many rows, you may find that
+ performance is improved by using several
+ DELETE FROM ... LIMIT ...
+ statements to chunk
the delete
+ operation. If your objective is to empty the table,
+ then you may wish to use TRUNCATE
+ instead.
+
+
-
+
+
+
+ <literal>LOAD DATA</literal> statements
+
LOAD DATA INFILE is not
- transactional. During such an operation the
- NDB engine can and does commit
- at will.
-
+ transactional when used on NDB
+ tables.
-
+
+
+ When executing a LOAD DATA
+ INFILE statement, the
+ NDB engine can and does
+ commit at will.
+
+
+
LOAD DATA FROM MASTER is not
supported in MySQL Cluster.
-
-
+
+
+
+
+
+
+ <literal>ALTER TABLE</literal> and transactions
+
- When copying a table as part of an ALTER
- TABLE, the creation of the copy is
- non-transactional. (In any case, this operation is
- rolled back when the copy is deleted.)
+ When copying an NDB table as
+ part of an ALTER TABLE, the
+ creation of the copy is non-transactional. (In any
+ case, this operation is rolled back when the copy
+ is deleted.)
-
-
-
+
+
-
-
- Node Start, Stop, or
- Restart:: Starting, stopping, or restarting
- a node may give rise to temporary errors causing some
- transactions to fail. These include the following
- cases:
-
+
+
-
+
+
-
-
- When first starting a node, it is possible that
- you may see Error 1204 Temporary
- failure, distribution changed and
- similar temporary errors.
-
-
+
+
-
-
- 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.)
-
-
+
-
+
-
- In either of these cases, any errors that are
- generated must be handled within the application. This
- should be done by retrying the transaction.
-
-
+ Error Handling
-
-
+
+ MySQL Cluster limitations
+ error handling and reporting
+
-
-
- MySQL Cluster limitations
- imposed by configuration
-
+
+ Starting, stopping, or restarting a node may give rise to
+ temporary errors causing some transactions to fail. These include
+ the following cases:
+
+
+
+
+
+ Temporary errors
+
- 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
- . 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 Temporary failure, distribution
+ changed and similar temporary errors.
-
+
+
-
-
- Database memory size and index memory size
- (DataMemory and
- IndexMemory, respectively).
-
+
+
-
- DataMemory is allocated as 32KB
- pages. As each DataMemory page is
- used, it is assigned to a specific table; once
- allocated, this memory cannot be freed except by
- dropping the table.
-
+ Errors due to node failure
-
- See ,
- for further information about
- DataMemory and
- IndexMemory.
-
-
+
+ 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.)
+
-
-
- The maximum number of operations that can be performed
- per transaction 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.
-
-
+
+
-
-
+
+ In either of these cases, any errors that are generated must be
+ handled within the application. This should be done by retrying
+ the transaction.
+
-
-
- MySQL Cluster limitations
- database objects
-
+
+ See also .
+
+
+
+
+
+ Limits Associated with Database Objects
+
+
+ MySQL Cluster limitations
+ database objects
+
+
+
+ Some database objects such as tables and indexes have different
+ limitations when using the NDBCLUSTER storage
+ engine:
+
+
+
+
+
+
+ Identifiers
+
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
+ as long in NDB 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 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.)
+ maximum of 122 characters. In other words, the maximum
+ length for an NDB table name is 122
+ characters, less the number of characters in the name of
+ the database of which that table is a part.
-
-
+
+
+
+
+
+
+ Number of tables
+
- 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 in
+ MySQL 5.0 is limited to 1792.
-
-
+
+
+
+
+
+
+ Attributes per table
+
- The maximum number of metadata objects is limited to 1600,
- including database tables, system tables, indexes and
- BLOBs.
+ The maximum number of attributes (that is, columns and
+ indexes) per table is limited to 128.
-
-
+
+
+
+
+
+
+ Attributes per key
+
- The maximum number of attributes per table is limited to
- 128.
+ The maximum number of attributes per key is 32.
-
-
+
+
+
+
+
+
+ Row size
+
The maximum permitted size of any one row is 8KB. Note
that each BLOB or
- TEXT column contributes a maximum of
- 256 bytes towards this total.
+ TEXT column contributes 256 + 8 = 264
+ bytes towards this total.
-
-
-
- The maximum number of attributes per key is 32.
-
-
+
+
-
-
+
+
-
-
- MySQL Cluster limitations
- unsupported features
-
+
-
- Unsupported features (do not
- cause errors, but are not supported or enforced):
-
+
+ Unsupported Or Missing Features
+
+
+ MySQL Cluster limitations
+ unsupported features
+
+
+
+
+ Unsupported Features
+
+
+ A number of features supported by other storage engines are not
+ supported for NDB 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:
+
-
- The foreign key construct is ignored, just as it is in
- MyISAM tables.
-
+
+
+ Foreign key constraints
+
+
+ The foreign key construct is ignored, just as it is in
+ MyISAM tables.
+
+
+
-
- Savepoints and rollbacks to savepoints are ignored as in
- MyISAM.
-
+
+
+ Savepoints and rollbacks
+
+
+ Savepoints and rollbacks to savepoints are ignored as in
+ MyISAM.
+
+
+
-
- OPTIMIZE operations are not supported.
-
+
+
+ <literal>OPTIMIZE</literal> operations
+
+
+ OPTIMIZE operations are not
+ supported.
+
+
+
-
- LOAD TABLE ... FROM MASTER is not
- supported.
-
+
+
+ <literal>LOAD TABLE ... FROM MASTER</literal>
+
+
+ LOAD TABLE ... FROM MASTER is not
+ supported.
+
+
+
-
+
-
-
- MySQL Cluster limitations
- performance
-
+
-
- Performance and limitation-related
- issues:
-
+
+ Missing Features
+
+
-
- The query cache is disabled, since it is not invalidated
- if an update occurs on a different MySQL server.
-
+
+
+ Transaction isolation
+
+
+ The only supported isolation level is READ
+ COMMITTED. (InnoDB supports READ
+ COMMITTED, READ
+ UNCOMMITTED, REPEATABLE
+ READ, and SERIALIZABLE.)
+ See
+ ,
+ for information on how this can affect backup and
+ restore of Cluster databases.
+
+
+
+
+
+ Durability
+
+
+ No durable commits on disk. Commits are replicated, but
+ there is no guarantee that logs are flushed to disk on
+ commit.
+
+
+
+
+
+
+
+
+
+
+
+
+ See ,
+ for more information relating to limitations on transaction
+ handling in NDB.
+
+
+
+
+
+
-
+
-
-
- The only supported isolation level is READ
- COMMITTED. (InnoDB supports READ
- COMMITTED, READ UNCOMMITTED,
- REPEATABLE READ, and
- SERIALIZABLE.) See
- ,
- for information on how this can affect backup and restore
- of Cluster databases.
-
-
+ Issues Exclusive to MySQL Cluster
-
-
- No durable commits on disk. Commits are replicated, but
- there is no guarantee that logs are flushed to disk on
- commit.
-
-
+
+ MySQL Cluster limitations
+ implementation
+
-
-
+
+ The following are limitations specific to the
+ NDBCLUSTER storage engine, and do not occur
+ with MyISAM or InnoDB:
-
-
- MySQL Cluster limitations
- multiple MySQL servers
-
+
-
- Problems relating to multiple MySQL
- servers (not relating to MyISAM
- or InnoDB):
-
+
+
-
+ Machine architecture
-
- ALTER TABLE is not fully locking when
- running multiple MySQL servers (no distributed table
- lock).
-
-
+ The following issues relate to physical architecture of
+ cluster hosts:
-
-
- 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. Once this has been done for a
- given MySQL server, that server should be able to detect
- the database tables without error.
-
-
+
+
+ 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.
+
+
-
-
- DDL operations are not node failure safe. If a node fails
- while trying to peform one of these (such as
- CREATE TABLE or ALTER
- TABLE), the data dictionary is locked and no
- further DDL statements can be executed without restarting
- the cluster.
-
-
+
+
-
-
+ Adding and dropping of data nodes
-
-
- MySQL Cluster limitations
- implementation
-
+
+ Online adding or dropping of data nodes is not
+ currently possible. In such cases, the entire
+ cluster must be restarted.
+
-
- 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.
-
-
+ Backup and restore between architectures
-
-
- 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)
+
+ 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)
+
+
+
+
+
+
-
-
+
+
+
+
+
+
+ Online schema changes
+
It is not possible to make online schema changes such as
those accomplished using ALTER TABLE or
@@ -861,119 +1227,213 @@
issue a FLUSH TABLES statement to force
the cluster to pick up the change.)
-
+
+
+
+
+
+
+
+
+
+
+ Limitations Relating to Multiple Cluster Nodes
+
+
+
+ Multiple SQL nodes
+
+
+ MySQL Cluster limitations
+ multiple MySQL servers
+
+
+
+ The following are issues relating to the use of multiple MySQL
+ servers as MySQL Cluster SQL nodes, and are specific to the
+ NDBCLUSTER storage engine:
+
+
+
-
- Online adding or dropping of nodes is not possible (the
- cluster must be restarted in such cases).
-
+
+
+ <literal>ALTER TABLE</literal> operations
+
+
+ ALTER TABLE is not fully locking when
+ running multiple MySQL servers (no distributed table
+ lock).
+
+
+
-
- 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
- ndbd process is run on a single
- physical machine.
-
+
-
- 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.
-
+ Replication
+
+
+ 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.
+
+
+
-
- MySQL Cluster limitations
- multiple management servers
-
+
-
- When using multiple management servers:
-
+ Database autodiscovery
-
+
+ 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.
+
-
-
- 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.
-
-
+
+
-
-
- 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.
-
+ DDL operations
-
- (See Bug #12307 and Bug #13070 for more information.)
-
-
+
+ DDL operations are not node failure safe. If a node
+ fails while trying to peform one of these (such as
+ CREATE TABLE or ALTER
+ TABLE), the data dictionary is locked and no
+ further DDL statements can be executed without
+ restarting the cluster.
+
-
+
+
+
+
+
+
+
+
+ Multiple management nodes
+
+
+ MySQL Cluster limitations
+ multiple management servers
+
+
+
+ When using multiple management servers:
+
+
+
- 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.
+
+
- 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 [TCP]
- section per connection in the
- config.ini file. See
- , 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.
- 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.
-
-
- 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.)
-
+
-
+
+
+
+ Multiple data node processes
+
+
+ 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 ndbd
+ process is run on a single physical machine.
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+ Multiple network addresses
+
+
+ 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.
+
+
+
+ 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 [TCP] section per connection in
+ the config.ini file. See
+ , for more
+ information.
+
+
+
+
+
+
+
+