MySQL 5.6 Reference Manual Including MySQL NDB Cluster 7.3-7.4 Reference Guide
The following are limitations specific to the
NDB
storage engine:
Machine architecture. 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.
Binary logging. NDB Cluster has the following limitations or restrictions with regard to binary logging:
sql_log_bin
has no
effect on data operations; however, it is supported for
schema operations.
NDB Cluster cannot produce a binary log for tables
having BLOB
columns but
no primary key.
Only the following schema operations are logged in a cluster binary log which is not on the mysqld executing the statement:
Schema operations. Schema operations (DDL statements) are rejected while any data node restarts. Schema operations are also not supported while performing an online upgrade or downgrade.
Number of fragment replicas.
The number of fragment replicas, as determined by the
NoOfReplicas
data
node configuration parameter, is the number of copies of
all data stored by NDB Cluster. Setting this parameter to
1 means there is only a single copy; in this case, no
redundancy is provided, and the loss of a data node
entails loss of data. To guarantee redundancy, and thus
preservation of data even if a data node fails, set this
parameter to 2, which is the default and recommended value
in production.
Setting NoOfReplicas
to a value greater than 2 is possible (to a maximum of 4)
but unnecessary to guard against loss of data. In addition,
values greater than 2 for this parameter are not
supported in production.
See also Section 18.1.7.10, “Limitations Relating to Multiple NDB Cluster Nodes”.