Known Limitations of NDB Cluster • BIT columns.   A  BIT  column cannot be a primary key, unique key, or index, nor can it be part of a composite primary key, unique key, or index. • AUTO_INCREMENT columns.   Like other MySQL storage engines, the  NDB  storage engine can handle a maximum of one  AUTO_INCREMENT  column per table. However, in the case of an NDB table with no explicit primary key, an  AUTO_INCREMENT  column is automatically defined and used as a “hidden”  primary key. For this reason, you cannot define a table that has an explicit  AUTO_INCREMENT column unless that column is also declared using the  PRIMARY KEY  option. Attempting to create a table with an  AUTO_INCREMENT  column that is not the table’s primary key, and using the  NDB  storage engine, fails with an error. • Restrictions on foreign keys.   Support for foreign key constraints in NDB 8.0 is comparable to that provided by  InnoDB , subject to the following restrictions: •Every column referenced as a foreign key requires an explicit unique key, if it is not the table’s primary key. • ON UPDATE CASCADE  is not supported when the reference is to the parent table’s primary key. •As of NDB 8.0.16:  ON DELETE CASCADE  is not supported where the child table contains one or more columns of any of the  TEXT  or  BLOB  types. (Bug #89511, Bug #27484882) • SET DEFAULT  is not supported. (Also not supported by  InnoDB .) •The  NO ACTION  keyword is accepted but treated as  RESTRICT .  NO ACTION , which is a standard SQL keyword, is the default in MySQL 8.0. (Also the same as with  InnoDB .) •In earlier versions of NDB Cluster, when creating a table with foreign key referencing an index in another table, it sometimes appeared possible to create the foreign key even if the order of the columns in the indexes did not match, due to the fact that an appropriate error was not always returned internally. A partial fix for this issue improved the error used internally to work in most cases; however, it remains possible for this situation to occur in the event that the parent index is a unique index. (Bug #18094360) • NDB Cluster and geometry data types.  • Character sets and binary log files.   Currently, the  ndb_apply_status  and  ndb_binlog_index tables are created using the  latin1  (ASCII) character set. Because names of binary logs are recorded in this table, binary log files named using non-Latin characters are not referenced correctly in these tables. This is a known issue, which we are working to fix. (Bug #50226) Geometry data types ( WKT  and  WKB ) are supported for  NDB  tables. However, spatial indexes are not supported. To work around this problem, use only Latin-1 characters when naming binary log files or setting any the --basedir ,  --log-bin , or  --log-bin-index  options. 3966 For more information, see Section 13.1.20.5, “FOREIGN KEY Constraints” , and Section 1.7.3.2, “FOREIGN KEY Constraints” . This is because an update of a primary key is implemented as a delete of the old row (containing the old primary key) plus an insert of the new row (with a new primary key). This is not visible to the NDB  kernel, which views these two rows as being the same, and thus has no way of knowing that this update should be cascaded.