C Glossary of Cluster Terminology

This book uses a lot of special terminology in reference to MySQL Cluster. This appendix is designed to be a quick reference of what a term means with regard to MySQL Cluster. Each term is defined briefly.

arbitration

Arbitration is the process by which MySQL Cluster prevents a split-brain scenario from occurring. In the event of network failures such that there are possibly two survivable clusters that do not communicate, arbitration is used to decide which set of nodes is allowed to continue running. The arbitrator is the node that is in charge of making this decision.

 

arbitrator

The arbitrator is the node that is in charge of deciding which set of nodes will remain running in the event of a network partitioning scenario. This is normally the management node, but it can also be an SQL node if you manually set ArbitrationRank to 1 or 2 for the SQL node(s). In the event that the arbitrator fails, a new node is automatically elected as the new arbitrator.

 

checkpoint

Checkpointing is the process by which MySQL Cluster writes data and logs from memory onto disk. There are two different types of checkpoints: local and global. In a local checkpoint, all the data is written from memory to disk. In a global checkpoint process, the REDO log is written to disk.

 

cluster log

The cluster log is a centralized log that is generated by the management node reporting on various actions taken by the cluster and its member nodes. This includes actions such as a node failure, a node restart, arbitration, backups, and many other cluster actions. In addition to the cluster log, there are node logs, which are generated locally for each individual node on the disk local to the node.

 

data node

A data node is a node in MySQL Cluster that stores all the actual data. Normally, all access to the data is done through SQL nodes, not directly to the data node. The data nodes are also in charge of executing any parts of the query that are passed down to them from the SQL nodes.

 

fragment

Data in MySQL Cluster is horizontally partitioned into pieces that are spread around the different data nodes. These pieces are called fragments of data. There is a number of fragments equal to the number of data nodes in the MySQL Cluster setup, each one being approximately 1/N of the data, where N is the number of data nodes. For example, if you have 4 data nodes, each fragment is approximately 1/4 of the data.

 

hash index

MySQL Cluster uses a hash index to implement both primary and unique keys. Rather than reference the data directly, MySQL Cluster instead produces a hash of the data and references the generated hash directly. An example of the hash used in MySQL Cluster is MD5 (for Message Digest 5).

 

InnoDB

InnoDB is one of the standard transactional engines in MySQL. InnoDB makes use of the normal transactional concepts of REDO and UNDO logs in order to maintain transactional consistency. InnoDB is not clustered, but it can be used along with cluster tables on a single system.

 

management client

ndb_mgm is the management client, which provides an interface to the management daemon, which runs on the management node. The management client can be run on any machine that has unfirewalled access to the management daemon.

 

management node

The management node is used for both configuration and control of MySQL Cluster. It is a central repository for the configuration information that all other nodes communicate with to find out the MySQL Cluster setup. In addition, it is used for management purposes, such as centralized logging, starting and monitoring of backups, monitoring of node status, and shutting down of nodes in the cluster.

The management node is not required to be running for normal operations, but in most cases, you want it to always be running for the previously described management purposes. It is possible to set up multiple management servers for redundancy purposes. In such a case, one is the active node, and the second node serves as the backup in the event that the primary is unable to be contacted.

 

master node

In every MySQL Cluster setup, one node is designated as the master node. This is done automatically, based on which data node has been running the longest. The master designation is used only internally for many different processes, such as global checkpointing and node recovery. In the event that the master node fails, the surviving nodes automatically elect another node as the master.

 

MyISAM

MyISAM is a nontransactional stored engine that exists in MySQL. In it, data is stored in a normal disk-based setup; it is not clustered. MyISAM must currently be used for the system tables.

 

network partitioning

Network partitioning can occur in a cluster that gets separated and leaves behind two possible survivable pieces. A set of nodes is considered able to survive if it contains at least one node from each node group in the cluster. For example, if there are four data nodes and they get split into two groups of two from different node groups, this would be a possible network partitioning situation. This situation is also called a "split brain" problem. To prevent this from occurring, MySQL Cluster uses a process called arbitration.

 

node

A node is a single running instance of software in MySQL Cluster. There are three different types of nodes: data, SQL, and management nodes. A single physical computer may run single or multiple nodes.

 

node group

A node group is a set of data nodes that all contain the same data. This designation is important for knowing whether a cluster can survive a node failure. As long as there is at least one node running from each node group, the cluster is able to continue running and processing requests. Each node group has in it a number of data nodes equal to the value of NoOfReplicas. There is a number of node groups equal to the number of data nodes divided by NoOfReplicas.

 

partitioning

Data in MySQL Cluster is horizontally partitioned. This means that a single table has different rows stored on different data nodes. Partitioning means that no single node normally has all the data (except with small clusters, where the NoOfReplicas is equal to the number of data nodes). Currently, data is always partitioned according to a MD5 hash of PRIMARY KEY. MySQL 5.1 adds the ability to manually control this, which can possibly lead to more efficient storage, improved querying, and better performance.

 

replica

A replica is considered a copy of data. If you have two replicas of your data, you have two complete copies of the data across your cluster. You can control how many copies to keep by using the NoOfReplicas setting. Technically, you can set NoOfReplicas from 1 to 4, with 2 being the most common setting.

 

SCI (scalable coherent interface)

SCI is a clustering interconnect that can be used in place of normal TCP/IP in MySQL Cluster. Generally, SCI has lower latency and much better performance than TCP/IP-based connections, but it costs more for the hardware compared to traditional TCP/IP interconnects.

 

shared-nothing clustering

MySQL Cluster uses shared-nothing clustering, which means that each physical server in the cluster setup is a completely separate system from the other physical servers. All disks, RAM, CPUs, and so on are completely independent from each other in this setup. This is in contrast to shared-disk clustering, in which there is a single storage subsystem that all the nodes use.

 

split-brain

Split-brain is a concept in which a cluster of machines gets a network-partitioned scenario, and two separate clusters can continue to process requests. This is a very dangerous situation and is prevented by arbitration.

 

SQL node

An SQL node is a normal MySQL server (which must have MySQL-Max installed or be compiled with the option --with-ndbcluster) that has been set up to connect and communicate with a cluster setup. You interface to this by using any of the normal MySQL clients and APIs.

 

synchronous replication

Replication in MySQL Cluster is automatically done in a transparent, synchronous fashion. This means that when you are writing data to the cluster, the data is copied to multiple places by the time your query returns. It is guaranteed to already exist in multiple places. This is how the MySQL Cluster setup can do transparent failover because there is more than one copy of the data across the data nodes. In the event that the cluster cannot successfully replicate the data, the transaction is aborted. See also two-phase commit.

 

T-tree index

A T-tree index in MySQL Cluster is the normal, ordered index that exists for tables. This is similar in structure to a B-tree index that is used for InnoDB and MyISAM, but it is optimized for access in main memory systems. It can be used to resolve all the same queries that a B-tree index can resolve.

 

two-phase commit

Two-phase commit is the mechanism that MySQL Cluster uses in order to be able to guarantee that synchronous replication is taking place. This happens automatically, based on the NoOfReplicas setting. Two-phase commit is sometimes abbreviated as 2PC.