Cluster.  In its generic sense, a cluster is a set of computers functioning as a unit and working together to accomplish a single task.

NDBCLUSTER.  This is the storage engine used in MySQL to implement data storage, retrieval, and management distributed among several computers.

MySQL Cluster.  This refers to a group of computers working together using the NDB storage engine to support a distributed MySQL database in a shared-nothing architecture using in-memory storage.

Configuration files.  Text files containing directives and information regarding the cluster, its hosts, and its nodes. These are read by the cluster's management nodes when the cluster is started. See Section 16.3.4, “Configuration File”, for details.

Backup.  A complete copy of all cluster data, transactions and logs, saved to disk or other long-term storage.

Restore.  Returning the cluster to a previous state, as stored in a backup.

Checkpoint.  Generally speaking, when data is saved to disk, it is said that a checkpoint has been reached. More specific to Cluster, it is a point in time where all committed transactions are stored on disk. With regard to the NDB storage engine, there are two types of checkpoints which work together to ensure that a consistent view of the cluster's data is maintained:

Cluster host.  A computer making up part of a MySQL Cluster. A cluster has both a physical structure and a logical structure. Physically, the cluster consists of a number of computers, known as cluster hosts (or more simply as hosts. See also Node and Node group below.

Node.  This refers to a logical or functional unit of MySQL Cluster, and is sometimes also referred to as a cluster node. In the context of MySQL Cluster, we use the term “node” to indicate a process rather than a physical component of the cluster. There are three node types required to implement a working MySQL Cluster:

It is possible for more than one node to co-exist on a single machine. (In fact, it is even possible to set up a complete cluster on one machine, although one would almost certainly not want to do this in a production environment.) It may be helpful to remember that, when working with MySQL Cluster, the term host refers to a physical component of the cluster whereas a node is a logical or functional component (that is, a process).

Note Regarding Terms.  In volder versions of the MySQL Cluster documentation, data nodes were sometimes referred to as “database nodes”. The term “storage nodes” has also been used. In addition, SQL nodes were sometimes known as “client nodes”. This older terminology has been deprecated to minimize confusion, and for this reason should be avoided. They are also often referred to as “API nodes” — an SQL node is actually an API node that provides an SQL interface to the cluster.

Node group.  A set of data nodes. All data nodes in a node group contain the same data (fragments), and all nodes in a single group should reside on different hosts. It is possible to control which nodes belong to which node groups.

For more information, see Section 16.1.2, “MySQL Cluster Nodes, Node Groups, Replicas, and Partitions”.

Node failure.  MySQL Cluster is not solely dependent upon the functioning of any single node making up the cluster; the cluster can continue to run if one or more nodes fail. The precise number of node failures that a given cluster can tolerate depends upon the number of nodes and the cluster's configuration.

Node restart.  The process of restarting a failed cluster node.

Initial node restart.  The process of starting a cluster node with its filesystem removed. This is sometimes used in the course of software upgrades and in other special circumstances.

System crash (or system failure).  This can occur when so many cluster nodes have failed that the cluster's state can no longer be guaranteed.

System restart.  The process of restarting the cluster and reinitializing its state from disk logs and checkpoints. This is required after either a planned or an unplanned shutdown of the cluster.

Fragment.  A portion of a database table; in the NDB storage engine, a table is broken up into and stored as a number of fragments. A fragment is sometimes also called a “partition”; however, “fragment” is the preferred term. Tables are fragmented in MySQL Cluster in order to facilitate load balancing between machines and nodes.

Replica.  Under the NDB storage engine, each table fragment has number of replicas stored on other data nodes in order to provide redundancy. Currently, there may be up four replicas per fragment.

Transporter.  A protocol providing data transfer between nodes. MySQL Cluster currently supports four different types of transporter connections:

NDB.  This stands for Network Database, and refers to the storage engine used to enable MySQL Cluster. The NDB storage engine supports all the usual MySQL data types and SQL statements, and is ACID-compliant. This engine also provides full support for transactions (commits and rollbacks).

Shared-nothing architecture.  The ideal architecture for a MySQL Cluster. In a true shared-nothing setup, each node runs on a separate host. The advantage such an arrangement is that there no single host or node can act as single point of failure or as a performance bottle neck for the system as a whole.

In-memory storage.  All data stored in each data node is kept in memory on the node's host computer. For each data node in the cluster, you must have available an amount of RAM equal to the size of the database times the number of replicas, divided by the number of data nodes. Thus, if the database takes up 1GB of memory, and you want to set up the cluster with four replicas and eight data nodes, a minimum of 500MB memory will be required per node. Note that this is in addition to any requirements for the operating system and any other applications that might be running on the host.

Table.  As is usual in the context of a relational database, the term “table” denotes a set of identically structured records. In MySQL Cluster, a database table is stored in a data node as a set of fragments, each of which is replicated on additional data nodes. The set of data nodes replicating the same fragment or set of fragments is referred to as a node group.

Cluster programs.  These are command-line programs used in running, configuring, and administering MySQL Cluster. They include both server daemons:

and client programs:

For more about these programs and their uses, see Section 16.6, “Process Management in MySQL Cluster”.

Event log.  MySQL Cluster logs events by category (startup, shutdown, errors, checkpoints, and so on), priority, and severity. A complete listing of all reportable events may be found in Section 16.7.3, “Event Reports Generated in MySQL Cluster”. Event logs are of two types:

Under normal circumstances, it is necessary and sufficient to keep and examine only the cluster log. The node logs need be consulted only for application development and debugging purposes.

Angel process.  When a data node is started, ndbd actually starts two processes. One of these is known as the “angel” process; its purpose is to check to make sure that the main ndbd process continues to run, and to restart the main process if it should stop for any reason.

Watchdog thread.  Each ndbd process has an internal watchdog thread which monitors the main worker thread, ensuring forward progress and a timely response to cluster protocols such as the cluster heartbeat. If the ndbd process is not being woken up promptly by the operating system when its sleep time expires, INFO and WARNING events, which are identifiable because they contain “Watchdog:...”, are written to the cluster log. Such messages are usually a symptom of an overloaded system; you should see what else is running on the system, and whether the ndbd process is being swapped out to disk. If ndbd cannot wake up regularly then it cannot respond to heartbeat messages on time, and other nodes eventually consider it “dead” due to the missed heartbeats, causing it to be excluded from the cluster.