16.2. Basic MySQL Cluster Concepts
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 failover
and load-balancing options, but it is easiest to start with the
storage engine at the cluster level. MySQL Cluster's NDB storage
engine 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 portion of MySQL Cluster is currently configured
independently of the MySQL servers. In a MySQL Cluster, each part
of the cluster is considered to be a
node.
Note: In many contexts, the term
“node” is used to indicate a computer, but when
discussing MySQL Cluster it means a process.
There can be any number of nodes on a single computer, for which
we use the term cluster host.
There are three types of cluster nodes, and in a minimal MySQL
Cluster configuration, there will be at least three nodes, one of
each of these types:
The management node (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. An MGM node is
started with the command ndb_mgmd.
The data node: This is the
type of node that stores the cluster's data. There are as many
data nodes as there are replicas, times the number of
fragments. For example, with two replicas, each having two
fragments, you will need four data nodes. It is not necessary
to have more than one replica. A data node is started with the
command ndbd.
The SQL node: This is the
node that accesses the cluster data. In the case of MySQL
Cluster, a client node is a traditional MySQL server that uses
the NDB Cluster storage engine. An SQL node
is typically started with the command mysqld
--ndbcluster or by using mysqld
with the ndbcluster option added to
my.cnf.
For a brief introduction to the relationships between nodes, node
groups, replicas, and partitions in MySQL Cluster, see
Section 16.2.1, “MySQL Cluster Nodes, Node Groups, Replicas, and Partitions”.
Configuration of a cluster involves configuring each individual
node in the cluster and setting up individual communication links
between nodes. MySQL Cluster is currently designed with the
intention that storage 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 (MGM node) 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 are of two types:
Standard MySQL clients: These
are no different for MySQL Cluster than they are for standard
(non-Cluster) MySQL. In other words, MySQL Cluster can be
accessed from existing MySQL applications written in PHP,
Perl, C, C++, Java, Python, Ruby, and so on.
Management clients: These
clients connect to the management server and provide commands
for starting and stopping nodes gracefully, starting and
stopping message tracing (debug versions only), showing node
versions and status, starting and stopping backups, and so on.
