NDB is an in-memory storage engine offering high-availability and data-persistence features.
The NDB storage engine can be configured with a range of fail-over and load-balancing options, but it is easiest to start with the storage engine at the cluster level. The NDB storage engine of MySQL Cluster contains a complete set of data, dependent only on other data within the cluster itself.
We will now describe how to set up a MySQL Cluster consisting of an NDB storage engine and some MySQL servers.
The cluster part of MySQL Cluster is currently configured independently from the MySQL servers. In a MySQL Cluster, each part of the cluster is considered to be a node.
Note: A node is in many contexts a computer, but for MySQL Cluster it is a process. There can be any number of nodes on a single computer.
Each node has a type, and there can be multiple nodes in the MySQL Cluster of each type. In a minimal MySQL Cluster configuration, there will be at least three nodes:
The management (MGM) node. The role of this type of node is to manage the other nodes within the MySQL Cluster, such as providing configuration data, starting and stopping nodes, running backup, and so forth. Because this node type manages the configuration of the other nodes, a node of this type should be started first, before any other node. With a running cluster, the MGM node does not necessarily have to be running all the time. A MGM node is started with the command ndb_mgmd, for this reason NDB_MGMD is provided as an alias for MGM when configuring the cluster.
The storage or database (DB) node. This is the type of node that manages and stores the database itself. There are as many DB nodes as you have replicas times the number of fragments. That is, with two fragments, each with two replicas, you need four DB nodes. It is not necessary to have more than one replica, so a minimal MySQL Cluster may contain just one DB node. A DB node is started with the command ndbd, for this reason NDBD is provided as an alias for DB when configuring the cluster.
The client (API) node. This is the client node that will access the cluster, and in the case of MySQL Cluster, these are traditional MySQL servers with a new storage engine NDB Cluster which enables access to clustered tables. Basically, the MySQL server is a client of the NDB cluster. If you have applications that use the NDB API directly, then these are considered API nodes too. The MySQL server is typically started with the commands mysqld or mysqld_safe, for this reason MYSQLD is provided as an alias to API when configuring the cluster.
We refer to these cluster processes as nodes in the cluster. Setting up the configuration of the cluster involves configuring each individual node in the cluster and setting up each individual communication link between the nodes in the cluster. MySQL Cluster currently is designed with the intention that storage nodes are homogenous in terms of processor power, memory space, and communication bandwidth. Also, to enable one point of configuration, the entire cluster configuration is located in one configuration file.
The management server manages the cluster configuration file and the cluster log. All nodes in the cluster contact the management server to retrieve their part of the configuration, so they need a way to determine where the management server resides. When interesting events occur in the storage nodes, they transfer the information of these events to the management server, which then writes the information to the cluster log.
In addition, there are any number of clients to the cluster. These are of two types.
There are the normal MySQL clients that are no different for MySQL Cluster. MySQL Cluster can be accessed from all MySQL applications written in PHP, Perl, C, C++, Java, Ruby, and so forth.
There are management clients. These clients connect to the management server and provide commands to start and stop nodes gracefully, to start and stop message tracing (only in debug versions), to show node status of all nodes in the cluster, to show versions of all nodes in the cluster, to start and stop backups, and so forth.