content_image/755869.jpg
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: 

• 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. 

• 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. 

• LOAD DATA statements. LOAD DATA  is not transactional when used on NDB  tables. 

<img src='content_image/755869.jpg'>

## Important 

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. 

• 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.) 

• 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.) 

## 23.1.7.4 NDB Cluster Error Handling 

Starting, stopping, or restarting a node may give rise to temporary errors causing some transactions to fail. These include the following cases: 

• Temporary errors.  When first starting a node, it is possible that you may see Error 1204 Temporary failure, distribution changed  and similar temporary errors. 

• 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.) 

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” . 

## 23.1.7.5 Limits Associated with Database Objects in NDB Cluster 

Some database objects such as tables and indexes have different limitations when using the NDBCLUSTER storage engine: 

• 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. 

• Attributes per table.  The maximum number of attributes (that is, columns and indexes) that can belong to a given table is 512. 

