Known Limitations of NDB Cluster •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: • CREATE TABLE • ALTER TABLE • DROP TABLE • CREATE DATABASE  /  CREATE SCHEMA • DROP DATABASE  /  DROP SCHEMA • CREATE TABLESPACE • ALTER TABLESPACE • DROP TABLESPACE • CREATE LOGFILE GROUP • ALTER LOGFILE GROUP • DROP LOGFILE GROUP • 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. •Maximum number of tablespaces: 2$^{32}$ (4294967296) •Maximum number of data files per tablespace: 2$^{16}$ (65536) •The minimum and maximum possible sizes of extents for tablespace data files are 32K and 2G, respectively. See Section 13.1.21, “CREATE TABLESPACE Statement” , for more information. 3974 In addition, when working with NDB Disk Data tables, you should be aware of the following issues regarding data files and extents: Disk Data object maximums and minimums.   Disk data objects are subject to the following maximums and minimums: See also Section 23.1.7.10, “Limitations Relating to Multiple NDB Cluster Nodes” . Setting  NoOfReplicas  to a value greater than 2 is supported (to a maximum of 4) but unnecessary to guard against loss of data. 23.1.7.9 Limitations Relating to NDB Cluster Disk Data Storage