Known Limitations of NDB Cluster very large amounts of memory. Because of this, the transactional behavior of a number of MySQL statements is affected as described in the following list: When executing a  LOAD DATA  statement, the  NDB  engine performs commits at irregular intervals that enable better utilization of the communication network. It is not possible to know ahead of time when such commits take place. Starting, stopping, or restarting a node may give rise to temporary errors causing some transactions to fail. These include the following cases: In either of these cases, any errors that are generated must be handled within the application. This should be done by retrying the transaction. See also Section 23.1.7.2, “Limits and Differences of NDB Cluster from Standard MySQL Limits” . Some database objects such as tables and indexes have different limitations when using the  NDBCLUSTER storage engine: 3971 • Attributes per table.   The maximum number of attributes (that is, columns and indexes) that can belong to a given table is 512. • Number of database objects.   The maximum number of  all NDB  database objects in a single NDB Cluster—including databases, tables, and indexes—is limited to 20320. • Errors due to node failure.   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.) • Temporary errors.   When first starting a node, it is possible that you may see Error 1204  Temporary failure, distribution changed  and similar temporary errors. • Transactions and the COUNT() function.   When using NDB Cluster Replication, it is not possible to guarantee the transactional consistency of the  COUNT()  function on the replica. In other words, when performing on the source a series of statements ( INSERT ,  DELETE , or both) that changes the number of rows in a table within a single transaction, executing  SELECT COUNT(*) FROM  table  queries on the replica may yield intermediate results. This is due to the fact that  SELECT COUNT(...)  may perform dirty reads, and is not a bug in the  NDB  storage engine. (See Bug #31321 for more information.) • ALTER TABLE and transactions.   When copying an  NDB  table as part of an  ALTER TABLE , the creation of the copy is nontransactional. (In any case, this operation is rolled back when the copy is deleted.) • LOAD DATA statements.  LOAD DATA  is not transactional when used on  NDB  tables. • 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 TABLE  instead. • TRUNCATE TABLE  is not transactional when used on  NDB  tables. If a  TRUNCATE TABLE  fails to empty the table, then it must be re-run until it is successful. Important 23.1.7.4 NDB Cluster Error Handling 23.1.7.5 Limits Associated with Database Objects in NDB Cluster