NDB Cluster Core Concepts • Management node : The role of this type of node is to manage the other nodes within the NDB Cluster, performing such functions as providing configuration data, starting and stopping nodes, and running backups. Because this node type manages the configuration of the other nodes, a node of this type should be started first, before any other node. A management node is started with the command ndb_mgmd . • Data node : This type of node stores cluster data. There are as many data nodes as there are fragment replicas, times the number of fragments (see Section 23.1.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions” ). For example, with two fragment replicas, each having two fragments, you need four data nodes. One fragment replica is sufficient for data storage, but provides no redundancy; therefore, it is recommended to have two (or more) fragment replicas to provide redundancy, and thus high availability. A data node is started with the command  ndbd  (see Section 23.4.1, “ndbd — The NDB Cluster Data Node Daemon” ) or  ndbmtd  (see Section 23.4.3, “ndbmtd — The NDB Cluster Data Node Daemon (Multi-Threaded)” ). • SQL node : This is a node that accesses the cluster data. In the case of NDB Cluster, an SQL node is a traditional MySQL server that uses the  NDBCLUSTER  storage engine. An SQL node is a  mysqld  process started with the  --ndbcluster  and  --ndb-connectstring  options, which are explained elsewhere in this chapter, possibly with additional MySQL server options as well. NDB Cluster tables are normally stored completely in memory rather than on disk (this is why we refer to NDB Cluster as an  in-memory  database). However, some NDB Cluster data can be stored on disk; see Section 23.5.10, “NDB Cluster Disk Data Tables” , for more information. An SQL node is actually just a specialized type of  API node , which designates any application which accesses NDB Cluster data. Another example of an API node is the  ndb_restore  utility that is used to restore a cluster backup. It is possible to write such applications using the NDB API. For basic information about the NDB API, see Getting Started with the NDB API. It is not realistic to expect to employ a three-node setup in a production environment. Such a configuration provides no redundancy; to benefit from NDB Cluster’s high-availability features, you must use multiple data and SQL nodes. The use of multiple management nodes is also highly recommended. For a brief introduction to the relationships between nodes, node groups, fragment replicas, and partitions in NDB Cluster, see Section 23.1.2, “NDB Cluster Nodes, Node Groups, Fragment Replicas, and Partitions” . Configuration of a cluster involves configuring each individual node in the cluster and setting up individual communication links between nodes. NDB Cluster is currently designed with the intention that data nodes are homogeneous in terms of processor power, memory space, and bandwidth. In addition, to provide a single point of configuration, all configuration data for the cluster as a whole is located in one configuration file. The management server manages the cluster configuration file and the cluster log. Each node in the cluster retrieves the configuration data from the management server, and so requires a way to determine where the management server resides. When interesting events occur in the data nodes, the nodes transfer information about these events to the management server, which then writes the information to the cluster log. In addition, there can be any number of cluster client processes or applications. These include standard MySQL clients,  NDB -specific API programs, and management clients. These are described in the next few paragraphs. 3927 Important