Oracle 5.0 Reference Manual page 2905

MySQL 5.0 FAQ: MySQL Cluster
less CPU must be utilized (because fewer indexes must be read and possibly updated). However, it
also means that queries that could otherwise use range scans must be satisfied by other means, which
can result in slower selects.
When calculating Cluster memory requirements, you may find useful the utility
ndb_size.pl
which is available in recent MySQL 5.0 releases. This Perl script connects to a current (non-Cluster)
MySQL database and creates a report on how much space that database would require if it used
the storage engine. For more information, see Section 17.4.18, "ndb_size.pl —
NDBCLUSTER
NDBCLUSTER Size Requirement Estimator".
It is especially important to keep in mind that every MySQL Cluster table must have a primary key. The
storage engine creates a primary key automatically if none is defined; this primary key is created
NDB
without
USING HASH.
There is no easy way to determine exactly how much memory is being used for storage of MySQL
Cluster indexes at any given time; however, warnings are written to the cluster log when 80% of
available [1559] or [1560] is in use, and again when usage reaches 85%,
DataMemory IndexMemory
90%, and so on.
B.10.11: What file systems can I use with MySQL Cluster? What about network file systems or
network shares?
Generally, any file system that is native to the host operating system should work well with MySQL
Cluster. If you find that a given file system works particularly well (or not so especially well) with MySQL
Cluster, we invite you to discuss your findings in the MySQL Cluster Forums.
We do not test MySQL Cluster with or file systems on Linux. Because of this, and due to
FAT VFAT
the fact that these are not very useful for any purpose other than sharing disk partitions between Linux
and Windows operating systems on multi-boot computers, we do not recommend their use with MySQL
Cluster.
MySQL Cluster is implemented as a shared-nothing solution; the idea behind this is that the failure of
a single piece of hardware should not cause the failure of multiple cluster nodes, or possibly even the
failure of the cluster as a whole. For this reason, the use of network shares or network file systems is
not supported for MySQL Cluster. This also applies to shared storage devices such as SANs.
B.10.12: Can I run MySQL Cluster nodes inside virtual machines (such as those created by
VMWare, Parallels, or Xen)?
This is possible but not recommended for a production environment with MySQL Cluster versions prior
to MySQL Cluster NDB 7.2.
For deployment in virtualized environments, you should use MySQL Cluster NDB 7.2 (or later).
B.10.13: I am trying to populate a MySQL Cluster database. The loading process
terminates prematurely and I get an error message like this one:
ERROR 1114: The table
Why is this happening?
'my_cluster_table' is full
The cause is very likely to be that your setup does not provide sufficient RAM for all table data and all
indexes, including the primary key required by the storage engine and automatically created in the
NDB
event that the table definition does not include the definition of a primary key.
It is also worth noting that all data nodes should have the same amount of RAM, since no data node
in a cluster can use more memory than the least amount available to any individual data node. For
example, if there are four computers hosting Cluster data nodes, and three of these have 3GB of RAM
available to store Cluster data while the remaining data node has only 1GB RAM, then each data node
can devote at most 1GB to MySQL Cluster data and indexes.
In some cases it is possible to get errors in MySQL client applications even when
Table is full
shows significant free [1559]. You can
ndb_mgm -e "ALL REPORT MEMORYUSAGE" DataMemory
force to create extra partitions for MySQL Cluster tables and thus have more memory available
NDB
2885