Table of Contents
This section describes the basics for planning, installing, configuring, and running an NDB Cluster. Whereas the examples in Chapter 5, Configuration of NDB Cluster provide more in-depth information on a variety of clustering options and configuration, the result of following the guidelines and procedures outlined here should be a usable NDB Cluster which meets the minimum requirements for availability and safeguarding of data.
For information about upgrading or downgrading an NDB Cluster between release versions, see Section 4.7, “Upgrading and Downgrading NDB Cluster 7.2”.
This section covers hardware and software requirements; networking issues; installation of NDB Cluster; configuration issues; starting, stopping, and restarting the cluster; loading of a sample database; and performing queries.
Assumptions. The following sections make a number of assumptions regarding the cluster's physical and network configuration. These assumptions are discussed in the next few paragraphs.
Cluster nodes and host computers. The cluster consists of four nodes, each on a separate host computer, and each with a fixed network address on a typical Ethernet network as shown here:
| Node | IP Address |
|---|---|
| Management node (mgmd) | 192.168.0.10 |
| SQL node (mysqld) | 192.168.0.20 |
| Data node "A" (ndbd) | 192.168.0.30 |
| Data node "B" (ndbd) | 192.168.0.40 |
This may be made clearer by the following diagram:
Network addressing.
In the interest of simplicity (and reliability), this
How-To uses only numeric IP addresses.
However, if DNS resolution is available on your network, it is
possible to use host names in lieu of IP addresses in configuring
Cluster. Alternatively, you can use the hosts
file (typically /etc/hosts for Linux and
other Unix-like operating systems,
C:\WINDOWS\system32\drivers\etc\hosts on
Windows, or your operating system's equivalent) for providing
a means to do host lookup if such is available.
Potential hosts file issues.
A common problem when trying to use host names for Cluster nodes
arises because of the way in which some operating systems
(including some Linux distributions) set up the system's own
host name in the /etc/hosts during
installation. Consider two machines with the host names
ndb1 and ndb2, both in the
cluster network domain. Red Hat Linux
(including some derivatives such as CentOS and Fedora) places the
following entries in these machines'
/etc/hosts files:
# ndb1 /etc/hosts:
127.0.0.1 ndb1.cluster ndb1 localhost.localdomain localhost
# ndb2 /etc/hosts:
127.0.0.1 ndb2.cluster ndb2 localhost.localdomain localhost
SUSE Linux (including OpenSUSE) places these entries in the
machines' /etc/hosts files:
# ndb1 /etc/hosts:
127.0.0.1 localhost
127.0.0.2 ndb1.cluster ndb1
# ndb2 /etc/hosts:
127.0.0.1 localhost
127.0.0.2 ndb2.cluster ndb2
In both instances, ndb1 routes
ndb1.cluster to a loopback IP address, but gets a
public IP address from DNS for ndb2.cluster,
while ndb2 routes ndb2.cluster
to a loopback address and obtains a public address for
ndb1.cluster. The result is that each data node
connects to the management server, but cannot tell when any other
data nodes have connected, and so the data nodes appear to hang
while starting.
You cannot mix localhost and other host names
or IP addresses in config.ini. For these
reasons, the solution in such cases (other than to use IP
addresses for all
config.ini HostName
entries) is to remove the fully qualified host names from
/etc/hosts and use these in
config.ini for all cluster hosts.
Host computer type. Each host computer in our installation scenario is an Intel-based desktop PC running a supported operating system installed to disk in a standard configuration, and running no unnecessary services. The core operating system with standard TCP/IP networking capabilities should be sufficient. Also for the sake of simplicity, we also assume that the file systems on all hosts are set up identically. In the event that they are not, you should adapt these instructions accordingly.
Network hardware. Standard 100 Mbps or 1 gigabit Ethernet cards are installed on each machine, along with the proper drivers for the cards, and that all four hosts are connected through a standard-issue Ethernet networking appliance such as a switch. (All machines should use network cards with the same throughput. That is, all four machines in the cluster should have 100 Mbps cards or all four machines should have 1 Gbps cards.) NDB Cluster works in a 100 Mbps network; however, gigabit Ethernet provides better performance.
NDB Cluster is not intended for use in a network for which throughput is less than 100 Mbps or which experiences a high degree of latency. For this reason (among others), attempting to run an NDB Cluster over a wide area network such as the Internet is not likely to be successful, and is not supported in production.
Sample data.
We use the world database which is available
for download from the MySQL Web site (see
http://dev.mysql.com/doc/index-other.html). We assume that
each machine has sufficient memory for running the operating
system, required NDB Cluster processes, and (on the data nodes)
storing the database.
For general information about installing MySQL, see Installing and Upgrading MySQL. For information about installation of NDB Cluster on Linux and other Unix-like operating systems, see Section 4.1, “Installing NDB Cluster on Linux”. For information about installation of NDB Cluster on Windows operating systems, see Section 4.2, “Installing NDB Cluster on Windows”.
For general information about NDB Cluster hardware, software, and networking requirements, see Section 3.3, “NDB Cluster Hardware, Software, and Networking Requirements”.
This section covers installation of NDB Cluster on Linux and other Unix-like operating systems. While the next few sections refer to a Linux operating system, the instructions and procedures given there should be easily adaptable to other supported Unix-like platforms.
NDB Cluster 7.2 is also available for Windows operating systems; for installation and setup instructions specific to Windows, see Section 4.2, “Installing NDB Cluster on Windows”.
Each NDB Cluster host computer must have the correct executable programs installed. A host running an SQL node must have installed on it a MySQL Server binary (mysqld). Management nodes require the management server daemon (ndb_mgmd); data nodes require the data node daemon (ndbd or ndbmtd). It is not necessary to install the MySQL Server binary on management node hosts and data node hosts. It is recommended that you also install the management client (ndb_mgm) on the management server host.
Installation of NDB Cluster on Linux can be done using precompiled binaries from Oracle (downloaded as a .tar.gz archive), with RPM packages (also available from Oracle), or from source code. All three of these installation methods are described in the section that follow.
Regardless of the method used, it is still necessary following installation of the NDB Cluster binaries to create configuration files for all cluster nodes, before you can start the cluster. See Section 4.3, “Initial Configuration of NDB Cluster”.
This section covers the steps necessary to install the correct executables for each type of Cluster node from precompiled binaries supplied by Oracle.
For setting up a cluster using precompiled binaries, the first
step in the installation process for each cluster host is to
download the latest NDB Cluster 7.2 binary archive
(mysql-cluster-gpl-7.2.27-linux-i686-glibc23.tar.gz)
from the NDB Cluster
downloads area. We assume that you have placed this file
in each machine's /var/tmp directory.
(If you do require a custom binary, see
Installing MySQL Using a Development Source Tree.)
After completing the installation, do not yet start any of the binaries. We show you how to do so following the configuration of the nodes (see Section 4.3, “Initial Configuration of NDB Cluster”).
SQL nodes.
On each of the machines designated to host SQL nodes, perform
the following steps as the system root
user:
Check your /etc/passwd and
/etc/group files (or use whatever tools
are provided by your operating system for managing users and
groups) to see whether there is already a
mysql group and mysql
user on the system. Some OS distributions create these as
part of the operating system installation process. If they
are not already present, create a new
mysql user group, and then add a
mysql user to this group:
shell>groupadd mysqlshell>useradd -g mysql -s /bin/false mysql
The syntax for useradd and groupadd may differ slightly on different versions of Unix, or they may have different names such as adduser and addgroup.
Change location to the directory containing the downloaded
file, unpack the archive, and create a symbolic link named
mysql to the mysql
directory. Note that the actual file and directory names
vary according to the NDB Cluster version number.
shell>cd /var/tmpshell>tar -C /usr/local -xzvf mysql-cluster-gpl-7.2.27-linux2.6.tar.gzshell>ln -s /usr/local/mysql-cluster-gpl-7.2.27-linux2.6-i686 /usr/local/mysql
Change location to the mysql directory
and run the supplied script for creating the system
databases:
shell>cd mysqlshell>scripts/mysql_install_db --user=mysql
Set the necessary permissions for the MySQL server and data directories:
shell>chown -R root .shell>chown -R mysql datashell>chgrp -R mysql .
Copy the MySQL startup script to the appropriate directory, make it executable, and set it to start when the operating system is booted up:
shell>cp support-files/mysql.server /etc/rc.d/init.d/shell>chmod +x /etc/rc.d/init.d/mysql.servershell>chkconfig --add mysql.server
(The startup scripts directory may vary depending on your
operating system and version—for example, in some
Linux distributions, it is
/etc/init.d.)
Here we use Red Hat's chkconfig for creating links to the startup scripts; use whatever means is appropriate for this purpose on your platform, such as update-rc.d on Debian.
Remember that the preceding steps must be repeated on each machine where an SQL node is to reside.
Data nodes.
Installation of the data nodes does not require the
mysqld binary. Only the NDB Cluster data
node executable ndbd (single-threaded) or
ndbmtd (multi-threaded) is required. These
binaries can also be found in the .tar.gz
archive. Again, we assume that you have placed this archive in
/var/tmp.
As system root (that is, after using
sudo, su root, or your
system's equivalent for temporarily assuming the system
administrator account's privileges), perform the following steps
to install the data node binaries on the data node hosts:
Change location to the /var/tmp
directory, and extract the ndbd and
ndbmtd binaries from the archive into a
suitable directory such as
/usr/local/bin:
shell>cd /var/tmpshell>tar -zxvf mysql-5.5.53-ndb-7.2.27-linux-i686-glibc23.tar.gzshell>cd mysql-5.5.53-ndb-7.2.27-linux-i686-glibc23shell>cp bin/ndbd /usr/local/bin/ndbdshell>cp bin/ndbmtd /usr/local/bin/ndbmtd
(You can safely delete the directory created by unpacking
the downloaded archive, and the files it contains, from
/var/tmp once
ndb_mgm and ndb_mgmd
have been copied to the executables directory.)
Change location to the directory into which you copied the files, and then make both of them executable:
shell>cd /usr/local/binshell>chmod +x ndb*
The preceding steps should be repeated on each data node host.
Although only one of the data node executables is required to run an NDB Cluster data node, we have shown you how to install both ndbd and ndbmtd in the preceding instructions. We recommend that you do this when installing or upgrading NDB Cluster, even if you plan to use only one of them, since this will save time and trouble in the event that you later decide to change from one to the other.
The data directory on each machine hosting a data node is
/usr/local/mysql/data. This piece of
information is essential when configuring the management node.
(See Section 4.3, “Initial Configuration of NDB Cluster”.)
Management nodes.
Installation of the management node does not require the
mysqld binary. Only the NDB Cluster
management server (ndb_mgmd) is required;
you most likely want to install the management client
(ndb_mgm) as well. Both of these binaries
also be found in the .tar.gz archive.
Again, we assume that you have placed this archive in
/var/tmp.
As system root, perform the following steps
to install ndb_mgmd and
ndb_mgm on the management node host:
Change location to the /var/tmp
directory, and extract the ndb_mgm and
ndb_mgmd from the archive into a suitable
directory such as /usr/local/bin:
shell>cd /var/tmpshell>tar -zxvf mysql-5.5.53-ndb-7.2.27-linux2.6-i686.tar.gzshell>cd mysql-5.5.53-ndb-7.2.27-linux2.6-i686shell>cp bin/ndb_mgm* /usr/local/bin
(You can safely delete the directory created by unpacking
the downloaded archive, and the files it contains, from
/var/tmp once
ndb_mgm and ndb_mgmd
have been copied to the executables directory.)
Change location to the directory into which you copied the files, and then make both of them executable:
shell>cd /usr/local/binshell>chmod +x ndb_mgm*
In Section 4.3, “Initial Configuration of NDB Cluster”, we create configuration files for all of the nodes in our example NDB Cluster.
This section covers the steps necessary to install the correct executables for each type of NDB Cluster node using RPM packages supplied by Oracle.
RPMs are available for both 32-bit and 64-bit Linux platforms. The filenames for these RPMs use the following pattern:
MySQL-Cluster-component-producttype-ndbversion.distribution.architecture.rpmcomponent:= {server | client [|other]}producttype:= {gpl | advanced}ndbversion:=major.minor.releasedistribution:= {sles10 | rhel5 | el6}architecture:= {i386 | x86_64}
The component can be
server or client. (Other
values are possible, but since only the
server and client
components are required for a working NDB Cluster installation,
we do not discuss them here.) The
producttype for Community RPMs
downloaded from http://dev.mysql.com/downloads/cluster/ is
always gpl; advanced is
used to indicate commercial releases.
ndbversion represents the three-part
NDB storage engine version number in
7.2.x format. The
distribution can be one of
sles11 (SUSE Enterprise Linux 11),
rhel5 (Oracle Linux 5, Red Hat Enterprise
Linux 4 and 5), or el6 (Oracle Linux 6, Red
Hat Enterprise Linux 6) The
architecture is
i386 for 32-bit RPMs and
x86_64 for 64-bit versions.
For an NDB Cluster, one and possibly two RPMs are required:
The server RPM (for example,
MySQL-Cluster-server-gpl-7.2.27-1.sles11.i386.rpm),
which supplies the core files needed to run a MySQL Server
with NDBCLUSTER storage engine
support (that is, as an NDB Cluster SQL node) as well as all
NDB Cluster executables, including the management node, data
node, and ndb_mgm client binaries. This
RPM is always required for installing NDB Cluster 7.2.
If you do not have your own client application capable of
administering a MySQL server, you should also obtain and
install the client RPM (for example,
MySQL-Cluster-client-gpl-7.2.27-1.sles11.i386.rpm),
which supplies the mysql client
The NDB Cluster version number in the RPM file names (shown here
as 7.2.27) can vary
according to the version which you are actually using.
It is very important that all of the Cluster RPMs to
be installed have the same version number. The
architecture designation should be
appropriate to the machine on which the RPM is to be installed;
in particular, you should keep in mind that 64-bit RPMs cannot
be used with 32-bit operating systems.
Data nodes.
On a computer that is to host a cluster data node it is
necessary to install only the server RPM.
To do so, copy this RPM to the data node host, and run the
following command as the system root user, replacing the name
shown for the RPM as necessary to match that of the RPM
downloaded from the MySQL web site:
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.2.27-1.sles11.i386.rpm
Although this installs all NDB Cluster binaries, only the
program ndbd or ndbmtd
(both in /usr/sbin) is actually needed to
run an NDB Cluster data node.
SQL nodes.
On each machine to be used for hosting a cluster SQL node,
install the server RPM by executing the
following command as the system root user, replacing the name
shown for the RPM as necessary to match the name of the RPM
downloaded from the MySQL web site:
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.2.27-1.sles11.i386.rpm
This installs the MySQL server binary
(mysqld) with
NDB storage engine support in the
/usr/sbin directory, as well as all needed
MySQL Server support files. It also installs the
mysql.server and
mysqld_safe startup scripts (in
/usr/share/mysql and
/usr/bin, respectively). The RPM installer
should take care of general configuration issues (such as
creating the mysql user and group, if needed)
automatically.
To administer the SQL node (MySQL server), you should also
install the client RPM, as shown here:
shell> rpm -Uhv MySQL-Cluster-client-gpl-7.2.27-1.sles11.i386.rpm
This installs the mysql client program.
Management nodes.
To install the NDB Cluster management server, it is necessary
only to use the server RPM. Copy this RPM
to the computer intended to host the management node, and then
install it by running the following command as the system root
user (replace the name shown for the RPM as necessary to match
that of the server RPM downloaded from the
MySQL web site):
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.2.27-1.sles11.i386.rpm
Although this RPM installs many other files, only the management
server binary ndb_mgmd (in the
/usr/sbin directory) is actually required
for running a management node. The server RPM
also installs ndb_mgm, the
NDB management client.
See Installing MySQL on Linux Using RPM Packages, for general information about installing MySQL using RPMs supplied by Oracle.
After installing from RPM, you still need to configure the cluster as discussed in Section 4.3, “Initial Configuration of NDB Cluster”.
A number of RPMs used by NDB Cluster 7.1 were made obsolete
and discontinued in NDB Cluster 7.2. These include the former
MySQL-Cluster-clusterj,
MySQL-Cluster-extra,
MySQL-Cluster-management,
MySQL-Cluster-storage, and NDB
Cluster-tools RPMs; all of these have been merged
into the MySQL-Cluster-server RPM. When
upgrading from an NDB Cluster 7.1 RPM installation to NDB
7.2.3 or an earlier NDB Cluster 7.2 release, it was necessary
to remove these packages manually before installing the NDB
Cluster 7.2 MySQL-Cluster-server RPM. This
issue is fixed in NDB 7.2.4 and later, where the
MySQL-Cluster-server package specifically
obsoletes the discontinued packages (BUG #13545589).
The section provides information about installing NDB Cluster on Debian and related Linux distributions such Ubuntu using the .deb files supplied by Oracle for this purpose.
Oracle provides .deb installer files for
NDB Cluster 7.2 for 32-bit and 64-bit platforms. For a
Debian-based system, only a single installer file is necessary.
This file is named using the pattern shown here, according to
the applicable NDB Cluster version, Debian version, and
architecture:
mysql-cluster-gpl-ndbver-debiandebianver-arch.deb
Here, ndbver is the 3-part
NDB engine version number,
debianver is the major version of
Debian (for NDB Cluster 7.2, this is always
6.0), and arch is
one of i686 or x86_64. In
the examples that follow, we assume you wish to install NDB
7.2.21 on a 64-bit Debian 6 system; in this case, the installer
file is named
mysql-cluster-gpl-7.2.21-debian6.0-x86_64.deb.
Once you have downloaded the appropriate
.deb file, you can install it from the
command line using dpkg, like this:
shell> dpkg -i mysql-cluster-gpl-7.2.21-debian6.0-i686.deb
You can also remove it using dpkg as shown
here:
shell> dpkg -r mysql
The installer file should also be compatible with most graphical
package managers that work with .deb files,
such as GDebi for the Gnome desktop.
The .deb file installs NDB Cluster under
/opt/mysql/server-,
where version/version is the 2-part release
series version for the included MySQL server. For NDB Cluster
7.2, this is always 5.5. The directory layout
is the same as that for the generic Linux binary distribution
(see MySQL Installation Layout for Generic Unix/Linux Binary Package), with the
exception that startup scripts and configuration files are found
in support-files instead of
share. All NDB Cluster executables, such as
ndb_mgm, ndbd, and
ndb_mgmd, are placed in the
bin directory.
This section provides information about compiling NDB Cluster on Linux and other Unix-like platforms. Building NDB Cluster from source is similar to building the standard MySQL Server, although it differs in a few key respects discussed here. For general information about building MySQL from source, see Installing MySQL from Source. For information about compiling NDB Cluster on Windows platforms, see Section 4.2.2, “Compiling and Installing NDB Cluster from Source on Windows”.
Building NDB Cluster requires using the NDB Cluster sources.
These are available from the NDB Cluster downloads page at
http://dev.mysql.com/downloads/cluster/. The archived source
file should have a name similar to
mysql-cluster-gpl-7.2.27.tar.gz.
You can also obtain MySQL development sources from
launchpad.net. Attempting to build NDB Cluster
from standard MySQL Server 5.5 sources is not
supported.
The WITH_NDBCLUSTER_STORAGE_ENGINE
option for CMake causes the binaries for the
management nodes, data nodes, and other NDB Cluster programs to
be built; it also causes mysqld to be
compiled with NDB storage engine
support. This option (or its alias
WITH_NDBCLUSTER) is required when
building NDB Cluster.
Beginning with NDB 7.2.9, the
WITH_NDB_JAVA option is enabled
by default. This means that, by default, if
CMake cannot find the location of Java on
your system, the configuration process fails; if you do not
wish to enable Java and ClusterJ support, you must indicate
this explicitly by configuring the build using
-DWITH_NDB_JAVA=OFF. (Bug #12379735) Use
WITH_CLASSPATH to provide the
Java classpath if needed.
For more information about CMake options specific to building NDB Cluster, see Options for Compiling NDB Cluster.
After you have run make && make install (or your system's equivalent), the result is similar to what is obtained by unpacking a precompiled binary to the same location.
Management nodes.
When building from source and running the default
make install, the management server and
management client binaries (ndb_mgmd and
ndb_mgm) can be found in
/usr/local/mysql/bin. Only
ndb_mgmd is required to be present on a
management node host; however, it is also a good idea to have
ndb_mgm present on the same host machine.
Neither of these executables requires a specific location on
the host machine's file system.
Data nodes.
The only executable required on a data node host is the data
node binary ndbd or
ndbmtd. (mysqld, for
example, does not have to be present on the host machine.) By
default, when building from source, this file is placed in the
directory /usr/local/mysql/bin. For
installing on multiple data node hosts, only
ndbd or ndbmtd need be
copied to the other host machine or machines. (This assumes
that all data node hosts use the same architecture and
operating system; otherwise you may need to compile separately
for each different platform.) The data node binary need not be
in any particular location on the host's file system, as long
as the location is known.
When compiling NDB Cluster from source, no special options are
required for building multi-threaded data node binaries.
Configuring the build with NDB
storage engine support causes ndbmtd to be
built automatically; make install places the
ndbmtd binary in the installation
bin directory along with
mysqld, ndbd, and
ndb_mgm.
SQL nodes.
If you compile MySQL with clustering support, and perform the
default installation (using make install as
the system root user),
mysqld is placed in
/usr/local/mysql/bin. Follow the steps
given in Installing MySQL from Source to make
mysqld ready for use. If you want to run
multiple SQL nodes, you can use a copy of the same
mysqld executable and its associated
support files on several machines. The easiest way to do this
is to copy the entire /usr/local/mysql
directory and all directories and files contained within it to
the other SQL node host or hosts, then repeat the steps from
Installing MySQL from Source on each machine. If you
configure the build with a nondefault PREFIX
option, you must adjust the directory accordingly.
In Section 4.3, “Initial Configuration of NDB Cluster”, we create configuration files for all of the nodes in our example NDB Cluster.
NDB Cluster 7.2 binaries for Windows can be obtained from http://dev.mysql.com/downloads/cluster/. For information about installing NDB Cluster on Windows from a binary release provided by Oracle, see Section 4.2.1, “Installing NDB Cluster on Windows from a Binary Release”.
It is also possible to compile and install NDB Cluster from source on Windows using Microsoft Visual Studio. For more information, see Section 4.2.2, “Compiling and Installing NDB Cluster from Source on Windows”.
This section describes a basic installation of NDB Cluster on
Windows using a binary no-install NDB Cluster
release provided by Oracle, using the same 4-node setup outlined
in the beginning of this section (see
Chapter 4, NDB Cluster Installation and Upgrades), as shown in the
following table:
| Node | IP Address |
|---|---|
| Management (MGMD) node | 192.168.0.10 |
| MySQL server (SQL) node | 192.168.0.20 |
| Data (NDBD) node "A" | 192.168.0.30 |
| Data (NDBD) node "B" | 192.168.0.40 |
As on other platforms, the NDB Cluster host computer running an SQL node must have installed on it a MySQL Server binary (mysqld.exe). You should also have the MySQL client (mysql.exe) on this host. For management nodes and data nodes, it is not necessary to install the MySQL Server binary; however, each management node requires the management server daemon (ndb_mgmd.exe); each data node requires the data node daemon (ndbd.exe or ndbmtd.exe). For this example, we refer to ndbd.exe as the data node executable, but you can install ndbmtd.exe, the multi-threaded version of this program, instead, in exactly the same way. You should also install the management client (ndb_mgm.exe) on the management server host. This section covers the steps necessary to install the correct Windows binaries for each type of NDB Cluster node.
As with other Windows programs, NDB Cluster executables are
named with the .exe file extension.
However, it is not necessary to include the
.exe extension when invoking these
programs from the command line. Therefore, we often simply
refer to these programs in this documentation as
mysqld, mysql,
ndb_mgmd, and so on. You should understand
that, whether we refer (for example) to
mysqld or mysqld.exe,
either name means the same thing (the MySQL Server program).
For setting up an NDB Cluster using Oracles's
no-install binaries, the first step in the
installation process is to download the latest NDB Cluster
Windows binary archive from
http://dev.mysql.com/downloads/cluster/. This archive has a
filename of the form
mysql-cluster-gpl-noinstall-,
where ver-winarch.zipver is the
NDB storage engine version (such as
7.2.1), and arch
is the architecture (32 for 32-bit binaries,
and 64 for 64-bit binaries). For example, the
NDB 7.2.1 no-install archive for 32-bit
Windows systems is named
mysql-cluster-gpl-noinstall-7.2.1-win32.zip.
You can run 32-bit NDB Cluster binaries on both 32-bit and 64-bit versions of Windows; however, 64-bit NDB Cluster binaries can be used only on 64-bit versions of Windows. If you are using a 32-bit version of Windows on a computer that has a 64-bit CPU, then you must use the 32-bit NDB Cluster binaries.
To minimize the number of files that need to be downloaded from the Internet or copied between machines, we start with the computer where you intend to run the SQL node.
SQL node.
We assume that you have placed a copy of the
no-install archive in the directory
C:\Documents and
Settings\ on the computer having the IP
address 192.168.0.20, where
username\My
Documents\Downloadsusername is the name of the current
user. (You can obtain this name using ECHO
%USERNAME% on the command line.) To install and run
NDB Cluster executables as Windows services, this user should
be a member of the Administrators group.
Extract all the files from the archive. The Extraction Wizard
integrated with Windows Explorer is adequate for this task. (If
you use a different archive program, be sure that it extracts
all files and directories from the archive, and that it
preserves the archive's directory structure.) When you are
asked for a destination directory, enter
C:\, which causes the Extraction Wizard to
extract the archive to the directory
C:\mysql-cluster-gpl-noinstall-.
Rename this directory to ver-winarchC:\mysql.
It is possible to install the NDB Cluster binaries to
directories other than C:\mysql\bin;
however, if you do so, you must modify the paths shown in this
procedure accordingly. In particular, if the MySQL Server (SQL
node) binary is installed to a location other than
C:\mysql or C:\Program
Files\MySQL\MySQL Server 5.5, or if the
SQL node's data directory is in a location other than
C:\mysql\data or C:\Program
Files\MySQL\MySQL Server 5.5\data, extra
configuration options must be used on the command line or added
to the my.ini or
my.cnf file when starting the SQL node. For
more information about configuring a MySQL Server to run in a
nonstandard location, see
Installing MySQL on Microsoft Windows Using a noinstall Zip Archive.
For a MySQL Server with NDB Cluster support to run as part of an
NDB Cluster, it must be started with the options
--ndbcluster and
--ndb-connectstring. While you
can specify these options on the command line, it is usually
more convenient to place them in an option file. To do this,
create a new text file in Notepad or another text editor. Enter
the following configuration information into this file:
[mysqld] # Options for mysqld process: ndbcluster # run NDB storage engine ndb-connectstring=192.168.0.10 # location of management server
You can add other options used by this MySQL Server if desired
(see Creating an Option File), but the file
must contain the options shown, at a minimum. Save this file as
C:\mysql\my.ini. This completes the
installation and setup for the SQL node.
Data nodes.
An NDB Cluster data node on a Windows host requires only a
single executable, one of either ndbd.exe
or ndbmtd.exe. For this example, we assume
that you are using ndbd.exe, but the same
instructions apply when using ndbmtd.exe.
On each computer where you wish to run a data node (the
computers having the IP addresses 192.168.0.30 and
192.168.0.40), create the directories
C:\mysql,
C:\mysql\bin, and
C:\mysql\cluster-data; then, on the
computer where you downloaded and extracted the
no-install archive, locate
ndbd.exe in the
C:\mysql\bin directory. Copy this file to
the C:\mysql\bin directory on each of the
two data node hosts.
To function as part of an NDB Cluster, each data node must be
given the address or hostname of the management server. You can
supply this information on the command line using the
--ndb-connectstring or
-c option when starting each data node process.
However, it is usually preferable to put this information in an
option file. To do this, create a new text file in Notepad or
another text editor and enter the following text:
[mysql_cluster] # Options for data node process: ndb-connectstring=192.168.0.10 # location of management server
Save this file as C:\mysql\my.ini on the
data node host. Create another text file containing the same
information and save it on as
C:mysql\my.ini on the other data node host,
or copy the my.ini file from the first data node host to the
second one, making sure to place the copy in the second data
node's C:\mysql directory. Both data
node hosts are now ready to be used in the NDB Cluster, which
leaves only the management node to be installed and configured.
Management node.
The only executable program required on a computer used for
hosting an NDB Cluster management node is the management
server program ndb_mgmd.exe. However, in
order to administer the NDB Cluster once it has been started,
you should also install the NDB Cluster management client
program ndb_mgm.exe on the same machine as
the management server. Locate these two programs on the
machine where you downloaded and extracted the
no-install archive; this should be the
directory C:\mysql\bin on the SQL node
host. Create the directory C:\mysql\bin
on the computer having the IP address 192.168.0.10, then copy
both programs to this directory.
You should now create two configuration files for use by
ndb_mgmd.exe:
A local configuration file to supply configuration data specific to the management node itself. Typically, this file needs only to supply the location of the NDB Cluster global configuration file (see item 2).
To create this file, start a new text file in Notepad or another text editor, and enter the following information:
[mysql_cluster] # Options for management node process config-file=C:/mysql/bin/config.ini
Save this file as the text file
C:\mysql\bin\my.ini.
A global configuration file from which the management node
can obtain configuration information governing the NDB
Cluster as a whole. At a minimum, this file must contain a
section for each node in the NDB Cluster, and the IP
addresses or hostnames for the management node and all data
nodes (HostName configuration parameter).
It is also advisable to include the following additional
information:
The IP address or hostname of any SQL nodes
The data memory and index memory allocated to each data
node (DataMemory
and IndexMemory
configuration parameters)
The number of replicas, using the
NoOfReplicas
configuration parameter (see
Section 3.2, “NDB Cluster Nodes, Node Groups, Replicas, and Partitions”)
The directory where each data node stores it data and
log file, and the directory where the management node
keeps its log files (in both cases, the
DataDir
configuration parameter)
Create a new text file using a text editor such as Notepad, and input the following information:
[ndbd default]
# Options affecting ndbd processes on all data nodes:
NoOfReplicas=2 # Number of replicas
DataDir=C:/mysql/cluster-data # Directory for each data node's data files
# Forward slashes used in directory path,
# rather than backslashes. This is correct;
# see Important note in text
DataMemory=80M # Memory allocated to data storage
IndexMemory=18M # Memory allocated to index storage
# For DataMemory and IndexMemory, we have used the
# default values. Since the "world" database takes up
# only about 500KB, this should be more than enough for
# this example Cluster setup.
[ndb_mgmd]
# Management process options:
HostName=192.168.0.10 # Hostname or IP address of management node
DataDir=C:/mysql/bin/cluster-logs # Directory for management node log files
[ndbd]
# Options for data node "A":
# (one [ndbd] section per data node)
HostName=192.168.0.30 # Hostname or IP address
[ndbd]
# Options for data node "B":
HostName=192.168.0.40 # Hostname or IP address
[mysqld]
# SQL node options:
HostName=192.168.0.20 # Hostname or IP address
Save this file as the text file
C:\mysql\bin\config.ini.
A single backslash character (\) cannot be
used when specifying directory paths in program options or
configuration files used by NDB Cluster on Windows. Instead,
you must either escape each backslash character with a second
backslash (\\), or replace the backslash
with a forward slash character (/). For
example, the following line from the
[ndb_mgmd] section of an NDB Cluster
config.ini file does not work:
DataDir=C:\mysql\bin\cluster-logs
Instead, you may use either of the following:
DataDir=C:\\mysql\\bin\\cluster-logs # Escaped backslashes
DataDir=C:/mysql/bin/cluster-logs # Forward slashes
For reasons of brevity and legibility, we recommend that you use forward slashes in directory paths used in NDB Cluster program options and configuration files on Windows.
Oracle provides precompiled NDB Cluster binaries for Windows which should be adequate for most users. However, if you wish, it is also possible to compile NDB Cluster for Windows from source code. The procedure for doing this is almost identical to the procedure used to compile the standard MySQL Server binaries for Windows, and uses the same tools. However, there are two major differences:
To build NDB Cluster, you must use the NDB Cluster sources, which you can obtain from http://dev.mysql.com/downloads/cluster/.
Attempting to build NDB Cluster from the source code for the standard MySQL Server is likely not to be successful, and is not supported by Oracle.
You must configure the build using the
WITH_NDBCLUSTER_STORAGE_ENGINE
or WITH_NDBCLUSTER option in
addition to any other build options you wish to use with
CMake. (WITH_NDBCLUSTER
is supported as an alias for
WITH_NDBCLUSTER_STORAGE_ENGINE, and works
in exactly the same way.)
Beginning with NDB 7.2.9, the
WITH_NDB_JAVA option is enabled
by default. This means that, by default, if
CMake cannot find the location of Java on
your system, the configuration process fails; if you do not
wish to enable Java and ClusterJ support, you must indicate
this explicitly by configuring the build using
-DWITH_NDB_JAVA=OFF. (Bug #12379735) Use
WITH_CLASSPATH to provide the
Java classpath if needed.
For more information about CMake options specific to building NDB Cluster, see Options for Compiling NDB Cluster.
Once the build process is complete, you can create a Zip archive
containing the compiled binaries;
Installing MySQL Using a Standard Source Distribution provides the
commands needed to perform this task on Windows systems. The NDB
Cluster binaries can be found in the bin
directory of the resulting archive, which is equivalent to the
no-install archive, and which can be
installed and configured in the same manner. For more
information, see
Section 4.2.1, “Installing NDB Cluster on Windows from a Binary Release”.
Once the NDB Cluster executables and needed configuration files are in place, performing an initial start of the cluster is simply a matter of starting the NDB Cluster executables for all nodes in the cluster. Each cluster node process must be started separately, and on the host computer where it resides. The management node should be started first, followed by the data nodes, and then finally by any SQL nodes.
On the management node host, issue the following command from the command line to start the management node process:
C:\mysql\bin> ndb_mgmd
2010-06-23 07:53:34 [MgmtSrvr] INFO -- NDB Cluster Management Server. mysql-5.5.53-ndb-7.2.27
2010-06-23 07:53:34 [MgmtSrvr] INFO -- Reading cluster configuration from 'config.ini'
The management node process continues to print logging output to the console. This is normal, because the management node is not running as a Windows service. (If you have used NDB Cluster on a Unix-like platform such as Linux, you may notice that the management node's default behavior in this regard on Windows is effectively the opposite of its behavior on Unix systems, where it runs by default as a Unix daemon process. This behavior is also true of NDB Cluster data node processes running on Windows.) For this reason, do not close the window in which ndb_mgmd.exe is running; doing so kills the management node process. (See Section 4.2.4, “Installing NDB Cluster Processes as Windows Services”, where we show how to install and run NDB Cluster processes as Windows services.)
The required -f option tells the management
node where to find the global configuration file
(config.ini). The long form of this
option is --config-file.
An NDB Cluster management node caches the configuration
data that it reads from config.ini;
once it has created a configuration cache, it ignores the
config.ini file on subsequent starts
unless forced to do otherwise. This means that, if the
management node fails to start due to an error in this
file, you must make the management node re-read
config.ini after you have corrected
any errors in it. You can do this by starting
ndb_mgmd.exe with the
--reload or
--initial option on the
command line. Either of these options works to refresh the
configuration cache.
It is not necessary or advisable to use either of these
options in the management node's
my.ini file.
For additional information about options which can be used with ndb_mgmd, see Section 6.4, “ndb_mgmd — The NDB Cluster Management Server Daemon”, as well as Section 6.26, “Options Common to NDB Cluster Programs — Options Common to NDB Cluster Programs”.
On each of the data node hosts, run the command shown here to start the data node processes:
C:\mysql\bin> ndbd
2010-06-23 07:53:46 [ndbd] INFO -- Configuration fetched from 'localhost:1186', generation: 1
In each case, the first line of output from the data node process should resemble what is shown in the preceding example, and is followed by additional lines of logging output. As with the management node process, this is normal, because the data node is not running as a Windows service. For this reason, do not close the console window in which the data node process is running; doing so kills ndbd.exe. (For more information, see Section 4.2.4, “Installing NDB Cluster Processes as Windows Services”.)
Do not start the SQL node yet; it cannot connect to the
cluster until the data nodes have finished starting, which
may take some time. Instead, in a new console window on the
management node host, start the NDB Cluster management
client ndb_mgm.exe, which should be in
C:\mysql\bin on the management node
host. (Do not try to re-use the console window where
ndb_mgmd.exe is running by typing
CTRL+C, as this kills the
management node.) The resulting output should look like
this:
C:\mysql\bin> ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm>
When the prompt ndb_mgm> appears, this
indicates that the management client is ready to receive NDB
Cluster management commands. You can observe the status of
the data nodes as they start by entering
ALL STATUS at the
management client prompt. This command causes a running
report of the data nodes's startup sequence, which
should look something like this:
ndb_mgm> ALL STATUS
Connected to Management Server at: localhost:1186
Node 2: starting (Last completed phase 3) (mysql-5.5.53-ndb-7.2.27)
Node 3: starting (Last completed phase 3) (mysql-5.5.53-ndb-7.2.27)
Node 2: starting (Last completed phase 4) (mysql-5.5.53-ndb-7.2.27)
Node 3: starting (Last completed phase 4) (mysql-5.5.53-ndb-7.2.27)
Node 2: Started (version 7.2.27)
Node 3: Started (version 7.2.27)
ndb_mgm>
Commands issued in the management client are not case-sensitive; we use uppercase as the canonical form of these commands, but you are not required to observe this convention when inputting them into the ndb_mgm client. For more information, see Section 7.2, “Commands in the NDB Cluster Management Client”.
The output produced by ALL
STATUS is likely to vary from what is shown here,
according to the speed at which the data nodes are able to
start, the release version number of the NDB Cluster
software you are using, and other factors. What is
significant is that, when you see that both data nodes have
started, you are ready to start the SQL node.
You can leave ndb_mgm.exe running; it has no negative impact on the performance of the NDB Cluster, and we use it in the next step to verify that the SQL node is connected to the cluster after you have started it.
On the computer designated as the SQL node host, open a
console window and navigate to the directory where you
unpacked the NDB Cluster binaries (if you are following our
example, this is C:\mysql\bin).
Start the SQL node by invoking mysqld.exe from the command line, as shown here:
C:\mysql\bin> mysqld --console
The --console option causes
logging information to be written to the console, which can
be helpful in the event of problems. (Once you are satisfied
that the SQL node is running in a satisfactory manner, you
can stop it and restart it out without the
--console option, so that
logging is performed normally.)
In the console window where the management client
(ndb_mgm.exe) is running on the
management node host, enter the
SHOW command, which
should produce output similar to what is shown here:
ndb_mgm> SHOW
Connected to Management Server at: localhost:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=2 @192.168.0.30 (Version: 5.5.53-ndb-7.2.27, Nodegroup: 0, *)
id=3 @192.168.0.40 (Version: 5.5.53-ndb-7.2.27, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.10 (Version: 5.5.53-ndb-7.2.27)
[mysqld(API)] 1 node(s)
id=4 @192.168.0.20 (Version: 5.5.53-ndb-7.2.27)
You can also verify that the SQL node is connected to the
NDB Cluster in the mysql client
(mysql.exe) using the
SHOW ENGINE NDB STATUS
statement.
You should now be ready to work with database objects and data
using NDB Cluster's NDBCLUSTER
storage engine. See
Section 4.5, “NDB Cluster Example with Tables and Data”, for more
information and examples.
You can also install ndb_mgmd.exe, ndbd.exe, and ndbmtd.exe as Windows services. For information on how to do this, see Section 4.2.4, “Installing NDB Cluster Processes as Windows Services”).
Once you are satisfied that NDB Cluster is running as desired, you can install the management nodes and data nodes as Windows services, so that these processes are started and stopped automatically whenever Windows is started or stopped. This also makes it possible to control these processes from the command line with the appropriate NET START or NET STOP command, or using the Windows graphical Services utility.
Installing programs as Windows services usually must be done using an account that has Administrator rights on the system.
To install the management node as a service on Windows, invoke
ndb_mgmd.exe from the command line on the
machine hosting the management node, using the
--install option, as shown
here:
C:\> C:\mysql\bin\ndb_mgmd.exe --install
Installing service 'NDB Cluster Management Server'
as '"C:\mysql\bin\ndbd.exe" "--service=ndb_mgmd"'
Service successfully installed.
When installing an NDB Cluster program as a Windows service, you should always specify the complete path; otherwise the service installation may fail with the error The system cannot find the file specified.
The --install option must be
used first, ahead of any other options that might be specified
for ndb_mgmd.exe. However, it is preferable
to specify such options in an options file instead. If your
options file is not in one of the default locations as shown in
the output of ndb_mgmd.exe
--help, you can specify the
location using the
--config-file option.
Now you should be able to start and stop the management server like this:
C:\>NET START ndb_mgmdThe NDB Cluster Management Server service is starting. The NDB Cluster Management Server service was started successfully. C:\>NET STOP ndb_mgmdThe NDB Cluster Management Server service is stopping.. The NDB Cluster Management Server service was stopped successfully.
You can also start or stop the management server as a Windows service using the descriptive name, as shown here:
C:\>NET START 'NDB Cluster Management Server'The NDB Cluster Management Server service is starting. The NDB Cluster Management Server service was started successfully. C:\>NET STOP 'NDB Cluster Management Server'The NDB Cluster Management Server service is stopping.. The NDB Cluster Management Server service was stopped successfully.
However, it is usually simpler to specify a short service name
or to permit the default service name to be used when installing
the service, and then reference that name when starting or
stopping the service. To specify a service name other than
ndb_mgmd, append it to the
--install option, as shown in
this example:
C:\> C:\mysql\bin\ndb_mgmd.exe --install=mgmd1
Installing service 'NDB Cluster Management Server'
as '"C:\mysql\bin\ndb_mgmd.exe" "--service=mgmd1"'
Service successfully installed.
Now you should be able to start or stop the service using the name you have specified, like this:
C:\>NET START mgmd1The NDB Cluster Management Server service is starting. The NDB Cluster Management Server service was started successfully. C:\>NET STOP mgmd1The NDB Cluster Management Server service is stopping.. The NDB Cluster Management Server service was stopped successfully.
To remove the management node service, invoke
ndb_mgmd.exe with the
--remove option, as shown here:
C:\> C:\mysql\bin\ndb_mgmd.exe --remove
Removing service 'NDB Cluster Management Server'
Service successfully removed.
If you installed the service using a service name other than the
default, you can remove the service by passing this name as the
value of the --remove option,
like this:
C:\> C:\mysql\bin\ndb_mgmd.exe --remove=mgmd1
Removing service 'mgmd1'
Service successfully removed.
Installation of an NDB Cluster data node process as a Windows
service can be done in a similar fashion, using the
--install option for
ndbd.exe (or ndbmtd.exe),
as shown here:
C:\> C:\mysql\bin\ndbd.exe --install
Installing service 'NDB Cluster Data Node Daemon' as '"C:\mysql\bin\ndbd.exe" "--service=ndbd"'
Service successfully installed.
Now you can start or stop the data node using either the default service name or the descriptive name with net start or net stop, as shown in the following example:
C:\>NET START ndbdThe NDB Cluster Data Node Daemon service is starting. The NDB Cluster Data Node Daemon service was started successfully. C:\>NET STOP ndbdThe NDB Cluster Data Node Daemon service is stopping.. The NDB Cluster Data Node Daemon service was stopped successfully. C:\>NET START 'NDB Cluster Data Node Daemon'The NDB Cluster Data Node Daemon service is starting. The NDB Cluster Data Node Daemon service was started successfully. C:\>NET STOP 'NDB Cluster Data Node Daemon'The NDB Cluster Data Node Daemon service is stopping.. The NDB Cluster Data Node Daemon service was stopped successfully.
To remove the data node service, invoke
ndbd.exe with the
--remove option, as shown here:
C:\> C:\mysql\bin\ndbd.exe --remove
Removing service 'NDB Cluster Data Node Daemon'
Service successfully removed.
As with ndb_mgmd.exe (and
mysqld.exe), when installing
ndbd.exe as a Windows service, you can also
specify a name for the service as the value of
--install, and then use it when
starting or stopping the service, like this:
C:\>C:\mysql\bin\ndbd.exe --install=dnode1Installing service 'dnode1' as '"C:\mysql\bin\ndbd.exe" "--service=dnode1"' Service successfully installed. C:\>NET START dnode1The NDB Cluster Data Node Daemon service is starting. The NDB Cluster Data Node Daemon service was started successfully. C:\>NET STOP dnode1The NDB Cluster Data Node Daemon service is stopping.. The NDB Cluster Data Node Daemon service was stopped successfully.
If you specified a service name when installing the data node
service, you can use this name when removing it as well, by
passing it as the value of the
--remove option, as shown here:
C:\> C:\mysql\bin\ndbd.exe --remove=dnode1
Removing service 'dnode1'
Service successfully removed.
Installation of the SQL node as a Windows service, starting the
service, stopping the service, and removing the service are done
in a similar fashion, using mysqld
--install, NET START,
NET STOP, and mysqld
--remove. For additional
information, see Starting MySQL as a Windows Service.
For our four-node, four-host NDB Cluster, it is necessary to write four configuration files, one per node host.
Each data node or SQL node requires a
my.cnf file that provides two pieces of
information: a connection
string that tells the node where to find the
management node, and a line telling the MySQL server on this
host (the machine hosting the data node) to enable the
NDBCLUSTER storage engine.
For more information on connection strings, see Section 5.3.3, “NDB Cluster Connection Strings”.
The management node needs a config.ini
file telling it how many replicas to maintain, how much memory
to allocate for data and indexes on each data node, where to
find the data nodes, where to save data to disk on each data
node, and where to find any SQL nodes.
Configuring the data nodes and SQL nodes.
The my.cnf file needed for the data nodes
is fairly simple. The configuration file should be located in
the /etc directory and can be edited using
any text editor. (Create the file if it does not exist.) For
example:
shell> vi /etc/my.cnf
We show vi being used here to create the file, but any text editor should work just as well.
For each data node and SQL node in our example setup,
my.cnf should look like this:
[mysqld] # Options for mysqld process: ndbcluster # run NDB storage engine [mysql_cluster] # Options for NDB Cluster processes: ndb-connectstring=192.168.0.10 # location of management server
After entering the preceding information, save this file and exit the text editor. Do this for the machines hosting data node “A”, data node “B”, and the SQL node.
Once you have started a mysqld process with
the ndbcluster and
ndb-connectstring parameters in the
[mysqld] and
[mysql_cluster] sections of the
my.cnf file as shown previously, you cannot
execute any CREATE TABLE or
ALTER TABLE statements without
having actually started the cluster. Otherwise, these statements
will fail with an error. This is by design.
Configuring the management node.
The first step in configuring the management node is to create
the directory in which the configuration file can be found and
then to create the file itself. For example (running as
root):
shell>mkdir /var/lib/mysql-clustershell>cd /var/lib/mysql-clustershell>vi config.ini
For our representative setup, the config.ini
file should read as follows:
[ndbd default]
# Options affecting ndbd processes on all data nodes:
NoOfReplicas=2 # Number of replicas
DataMemory=80M # How much memory to allocate for data storage
IndexMemory=18M # How much memory to allocate for index storage
# For DataMemory and IndexMemory, we have used the
# default values. Since the "world" database takes up
# only about 500KB, this should be more than enough for
# this example Cluster setup.
[tcp default]
# TCP/IP options:
portnumber=2202 # This the default; however, you can use any
# port that is free for all the hosts in the cluster
# Note: It is recommended that you do not specify the port
# number at all and simply allow the default value to be used
# instead
[ndb_mgmd]
# Management process options:
hostname=192.168.0.10 # Hostname or IP address of MGM node
datadir=/var/lib/mysql-cluster # Directory for MGM node log files
[ndbd]
# Options for data node "A":
# (one [ndbd] section per data node)
hostname=192.168.0.30 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's data files
[ndbd]
# Options for data node "B":
hostname=192.168.0.40 # Hostname or IP address
datadir=/usr/local/mysql/data # Directory for this data node's data files
[mysqld]
# SQL node options:
hostname=192.168.0.20 # Hostname or IP address
# (additional mysqld connections can be
# specified for this node for various
# purposes such as running ndb_restore)
The world database can be downloaded from
http://dev.mysql.com/doc/index-other.html.
After all the configuration files have been created and these minimal options have been specified, you are ready to proceed with starting the cluster and verifying that all processes are running. We discuss how this is done in Section 4.4, “Initial Startup of NDB Cluster”.
For more detailed information about the available NDB Cluster configuration parameters and their uses, see Section 5.3, “NDB Cluster Configuration Files”, and Chapter 5, Configuration of NDB Cluster. For configuration of NDB Cluster as relates to making backups, see Section 7.3.3, “Configuration for NDB Cluster Backups”.
The default port for Cluster management nodes is 1186; the default port for data nodes is 2202. However, the cluster can automatically allocate ports for data nodes from those that are already free.
Starting the cluster is not very difficult after it has been configured. Each cluster node process must be started separately, and on the host where it resides. The management node should be started first, followed by the data nodes, and then finally by any SQL nodes:
On the management host, issue the following command from the system shell to start the management node process:
shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
The first time that it is started, ndb_mgmd
must be told where to find its configuration file, using the
-f or
--config-file option. (See
Section 6.4, “ndb_mgmd — The NDB Cluster Management Server Daemon”, for
details.)
For additional options which can be used with ndb_mgmd, see Section 6.26, “Options Common to NDB Cluster Programs — Options Common to NDB Cluster Programs”.
On each of the data node hosts, run this command to start the ndbd process:
shell> ndbd
If you used RPM files to install MySQL on the cluster host where the SQL node is to reside, you can (and should) use the supplied startup script to start the MySQL server process on the SQL node.
If all has gone well, and the cluster has been set up correctly, the cluster should now be operational. You can test this by invoking the ndb_mgm management node client. The output should look like that shown here, although you might see some slight differences in the output depending upon the exact version of MySQL that you are using:
shell>ndb_mgm-- NDB Cluster -- Management Client -- ndb_mgm>SHOWConnected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 @192.168.0.30 (Version: 5.5.53-ndb-7.2.27, Nodegroup: 0, *) id=3 @192.168.0.40 (Version: 5.5.53-ndb-7.2.27, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.10 (Version: 5.5.53-ndb-7.2.27) [mysqld(API)] 1 node(s) id=4 @192.168.0.20 (Version: 5.5.53-ndb-7.2.27)
The SQL node is referenced here as
[mysqld(API)], which reflects the fact that the
mysqld process is acting as an NDB Cluster API
node.
The IP address shown for a given NDB Cluster SQL or other API
node in the output of SHOW
is the address used by the SQL or API node to connect to the
cluster data nodes, and not to any management node.
You should now be ready to work with databases, tables, and data in NDB Cluster. See Section 4.5, “NDB Cluster Example with Tables and Data”, for a brief discussion.
The information in this section applies to NDB Cluster running on both Unix and Windows platforms.
Working with database tables and data in NDB Cluster is not much different from doing so in standard MySQL. There are two key points to keep in mind:
For a table to be replicated in the cluster, it must use the
NDBCLUSTER storage engine. To
specify this, use the ENGINE=NDBCLUSTER or
ENGINE=NDB option when creating the table:
CREATE TABLEtbl_name(col_namecolumn_definitions) ENGINE=NDBCLUSTER;
Alternatively, for an existing table that uses a different
storage engine, use ALTER TABLE
to change the table to use
NDBCLUSTER:
ALTER TABLE tbl_name ENGINE=NDBCLUSTER;
Every NDBCLUSTER table has a
primary key. If no primary key is defined by the user when a
table is created, the NDBCLUSTER
storage engine automatically generates a hidden one. Such a
key takes up space just as does any other table index. (It is
not uncommon to encounter problems due to insufficient memory
for accommodating these automatically created indexes.)
If you are importing tables from an existing database using the
output of mysqldump, you can open the SQL
script in a text editor and add the ENGINE
option to any table creation statements, or replace any existing
ENGINE options. Suppose that you have the
world sample database on another MySQL server
that does not support NDB Cluster, and you want to export the
City table:
shell> mysqldump --add-drop-table world City > city_table.sql
The resulting city_table.sql file will
contain this table creation statement (and the
INSERT statements necessary to
import the table data):
DROP TABLE IF EXISTS `City`;
CREATE TABLE `City` (
`ID` int(11) NOT NULL auto_increment,
`Name` char(35) NOT NULL default '',
`CountryCode` char(3) NOT NULL default '',
`District` char(20) NOT NULL default '',
`Population` int(11) NOT NULL default '0',
PRIMARY KEY (`ID`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
INSERT INTO `City` VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO `City` VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO `City` VALUES (3,'Herat','AFG','Herat',186800);
(remaining INSERT statements omitted)
You need to make sure that MySQL uses the
NDBCLUSTER storage engine for this
table. There are two ways that this can be accomplished. One of
these is to modify the table definition
before importing it into the Cluster
database. Using the City table as an example,
modify the ENGINE option of the definition as
follows:
DROP TABLE IF EXISTS `City`;
CREATE TABLE `City` (
`ID` int(11) NOT NULL auto_increment,
`Name` char(35) NOT NULL default '',
`CountryCode` char(3) NOT NULL default '',
`District` char(20) NOT NULL default '',
`Population` int(11) NOT NULL default '0',
PRIMARY KEY (`ID`)
) ENGINE=NDBCLUSTER DEFAULT CHARSET=latin1;
INSERT INTO `City` VALUES (1,'Kabul','AFG','Kabol',1780000);
INSERT INTO `City` VALUES (2,'Qandahar','AFG','Qandahar',237500);
INSERT INTO `City` VALUES (3,'Herat','AFG','Herat',186800);
(remaining INSERT statements omitted)
This must be done for the definition of each table that is to be
part of the clustered database. The easiest way to accomplish this
is to do a search-and-replace on the file that contains the
definitions and replace all instances of
TYPE= or
engine_nameENGINE=
with engine_nameENGINE=NDBCLUSTER. If you do not want to
modify the file, you can use the unmodified file to create the
tables, and then use ALTER TABLE to
change their storage engine. The particulars are given later in
this section.
Assuming that you have already created a database named
world on the SQL node of the cluster, you can
then use the mysql command-line client to read
city_table.sql, and create and populate the
corresponding table in the usual manner:
shell> mysql world < city_table.sql
It is very important to keep in mind that the preceding command
must be executed on the host where the SQL node is running (in
this case, on the machine with the IP address
192.168.0.20).
To create a copy of the entire world database
on the SQL node, use mysqldump on the
noncluster server to export the database to a file named
world.sql; for example, in the
/tmp directory. Then modify the table
definitions as just described and import the file into the SQL
node of the cluster like this:
shell> mysql world < /tmp/world.sql
If you save the file to a different location, adjust the preceding instructions accordingly.
Running SELECT queries on the SQL
node is no different from running them on any other instance of a
MySQL server. To run queries from the command line, you first need
to log in to the MySQL Monitor in the usual way (specify the
root password at the Enter
password: prompt):
shell> mysql -u root -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 1 to server version: 5.5.53-ndb-7.2.27
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
mysql>
We simply use the MySQL server's root
account and assume that you have followed the standard security
precautions for installing a MySQL server, including setting a
strong root password. For more information, see
Securing the Initial MySQL Accounts.
It is worth taking into account that Cluster nodes do
not make use of the MySQL privilege system
when accessing one another. Setting or changing MySQL user
accounts (including the root account) effects
only applications that access the SQL node, not interaction
between nodes. See
Section 7.11.2, “NDB Cluster and MySQL Privileges”, for
more information.
If you did not modify the ENGINE clauses in the
table definitions prior to importing the SQL script, you should
run the following statements at this point:
mysql>USE world;mysql>ALTER TABLE city ENGINE=NDBCLUSTER;mysql>ALTER TABLE country ENGINE=NDBCLUSTER;mysql>ALTER TABLE countrylanguage ENGINE=NDBCLUSTER;
Selecting a database and running a SELECT query against a table in that database is also accomplished in the usual manner, as is exiting the MySQL Monitor:
mysql>USE world;mysql>SELECT Name, Population FROM city ORDER BY Population DESC LIMIT 5;+-----------+------------+ | Name | Population | +-----------+------------+ | Bombay | 10500000 | | Seoul | 9981619 | | São Paulo | 9968485 | | Shanghai | 9696300 | | Jakarta | 9604900 | +-----------+------------+ 5 rows in set (0.34 sec) mysql>\qBye shell>
Applications that use MySQL can employ standard APIs to access
NDB tables. It is important to
remember that your application must access the SQL node, and not
the management or data nodes. This brief example shows how we
might execute the SELECT statement
just shown by using the PHP 5.X mysqli
extension running on a Web server elsewhere on the network:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php
# connect to SQL node:
$link = new mysqli('192.168.0.20', 'root', 'root_password', 'world');
# parameters for mysqli constructor are:
# host, user, password, database
if( mysqli_connect_errno() )
die("Connect failed: " . mysqli_connect_error());
$query = "SELECT Name, Population
FROM City
ORDER BY Population DESC
LIMIT 5";
# if no errors...
if( $result = $link->query($query) )
{
?>
<table border="1" width="40%" cellpadding="4" cellspacing ="1">
<tbody>
<tr>
<th width="10%">City</th>
<th>Population</th>
</tr>
<?
# then display the results...
while($row = $result->fetch_object())
printf("<tr>\n <td align=\"center\">%s</td><td>%d</td>\n</tr>\n",
$row->Name, $row->Population);
?>
</tbody
</table>
<?
# ...and verify the number of rows that were retrieved
printf("<p>Affected rows: %d</p>\n", $link->affected_rows);
}
else
# otherwise, tell us what went wrong
echo mysqli_error();
# free the result set and the mysqli connection object
$result->close();
$link->close();
?>
</body>
</html>
We assume that the process running on the Web server can reach the IP address of the SQL node.
In a similar fashion, you can use the MySQL C API, Perl-DBI, Python-mysql, or MySQL Connectors to perform the tasks of data definition and manipulation just as you would normally with MySQL.
To shut down the cluster, enter the following command in a shell on the machine hosting the management node:
shell> ndb_mgm -e shutdown
The -e option here is used to pass a command to
the ndb_mgm client from the shell. (See
Section 6.26, “Options Common to NDB Cluster Programs — Options Common to NDB Cluster Programs”, for more
information about this option.) The command causes the
ndb_mgm, ndb_mgmd, and any
ndbd or ndbmtd processes to
terminate gracefully. Any SQL nodes can be terminated using
mysqladmin shutdown and other means. On Windows
platforms, assuming that you have installed the SQL node as a
Windows service, you can use NET STOP MYSQL.
To restart the cluster on Unix platforms, run these commands:
On the management host (192.168.0.10 in our
example setup):
shell> ndb_mgmd -f /var/lib/mysql-cluster/config.ini
On each of the data node hosts
(192.168.0.30 and
192.168.0.40):
shell> ndbd
Use the ndb_mgm client to verify that both data nodes have started successfully.
On the SQL host (192.168.0.20):
shell> mysqld_safe &
On Windows platforms, assuming that you have installed all NDB Cluster processes as Windows services using the default service names (see Section 4.2.4, “Installing NDB Cluster Processes as Windows Services”), you can restart the cluster as follows:
On the management host (192.168.0.10 in our
example setup), execute the following command:
C:\> NET START ndb_mgmd
On each of the data node hosts
(192.168.0.30 and
192.168.0.40), execute the following
command:
C:\> NET START ndbd
On the management node host, use the ndb_mgm client to verify that the management node and both data nodes have started successfully (see Section 4.2.3, “Initial Startup of NDB Cluster on Windows”).
On the SQL node host (192.168.0.20),
execute the following command:
C:\> NET START mysql
In a production setting, it is usually not desirable to shut down the cluster completely. In many cases, even when making configuration changes, or performing upgrades to the cluster hardware or software (or both), which require shutting down individual host machines, it is possible to do so without shutting down the cluster as a whole by performing a rolling restart of the cluster. For more information about doing this, see Section 7.5, “Performing a Rolling Restart of an NDB Cluster”.
This section provides information about NDB Cluster software and table file compatibility between different NDB Cluster 7.2 releases with regard to performing upgrades and downgrades as well as compatibility matrices and notes. You are expected already to be familiar with installing and configuring an NDB Cluster prior to attempting an upgrade or downgrade. See Chapter 5, Configuration of NDB Cluster.
For information regarding the rolling restart procedure used to perform an online upgrade, see Section 7.5, “Performing a Rolling Restart of an NDB Cluster”.
Only compatibility between MySQL versions with regard to
NDBCLUSTER is taken into account in
this section, and there are likely other issues to be
considered. As with any other MySQL software upgrade
or downgrade, you are strongly encouraged to review the relevant
portions of the MySQL Manual for the MySQL versions from which
and to which you intend to migrate, before attempting an upgrade
or downgrade of the NDB Cluster software. This is
especially true when planning a migration from NDB Cluster 7.1
(or earlier) to NDB Cluster 7.2, since the version of the
underlying MySQL Server also changes from MySQL 5.1 to MySQL
5.5. See Upgrading MySQL.
The table shown here provides information on NDB Cluster upgrade and downgrade compatibility among different releases of NDB Cluster 7.2. Additional notes about upgrades and downgrades to, from, or within the NDB Cluster 7.2 release series can be found immediately following the table.
Versions supported. The following versions of NDB Cluster are supported for upgrades to NDB Cluster 7.2 (7.2.4 and later):
NDB Cluster 7.1 GA releases (7.1.3 and later)
NDB Cluster 7.0 GA releases (7.0.5 and later)
NDB Cluster 6.3 GA releases (6.3.8 and later) that can be upgraded to NDB Cluster 7.1
For information about upgrades to and downgrades from NDB Cluster 7.3, see Upgrading and Downgrading NDB Cluster. For information about upgrades and downgrades in previous NDB Cluster release series, see the MySQL 5.1 Reference Manual.
NDB API, ClusterJ, and other applications used with recent releases of NDB Cluster 6.3 and later should continue to work with NDB 7.2.4 and later without rewriting or recompiling.
In NDB Cluster 7.2, the default values for a number of node configuration parameters have changed. See Improved default values for data node configuration parameters, for a listing of these.
Other known issues include the following:
In NDB 7.2.7 and later, the size of the hash map is 3840 LDM
threads, an increase from 240 in previous versions. When
upgrading an NDB Cluster from NDB 7.2.6 and earlier to NDB
7.2.9 or later, you can modify existing tables online to take
advantage of the new size: following the upgrade, increase the
number of fragments by (for example) adding new data nodes to
the cluster, and then execute
ALTER
ONLINE TABLE ... REORGANIZE PARTITION on any tables
that were created in the older version. Following this, these
tables can use the larger hash map size. (Bug #14645319)
Due to this change, it was not possible to downgrade online to
NDB 7.2.6 or earlier. This issue was resolved in NDB 7.2.11,
where the size is made configurable using the
DefaultHashMapSize
parameter. (Bug #14800539) See the description of this
parameter for more information.
It is not possible to downgrade online to NDB 7.2.13 or earlier from NDB 7.2.14 or later. Online upgrades from NDB 7.2.13 to later NDB Cluster 7.2 releases are supported.