Oracle 5.0, Reference Manual

Page: 2903 / 3232

MySQL 5.0 FAQ: MySQL Cluster
2883
server. For more about these options, see Section 17.3.4.2, “
mysqld
Command Options for MySQL
Cluster” .
Note
An API node is any application that makes direct use of Cluster data nodes
for data storage and retrieval. An SQL node can thus be considered a
type of API node that uses a MySQL Server to provide an SQL interface
to the Cluster. You can write such applications (that do not depend on a
MySQL Server) using the NDB API, which supplies a direct, object-oriented
transaction and scanning interface to MySQL Cluster data; see
MySQL
Cluster API Overview: The NDB API , for more information.
B.10.7: When I run the
SHOW
command in the MySQL Cluster management client, I see a line of
output that looks like this:
id=2 @10.100.10.32 (Version: 5.0.96, Nodegroup: 0, Master)
What is a “master node”, and what does it do? How do I configure a node so that it is the
master?
The simplest answer is, “It's not something you can control, and it's nothing that you need to worry
about in any case, unless you're a software engineer writing or analyzing the MySQL Cluster source
code”.
If you don't find that answer satisfactory, here's a longer and more technical version:
A number of mechanisms in MySQL Cluster require distributed coordination among the data nodes.
These distributed algorithms and protocols include global checkpointing, DDL (schema) changes, and
node restart handling. To make this coordination simpler, the data nodes “elect” one of their number to
be a “master”. There is no user-facing mechanism for influencing this selection, which is is completely
automatic; the fact that it is automatic is a key part of MySQL Cluster's internal architecture.
When a node acts as a master for any of these mechanisms, it is usually the point of coordination for
the activity, and the other nodes act as “servants”, carrying out their parts of the activity as directed
by the master. If the node acting as master fails, then the remaining nodes elect a new master. Tasks
in progress that were being coordinated by the old master may either fail or be continued by the new
master, depending on the actual mechanism involved.
It is possible for some of these different mechanisms and protocols to have different master nodes, but
in general the same master is chosen for all of them. The node indicated as the master in the output
of
SHOW
in the management client is actually the
DICT
master (see The
DBDICT
Block , in the MySQL
Cluster API Developer Guide, for more information), responsible for coordinating DDL and metadata
activity.
MySQL Cluster is designed in such a way that the choice of master has no discernable effect outside
the cluster itself. For example, the current master does not have significantly higher CPU or resource
usage than the other data nodes, and failure of the master should not have a significantly different
impact on the cluster than the failure of any other data node.
B.10.8: With which operating systems can I use MySQL Cluster?
MySQL Cluster is supported on most Unix-like operating systems. Beginning with MySQL Cluster NDB
7.1.3, MySQL Cluster is also supported in production on Microsoft Windows operating systems.
Important
We do not intend to provide any level of support on Windows for MySQL Cluster
in MySQL 5.0; you must use MySQL Cluster NDB 7.1.3 or later to obtain GA-
level support for MySQL Cluster in a Windows environment. See
MySQL
Cluster Development in MySQL Cluster NDB 7.1 , for more information.