5254 MySQL 8.0 FAQ: NDB Cluster information, as well as Section 13.1.20.5, “FOREIGN KEY Constraints” . Applications requiring foreign key support should use NDB Cluster 7.3, 7.4, 7.5, or later. You can import databases into NDB Cluster much as you would with any other version of MySQL. Other than the limitations mentioned elsewhere in this FAQ, the only other special requirement is that any tables to be included in the cluster must use the  NDB  storage engine. This means that the tables must be created with  ENGINE=NDB  or  ENGINE=NDBCLUSTER . It is also possible to convert existing tables that use other storage engines to  NDBCLUSTER  using one or more  ALTER TABLE  statement. However, the definition of the table must be compatible with the  NDBCLUSTER  storage engine prior to making the conversion. In MySQL 8.0, an additional workaround is also required; see Section 23.1.7, “Known Limitations of NDB Cluster” , for details. Cluster nodes can communicate through any of three different transport mechanisms: TCP/IP, SHM (shared memory), and SCI (Scalable Coherent Interface). Where available, SHM is used by default between nodes residing on the same cluster host; however, this is considered experimental. SCI is a high-speed (1 gigabit per second and higher), high-availability protocol used in building scalable multi-processor systems; it requires special hardware and drivers. See Section 23.3.4, “Using High- Speed Interconnects with NDB Cluster” , for more about using SCI as a transport mechanism for NDB Cluster. If one or more data nodes in a cluster fail, it is possible that not all cluster data nodes are able to “see”  one another. In fact, it is possible that two sets of data nodes might become isolated from one another in a network partitioning, also known as a “split-brain”  scenario. This type of situation is undesirable because each set of data nodes tries to behave as though it is the entire cluster. An arbitrator is required to decide between the competing sets of data nodes. When all data nodes in at least one node group are alive, network partitioning is not an issue, because no single subset of the cluster can form a functional cluster on its own. The real problem arises when no single node group has all its nodes alive, in which case network partitioning (the “split-brain”  scenario) becomes possible. Then an arbitrator is required. All cluster nodes recognize the same node as the arbitrator, which is normally the management server; however, it is possible to configure any of the MySQL Servers in the cluster to act as the arbitrator instead. The arbitrator accepts the first set of cluster nodes to contact it, and tells the remaining set to shut down. Arbitrator selection is controlled by the  ArbitrationRank  configuration parameter for MySQL Server and management server nodes. You can also use the  ArbitrationRank  configuration parameter to control the arbitrator selection process. For more information about these parameters, see Section 23.3.3.5, “Defining an NDB Cluster Management Server” . The role of arbitrator does not in and of itself impose any heavy demands upon the host so designated, and thus the arbitrator host does not need to be particularly fast or to have extra memory especially for this purpose. NDB Cluster supports all of the usual MySQL data types, including those associated with MySQL’s spatial extensions; however, the  NDB  storage engine does not support spatial indexes. (Spatial indexes are supported only by  MyISAM ; see Section 11.4, “Spatial Data Types” , for more information.) In addition, there are some differences with regard to indexes when used with  NDB tables. A.10.30. What data types are supported by NDB Cluster? A.10.29. What is an  arbitrator ? A.10.27. How do I import an existing MySQL database into an NDB Cluster? A.10.28. How do NDB Cluster nodes communicate with one another?