Oracle 5.0 Reference Manual page 1537

MySQL 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, replicas, and partitions in
MySQL Cluster, see Section 17.1.2, "MySQL Cluster Nodes, Node Groups, Replicas, and
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 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 (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.
in PHP, Perl, C, C++, Java, Python, Ruby, and so on. Such client applications send SQL statements
to and receive responses from MySQL servers acting as MySQL Cluster SQL nodes in much
the same way that they interact with standalone MySQL servers. However, MySQL clients using
a MySQL Cluster as a data source can be modified to take advantage of the ability to connect
with multiple MySQL servers to achieve load balancing and failover. For example, Java clients
using Connector/J 5.0.6 and later can use
Connector/J 5.1.7) to achieve load balancing transparently .
• Management clients.
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. Such clients
—such as the
ndb_mgm
"ndb_mgm — The MySQL Cluster Management
language API that communicates directly with one or more MySQL Cluster management servers. For
more information, see
Event logs. 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
"Event Reports Generated in MySQL
• Cluster log. Keeps a record of all desired reportable events for the cluster as a whole.
• Node log. A separate log which is also kept for each individual node.
Note
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.
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
ensure that a consistent view of the cluster's data is maintained:
• Local Checkpoint (LCP).
take place for all nodes in the cluster more or less concurrently. An LCP involves saving all of a
node's data to disk, and so usually occurs every few minutes. The precise interval varies, and
depends upon the amount of data stored by the node, the level of cluster activity, and other factors.
MySQL Cluster Core Concepts
MySQL Cluster can be used with existing MySQL applications written
jdbc:mysql:loadbalance://
These clients connect to the management server and provide commands
management client supplied with MySQL Cluster (see
The MGM API.
Cluster". Event logs are of two types:
storage engine, there are two types of checkpoints which work together to
NDB
This is a checkpoint that is specific to a single node; however, LCP's
1517
Client")—are written using the MGM API, a C-
Partitions".
URLs (improved in
Section 17.4.3,
Section 17.5.6,