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.8, “Upgrading and Downgrading NDB Cluster”.
This section covers hardware and software requirements; networking issues; installation of NDB Cluster ; basic configuration issues; starting, stopping, and restarting the cluster; loading of a sample database; and performing queries.
NDB Cluster 7.5 also provides an NDB Cluster Auto-Installer, a web-based graphical installer, as part of the NDB Cluster distribution. The Auto-Installer can be used to perform basic installation and setup of an NDB Cluster on one (for testing) or more host computers. See Section 4.1, “The NDB Cluster Auto-Installer”, for more information.
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.2, “Installation of NDB Cluster on Linux”. For information about installation of NDB Cluster on Windows operating systems, see Section 4.3, “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 describes the web-based graphical configuration installer included as part of the NDB Cluster distribution. Topics discussed include an overview of the installer and its parts, software and other requirements for running the installer, navigating the GUI, and using the installer to set up and start or stop an NDB Cluster on one or more host computers.
This section provides information on supported operating platforms and software, required software, and other prerequisites for running the NDB Cluster Auto-Installer.
Supported platforms. The NDB Cluster Auto-Installer is available with most NDB 7.5.2 and later NDB Cluster distributions for recent versions of Linux, Windows, Solaris, and MacOS X. For more detailed information about platform support for NDB Cluster and the NDB Cluster Auto-Installer, see http://www.mysql.com/support/supportedplatforms/cluster.html.
The NDB Cluster Auto-Installer is not supported with NDB 7.5.0 or 7.5.1 (Bug #79853, Bug #22502247).
Supported Web browsers. The Web-based installer is supported with recent versions of Firefox and Microsoft Internet Explorer. It should also work with recent versions of Opera, Safari, and Chrome, although we have not thoroughly tested for compability with these browsers.
Required software—setup host. The following software must be installed on the host where the Auto-Installer is run:
Python 2.6 or higher. The Auto-Installer requires the Python interpreter and standard libraries. If these are not already installed on the system, you may be able to add them using the system's package manager. Otherwise, they can be downloaded from http://python.org/download/.
Paramiko 1.7.7.1 or higher. This is required to communicate with remote hosts using SSH. You can download it from http://www.lag.net/paramiko/. Paramiko may also be available from your system's package manager.
Pycrypto version 2.6 or higher. This cryptography module is required by Paramiko. If it is not available using your system's package manage, you can download it from https://www.dlitz.net/software/pycrypto/.
All of the software in the preceding list is included in the Windows version of the configuration tool, and does not need to be installed separately.
The Paramiko and Pycrypto libraries are required only if you intend to deploy NDB Cluster nodes on remote hosts, and are not needed if all nodes are on the same host where the installer is run.
Required software—remote hosts. The only software required for remote hosts where you wish to deploy NDB Cluster nodes is the SSH server, which is usually installed by default on Linux and Solaris systems. Several alternatives are available for Windows; for an overview of these, see http://en.wikipedia.org/wiki/Comparison_of_SSH_servers.
An additional requirement when using multiple hosts is that it is possible to authenticate to any of the remote hosts using SSH and the proper keys or user credentials, as discussed in the next few paragraphs:
Authentication and security. Three basic security or authentication mechanisms for remote access are available to the Auto-Installer, which we list and describe here:
SSH. A secure shell connection is used to enable the back end to perform actions on remote hosts. For this reason, an SSH server must be running on the remote host. In addition, the system user running the installer must have access to the remote server, either with a user name and password, or by using public and private keys.
You should never use the system root
account for remote access, as this is extremely insecure.
In addition, mysqld cannot normally be
started by system root. For these and
other reasons, you should provide SSH credentials for a
regular user account on the target system, and not for
system root. For more information about
this issue, see How to Run MySQL as a Normal User.
HTTPS.
Remote communication between the Web browser front end and
the back end is not encrypted by default, which means that
information such as the user's SSH password is
transmitted in clear text that is readable to anyone. For
communication from a remote client to be encrypted, the
back end must have a certificate, and the front end must
communicate with the back end using HTTPS rather than
HTTP. Enabling HTTPS is accomplished most easily through
issuing a self-signed certificate. Once the certificate is
issued, you must make sure that it is used. You can do
this by starting ndb_setup.py from the
command line with the
--use-https and
--cert-file options.
Certificate-based authentication.
The back end ndb_setup.py process can
execute commands on the local host as well as remote
hosts. This means that anyone connecting to the back end
can take charge of how commands are executed. To reject
unwanted connections to the back end, a certificate may be
required for authentication of the client. In this case, a
certificate must be issued by the user, installed in the
browser, and made available to the back end for
authentication purposes. You can enact this requirement
(together with or in place of password or key
authentication) by starting
ndb_setup.py with the
--ca-certs-file
option.
There is no need or requirement for secure authentication when the client browser is running on the same host as the Auto-Installer back end.
See also Section 7.12, “NDB Cluster Security Issues”, which discusses security considerations to take into account when deploying NDB Cluster , as well as Security, for more general MySQL security information.
The NDB Cluster Auto-Installer is made up of two components. The front end is a GUI client implemented as a Web page that loads and runs in a standard Web browser such as Firefox or Microsoft Internet Explorer (see Section 4.1.1, “NDB Cluster Auto-Installer Requirements”). The back end is a server process (ndb_setup.py) that runs on the local machine or on another host to which you have access.
These two components (client and server) communicate with each other using standard HTTP requests and responses. The back end can manage NDB Cluster software programs on any host where the back end user has granted access. If the NDB Cluster software is on a different host, the back end relies on SSH for access, using the Paramiko library for executing commands remotely (see Section 4.1.1, “NDB Cluster Auto-Installer Requirements”).
The remainder of this section is concerned primarily with the Web client. For more information about using the command-line tool, see Section 6.23, “ndb_setup.py — Start browser-based Auto-Installer for NDB Cluster ”.
NDB Cluster Auto-Installer Interface. This section describes the layout and navigation of the NDB Cluster Auto-Installer, whose Welcome screen looks similar to what is shown here when it is first opened in the Web browser:
You can access the installer UI by selecting either of the options Create New NDB Cluster or Continue Previous Cluster Configuration. A typical screen in the Auto-Installer includes the following elements:
Display panel. The central area where data regarding configuration settings and controls for changing them are displayed.
Breadcrumb navigation. Located in the top left and top center of the GUI, the breadcrumb navigation bar consists of a series of titles linking to screens that correspond to steps in the configuration of an NDB Cluster . The breadcrumb allows you to jump between these stages in arbritrary order.
Sequential navigation. This consists of a set of buttons labelled , , and , and can be found in the lower right-hand corner of the GUI. The sequential navigation is used to move between steps in the suggested order.
Settings and Help menus. These menus can be found in the top right corner of the GUI (to the right of the breadcrumb navigation bar). provides a way check and possibly alter configuration settings for the Auto-Installer; can be used to access the installer's built-in help files.
The locations of the elements just described are shown here in a typical page in the Auto-Installer; the numbers superimposed thereupon correspond to those used in the preceding list.
All of these elements except for the display panel are described in greater detail in the remainder of this section. Section 4.1.3, “Using the NDB Cluster Auto-Installer”, describes the panels shown in the display area as well as the functionality of each panel and the controls it contains.
Arbitrary and sequential navigation. The Auto-Installer can display any of a number of pages covering different stages in the setup and configuration of an NDB Cluster deployment. You can navigate between pages in either of two ways. The first of these is the breadcrumb trail navigation toolbar displaying the titles of the various pages (in which the title of the current page is highlighted and disabled). From these, any desired page, in any desired order, can be reached by selecting the title of the corresponding page. This toolbar is shown here:
The second navigation mechanism provided by the Auto-Installer consists of the , , and sequential navigation buttons at the bottom right of the page. These can be used to move to the next or previous page in predetermined order, or to go to the very last page. The buttons are enabled and disabled as needed, so that you cannot, for example, advance beyond the last page.
Settings and Help menus. These menus are positioned adjacent to one another in the top right corner of the GUI, as shown earlier in this section. The menu is shown here in more detail:
The entries in the menu are described here, in the following list:
: Remove all hosts and processes; reset all parameter values to their defaults; start the installer over at the first page.
: Save your configuration information—such as host names, process data, and parameter values—as a cookie in the browser. When this option is chosen, all information except any SSH password is saved. This means that you can quit and restart the browser, and continue working on the same configuration from where you left off at the end of the previous session).
Since the SSH password is never saved, you must supply this once again at the beginning of a new session, if one is used.
: Show advanced configuration parameters in the Auto-Installer and make these settable by the user.
Once set, the advanced parameters continue to be used in the configuration file until they are explicitly changed or reset. This is regardless of whether the advanced parameters are currently visible in the installer; in other words, disabling the menu item does not reset the values of any of these parameters.
: Query new hosts automatically for hardware resource information to pre-populate a number of configuration options and values. In this case, the suggested values are not mandatory, but they are used unless explicitly changed using the appropriate editing options in the installer.
As with the installer's navigation elements, one or more of the entries in the menu may be disabled due to choices you have made previously.
The menu is shown here, as it appears when expanded:
The menu provides several options, described in the following list:
: Show the built-in user guide. This is opened in a separate browser window, so that it can be used simultaneously with the installer without interrupting workflow.
: Open the built-in user guide to the section describing the page currently displayed in the installer.
: This will show a small dialog displaying the installer name and the version number of the NDB Cluster distribution it was supplied with, similar to what is shown here:
The Auto-Installer also provides context-sensitive help in the form of tooltips for most input widgets. One of these tooltips is displayed when the mouse hovers over a widget or the small question mark which can sometimes appear next to a widget label.
In addition, the names of NDB Cluster configuration parameters are linked to their descriptions in the online NDB Cluster documentation, so that if you click on the name of a given parameter, the documentation for that parameter is shown in a separate window.
Section 4.1.3.2, “NDB Cluster Auto-Installer Welcome Screen”
Section 4.1.3.3, “NDB Cluster Auto-Installer Define Cluster Screen”
Section 4.1.3.4, “NDB Cluster Auto-Installer Define Hosts Screen”
Section 4.1.3.5, “NDB Cluster Auto-Installer Define Processes Screen”
Section 4.1.3.6, “NDB Cluster Auto-Installer Define Attributes Screen”
Section 4.1.3.7, “NDB Cluster Auto-Installer Deploy Cluster Screen”
The NDB Cluster Auto-Installer consists of several pages, each corresponding to a step in the process used to configure and deploy an NDB Cluster , and listed here:
Welcome: Begin using the Auto-Installer by choosing either to configure a new NDB Cluster , or to continue configuring an existing one.
Define Cluster: Set basic information about the cluster as a whole, such as name, hosts, and load type. Here you can also set the SSH authentication type for accessing remote hosts, if needed.
Define Hosts: Identify the hosts where you intend to run NDB Cluster processes.
Define Processes: Assign one or more processes of a given type or types to each cluster host.
Define Attributes: Set configuration attributes for processes or types of processes.
Deploy Cluster: Deploy the cluster with the configuration set previously; start and stop the deployed cluster.
The following sections describe in greater detail the purpose and function of each of these pages, in the order just listed.
The Auto-Installer is provided together with the NDB Cluster
software. (See Chapter 4, NDB Cluster Installation.)
The present section explains how to start the installer. You
can do by invoking the ndb_setup.py
executable. ndb_setup.py is found in the
bin within the NDB Cluster installation
directory; a typical location might be
/usr/local/mysql/bin on a Linux system or
C:\Program Files\MySQL\MySQL Server
5.6\bin on a Windows system, but this can vary
according to where the NDB Cluster software is installed on
your system.
On Windows, you can also start the installer by running setup.bat in the NDB Cluster installation directory. When invoked from the command line, it accepts the same options as does ndb_setup.py.
ndb_setup.py can be started with any of several options that affect its operation, but it is usually sufficient to allow the default settings be used, in which case you can start ndb_setup.py by either of the following two methods:
Navigate to the NDB Cluster bin
directory in a terminal and invoke it from the command
line, without any additional arguments or options, like
this:
shell> ndb_setup
This works regardless of operating platform.
Navigate to the NDB Cluster bin
directory in a file browser (such Windows Explorer on
Windows, or Konqueror, Dolphin, or Nautilus on Linux) and
activate (usually by double-clicking) the
ndb_setup.py file icon. This works on
Windows, and should work with most common Linux desktops
as well.
On Windows, you can also navigate to the NDB Cluster installation directory and activate the setup.bat file icon.
In either case, once ndb_setup.py is invoked, the Auto-Installer's Welcome screen should open in the system's default Web browser.
In some cases, you may wish to use non-default settings for the installer, such as specifying a different port for the Auto-Installer's included Web server to run on, in which case you must invoke ndb_setup.py with one or more startup options with values overriding the necessary defaults. The same startup options can be used on Windows systems with the setup.bat file supplied for such platforms in the NDB Cluster software distribution. This can be done using the command line, but if you want or need to start the installer from a desktop or file browser while emplying one or more of these options, it is also possible to create a script or batch file containing the proper invocation, then to double-click its file icon in the file browser to start the installer. (On Linux systems, you might also need to make the script file executable first.) For information about advanced startup options for the NDB Cluster Auto-Installer, see Section 6.23, “ndb_setup.py — Start browser-based Auto-Installer for NDB Cluster ”.
The Welcome screen is loaded in the default browser when ndb_setup.py is invoked, as shown here:
This screen provides the following two choices for entering the installer, one of which must be selected to continue:
Create New NDB Cluster : Start the Auto-Installer with a completely new cluster to be set up and deployed.
Continue Previous Cluster Configuration: Start the Auto-Installer at the same point where the previous session ended, with all previous settings preserved.
The second option requires that the browser be able to access its cookies from the previous session, as these provide the mechanism by which configuration and other information generated during a session is stored. In other words, to continue the previous session with the Auto-Installer, you must use the same web browser running on the same host as you did for the previous session.
The Define Cluster screen is the first screen to appear following the choice made in the Welcome screen, and is used for setting general properties of the cluster. The layout of the Define Cluster screen is shown here:
The Define Cluster screen allows you to set a number of general properties for the cluster, as described in this list:
Cluster name: A name that identifies
the cluster. The default is MyCluster.
Host list: A comma-delimited list of
one or more hosts where cluster processes should run. By
default, this is 127.0.0.1. If you add
remote hosts to the list, you must be able to connect to
them using the SSH Credentials
supplied.
Application type: Choose one of the following:
: Minimal resource usage for small-scale testing. This the default. Not intended for production environments.
: Maximize performance for the given hardware.
: Maximize performance while maximizing sensitivity to timeouts in order to minimize the time needed to detect failed cluster processes.
Write load: Choose a level for the anticipated number of writes for the cluster as a whole. You can choose any one of the following levels:
: The expected load includes fewer than 100 write transactions for second.
: The expected load includes 100 to 1000 write transactions per second.
: The expected load includes more than 1000 write transactions per second.
SSH Credentials: Choose Key-Based SSH or enter User and Password credentials. The SSH key or a user name with password is required for connecting to any remote hosts specified in the Host list. By default, Key-Based SSH is selected, and the User and Password fileds are blank.
The Define Hosts screen, shown here, provides a means of viewing and specifying several key properties of each cluster host:
The hosts currently entered are displayed in the grid with various pieces of information. You can add hosts by clicking the button and entering a list of one or more comma-separated host names, IP addresses, or both (as when editing the host list on the Define Cluster screen).
Similarly, you can remove one or more hosts using the button labelled . When you remove a host in this fashion, any process which was configured for that host is also removed.
If Automatically get resource information for new hosts is checked in the menu, the Auto-Installer attempts to retrieve the platform name, amount of memory, and number of CPU cores and to fill these in automatically. The status of this is displayed in the Resource info column. Fetching the information from remote hosts is not instantaneous and may take some time, particularly from remote hosts running Windows.
If the SSH user credentials on the Define Cluster screen are changed, the tool tries to refresh the hardware information from any hosts for which information is missing. However, if a given field has already been edited, the user-supplied information is not overwritten by any value fetched from that host.
The hardware resource information, platform name, installation directory, and data directory can be edited by the user by clicking the corresponding cell in the grid, by selecting one or more hosts and clicking the button labelled Edit selected host(s). This causes a dialog box to appear, in which these fields can be edited, as shown here:
When more than one host is selected, any edited values are applied to all selected hosts.
The Define Processes screen, shown here, provides a way to assign NDB Cluster processes (nodes) to cluster hosts:
The left-hand portion of this screen contains a process tree showing cluster hosts and processes set up to run on each one. On the right is a panel which displays information about the item currently selected in the tree.
When this screen is accessed for the first time for a given cluster, a default set of processes is defined for you, based on the number of hosts. If you later return to the Define Hosts screen, remove all hosts, and add new hosts, this also causes a new default set of processes to be defined.
NDB Cluster processes are of the following types:
Management node. Performs administrative tasks such as stopping individual data nodes, querying node and cluster status, and making backups. Executable: ndb_mgmd.
Single-threaded data node. Stores data and executes queries. Executable: ndbd.
Multi threaded data node. Stores data and executes queries with multiple worker threads executing in parallel. Executable: ndbmtd.
SQL node.
MySQL server for executing SQL queries against
NDB. Executable:
mysqld.
API node.
A client accessing data in
NDB by means of the NDB API
or other low-level client API, rather than by using SQL.
See MySQL NDB Cluster API Developer Guide, for more information.
For more information about process (node) types, see Section 3.1, “NDB Cluster Core Concepts”.
Processes shown in the tree are numbered sequentially by type,
for each host—for example, SQL node
1, SQL node 2, and so on—to
simplify identification.
Each management node, data node, or SQL process must be assigned to a specific host, and is not allowed to run on any other host. An API node may be assigned to a single host, but this is not required. Instead, you can assign it to the special entry which the tree also contains in addition to any other hosts, and which acts as a placeholder for processes that are allowed to run on any host. Only API processes may use this entry.
Adding processes. To add a new process to a given host, either right-click that host's entry in the tree, then select the Add process popup when it appears, or select a host in the process tree, and press the button below the process tree. Performing either of these actions opens the add process dialog, as shown here:
Here you can select from among the available process types described earlier this section; you can also enter an arbitrary process name to take the place of the suggested value, if desired.
Removing processes. To delete a process, right-click on a process in the tree and select delete process from the pop up menu that appears, or select a process, then use the button below the process tree.
When a process is selected in the process tree, information about that process is displayed in the panel to the right of the tree, where you can change the process name and possibly its type. Important: Currently, you can change a single-threaded data node (ndbd) to a multi-threaded data node (ndbmtd), or the reverse, only; no other process type changes are allowed. If you want to make a change between any other process types, you must delete the original process first, then add a new process of the desired type.
This screen has a layout similar to that of the Define Processes screen, with a process tree at the left. Unlike that screen's tree, the Define Attributes process tree is organized by process or node type, with single-threaded and multi-threaded data nodes considered to be of the same type for this purpose, in groups labelled , , , and . A panel to the right of this tree displays information regarding the item currently selected. The Define Attributes screen is shown here:
A checkbox labelled Show advanced configuration is located below the process tree. Checking this box makes advanced options visible in the information pane. These options are set and used whether or not they are visible.
You can edit attributes for a single process by selecting that process from the tree, or for all processes of the same type in the cluster by selecting one of the folders. A per-process value set for a given attribute overrides any per-group setting for that attribute that would otherwise apply to the process in question. An example of such an information panel (for an SQL process) is shown here:
For some of the attributes shown in the information panel, a button bearing a plus sign is displayed to the right, which means that the value of this attribute can be overridden. This button activates an input widget for the attribute, enabling you to change its value. When the value has been overridden, this button changes into a button showing an , as shown here:
Clicking the button next to an attribute undoes any changes made to it; it immediately reverts to the predefined value.
All configuration attributes have predefined values calculated by the installer, based such factors as host name, node ID, node type, and so on. In most cases, these values may be left as they are. If you are not familiar with it already, it is highly recommended that you read the applicable documentation before making changes to any of the attribute values. To make finding this information easier, each attribute name shown in the information panel is linked to its description in the online NDB Cluster documentation.
This screen allows you to perform the following tasks:
Review process startup commands and configuration files to be applied
Distribute configuration files by creating any necessary files and directories on all cluster hosts—that is, deploy the cluster as presently configured
Start and stop the cluster
The Deploy Cluster screen is shown here:
Like the Define Attributes screen, this screens features a process tree, organized by process type, on the left hand side. Next to each process is a status icon whose color indicates the current status of the process: green if it is running; yellow if it is starting or stopping; red if the process is stopped.
To the right of the process tree are two information panels, the upper panel showing the startup command or commands needed to start the selected process. (For some processes, more than one command may be required—for example, if initialization is necessary.) The lower panel shows the contents of the configuration file, if any, for the given process; currently, the management node process is only type of process having a configuration file. Other process types are configured using command-line parameters when starting the process, or by obtaining configuration information from the management nodes as needed in real time.
Three buttons are located immediately below the process tree. These are labelled as and perform the functions described in the following list:
: Verify that the configuration is valid. Create any directories required on the cluster hosts, and distribute the configuration files onto the hosts. A progress bar shows how far the deployment has proceeded.
: The cluster is deployed as with , after which all cluster processes are started in the correct order.
Starting these processes may take some time. If the estimated time to completion is too large, the installer provides an opportunity to cancel or to continue of the startup procedure. A progress bar indicates the current status of the startup procedure, as shown here:
The process status icons adjoining the process tree mentioned previously also update with the status of each process.
: After the cluster has been started, you can stop it using the this. As with starting the cluster, cluster shutdown is not instantaneous, and may require some time complete. A progress bar, similar to that displayed during cluster startup, shows the approximate current status of the cluster shutdown procedure, as do the process status icons adjoining the process tree.
The Auto-Installer generates a my.cnf
file containing the appropriate options for each
mysqld process in the cluster.
This section covers installation methods for 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. For manual installation and setup instructions specific to Windows systems, see Section 4.3, “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.4, “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.5 binary archive
(mysql-cluster-gpl-7.5.5-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.4, “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.
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.5.5-linux2.6.tar.gzshell>ln -s /usr/local/mysql-cluster-gpl-7.5.5-linux2.6-i686 /usr/local/mysql
Change location to the mysql directory
and set up the system databases using
mysqld
--initialize as shown here:
shell>cd mysqlshell>mysqld --initialize
This generates a random password for the MySQL
root account. If you do
not want the random password to be
generated, you can substitute the
--initialize-insecure option
for --initialize. In either case, you
should review
Initializing the Data Directory Manually Using mysqld, for
additional information before performing this step. See also
mysql_secure_installation — Improve MySQL Installation Security.
Alternatively, you can change location to the
mysql directory and run
mysql_install_db to create the system
databases:
shell>cd mysqlshell>scripts/mysql_install_db --user=mysql
However, this method is not recommended, due to the fact that mysql_install_db is deprecated, and thus subject to removal in a future release.
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.7.16-ndb-7.5.5-linux-i686-glibc23.tar.gzshell>cd mysql-5.7.16-ndb-7.5.5-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.4, “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.7.16-ndb-7.5.5-linux2.6-i686.tar.gzshell>cd mysql-5.7.16-ndb-7.5.5-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.4, “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 beginning with NDB 7.5.4. For information about RPMs for previous versions of NDB Cluster , see Installation using old-style RPMs (NDB 7.5.3 and earlier).
RPMs are available for both 32-bit and 64-bit Linux platforms. The filenames for these RPMs use the following pattern:
mysql-cluster-license-component-ver-rev.distro.arch.rpmlicense:= {commercial | community}component: {management-server | data-node | server | client |other—see text}ver:major.minor.releaserev:major.minordistro: {el5 | el6 | el7 | sles12}arch: {i686 | x86_64}
license indicates whether the RPM is
part of a Commercial or Community release of NDB Cluster . In
the remainder of this section, we assume for the examples that
you are installing a Community release.
Possible values for component, with
descriptions, can be found in the following table:
| Component | Description |
|---|---|
auto-installer | NDB Cluster Auto Installer program; see Section 4.1, “The NDB Cluster Auto-Installer”, for usage |
client | MySQL and NDB client programs; includes
mysql client,
ndb_mgm client, and other client
tools |
common | Character set and error message information needed by the MySQL server |
data-node | ndbd and ndbmtd data node binaries |
devel | Headers and library files needed for MySQL client development |
embedded | Embedded MySQL server |
embedded-compat | Backwards-compatible embedded MySQL server |
embedded-devel | Header and library files for developing applications for embedded MySQL |
java | JAR files needed for support of ClusterJ applications |
libs | MySQL client libraries |
libs-compat | Backwards-compatible MySQL client libraries |
management-server | The NDB Cluster management server (ndb_mgmd) |
memcached | Files needed to support ndbmemcache |
ndbclient | NDB client library for running NDB API and MGM API
applications (libndbclient) |
ndbclient-devel | Header and other files needed for developing NDB API and MGM API applications |
nodejs | Files needed to set up Node.JS support for NDB Cluster |
server | The MySQL server (mysqld) with NDB
storage engine support included, and associated MySQL
server programs |
test | mysqltest, other MySQL test programs, and support files |
A single bundle (.tar file) of all NDB
Cluster RPMs for a given platform and architecture is also
available. The name of this file follows the pattern shown here:
mysql-cluster-license-ver-rev.distro.arch.rpm-tar
You can extract the individual RPM files from this file using tar or your preferred tool for extracting archives.
The components required to install the three major types of NDB Cluster nodes are given in the following list:
Management node:
management-server
Data node: data-node
SQL node: server and
common
In addition, the client RPM should be
installed to provide the ndb_mgm management
client on at least one management node. You may also wish to
install it on SQL nodes, to have mysql and
other MySQL client programs available on these. We discuss
installation of nodes by type later in this section.
ver represents the three-part
NDB storage engine version number in
7.5.x format, shown as
7.5.5 in the examples.
rev provides the RPM revision number in
major.minor
format. In the examples shown in this section, we use
1.1 for this value.
The distro (Linux distribution) is
one of rhel5 (Oracle Linux 5, Red Hat
Enterprise Linux 4 and 5), el6 (Oracle Linux
6, Red Hat Enterprise Linux 6), el7 (Oracle
Linux 7, Red Hat Enterprise Linux 7), or
sles12 (SUSE Enterprise Linux 12). For the
examples in this section, we assume that the host runs Oracle
Linux 7, Red Hat Enterprise Linux 7, or the equivalent
(el7).
arch is i686 for
32-bit RPMs and x86_64 for 64-bit versions.
In the examples shown here, we assume a 64-bit platform.
The NDB Cluster version number in the RPM file names (shown here
as 7.5.5) 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 should also be appropriate to the machine on which
the RPM is to be installed; in particular, you should keep in
mind that 64-bit RPMs (x86_64) cannot be used
with 32-bit operating systems (use i686 for
the latter).
Data nodes.
On a computer that is to host an NDB Cluster data node it is
necessary to install only the data-node
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-community-data-node-7.5.5-1.1.el7.x86_64.rpm
This installs the ndbd and
ndbmtd data node binaries in
/usr/sbin. Either of these can be used to
run a data node process on this host.
SQL nodes.
Copy the server and
common RPMs to each machine to be used for
hosting an NDB Cluster SQL node (server
requires common). 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-community-server-7.5.5-1.1.el7.x86_64.rpm
This installs the MySQL server binary
(mysqld), with NDB storage
engine support, in the /usr/sbin directory.
It also installs all needed MySQL Server support files and
useful MySQL server programs, including 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.
You must use the versions of these RPMs released for NDB
Cluster ; those released for the standard MySQL server do not
provide support for the NDB storage engine.
To administer the SQL node (MySQL server), you should also
install the client RPM, as shown here:
shell> rpm -Uhv mysql-cluster-community-client-7.5.5-1.1.el7.x86_64.rpm
This installs the mysql client and other
MySQL client programs, such as mysqladmin and
mysqldump, to /usr/bin.
Management nodes.
To install the NDB Cluster management server, it is necessary
only to use the management-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
management-server RPM downloaded from the
MySQL web site):
shell> rpm -Uhv mysql-cluster-commercial-management-server-7.5.5-1.1.el7.x86_64.rpm
This RPM installs the management server binary
ndb_mgmd in the
/usr/sbin directory. While this is the only
program actually required for running a management node, it is
also a good idea to have the ndb_mgm NDB
Cluster management client available as well. You can obtain this
program, as well as other NDB client programs
such as ndb_desc and
ndb_config, by installing the
client RPM as described previously.
Previously, ndb_mgm was installed by the
same RPM used to install the management server. In NDB 7.5.4
and later, all NDB client programs are
obtained from the same client RPM that
installs mysql and other MySQL clients.
See Installing MySQL on Linux Using RPM Packages from Oracle, for general information about installing MySQL using RPMs supplied by Oracle.
After installing from RPM, you still need to configure the cluster; see Section 4.4, “Initial Configuration of NDB Cluster”, for the relevant information.
Installation using old-style RPMs (NDB 7.5.3 and earlier). The information in the remainder of this section applies only to NDB 7.5.3 and earlier, and provides the steps necessary to install the correct executables for each type of NDB Cluster node using “old-style” RPM packages as supplied by Oracle prior to NDB 7.5.4. The filenames for these “old-style” RPMs use the following pattern:
MySQL-Cluster-component-producttype-ndbversion-revision.distribution.architecture.rpmcomponent:= {server | client [|other]}producttype:= {gpl | advanced}ndbversion:=major.minor.releasedistribution:= {sles11 | 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.5.x format; we use
7.5.3 throughout the rest of this section.
The RPM revision is shown as
1 in the examples following. 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.5.3-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 .
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.5.3-1.sles11.i386.rpm),
which supplies the mysql client
It is very important that all of the Cluster RPMs to
be installed have the same version number. The
architecture designation should also
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.5.3-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.5.3-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.5.3-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.5.3-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 from Oracle, for general information about installing MySQL using RPMs supplied by Oracle. See Section 4.4, “Initial Configuration of NDB Cluster”, for information about required post-installation configuration.
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.5 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 (6.0 or 7), and
arch is one of
i686 or x86_64. In the
examples that follow, we assume you wish to install NDB
7.5.5 on a 64-bit Debian 7 system; in this
case, the installer file is named
mysql-cluster-gpl-7.5.5-debian7-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.5.5-debian7-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 7.5, this
is always 5.7. 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.3.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.5.5.tar.gz.
You can also obtain MySQL development sources from
launchpad.net. Building NDB Cluster
from standard MySQL Server 5.7 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 .
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. 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.4, “Initial Configuration of NDB Cluster”, we create configuration files for all of the nodes in our example NDB Cluster .
This section describes installation procedures for NDB Cluster on Windows hosts. NDB Cluster 7.5 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.3.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.3.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), 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.5.5), and
arch is the architecture
(32 for 32-bit binaries, and
64 for 64-bit binaries). For example, the NDB
Cluster 7.5.5 no-install
archive for 32-bit Windows systems is named
mysql-cluster-gpl-noinstall-7.5.5-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.7, 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.7\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.)
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.3.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. The output should appear similar to what is shown here:
C:\mysql\bin> ndb_mgmd
2010-06-23 07:53:34 [MgmtSrvr] INFO -- NDB Cluster Management Server. mysql-5.7.16-ndb-7.5.5
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.3.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.27, “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.3.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.7.16-ndb-7.5.5)
Node 3: starting (Last completed phase 3) (mysql-5.7.16-ndb-7.5.5)
Node 2: starting (Last completed phase 4) (mysql-5.7.16-ndb-7.5.5)
Node 3: starting (Last completed phase 4) (mysql-5.7.16-ndb-7.5.5)
Node 2: Started (version 7.5.5)
Node 3: Started (version 7.5.5)
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.7.16-ndb-7.5.5, Nodegroup: 0, *)
id=3 @192.168.0.40 (Version: 5.7.16-ndb-7.5.5, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @192.168.0.10 (Version: 5.7.16-ndb-7.5.5)
[mysqld(API)] 1 node(s)
id=4 @192.168.0.20 (Version: 5.7.16-ndb-7.5.5)
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.6, “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.3.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.
In this section, we discuss manual configuration of an installed NDB Cluster by creating and editing configuration files.
NDB Cluster also provides a GUI installer which can be used to perform the configuration without the need to edit text files in a separate application. For more information, see Section 4.1, “The NDB Cluster Auto-Installer”.
For our four-node, four-host NDB Cluster (see Cluster nodes and host computers), 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.5, “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.27, “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.7.16-ndb-7.5.5, Nodegroup: 0, *) id=3 @192.168.0.40 (Version: 5.7.16-ndb-7.5.5, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @192.168.0.10 (Version: 5.7.16-ndb-7.5.5) [mysqld(API)] 1 node(s) id=4 @192.168.0.20 (Version: 5.7.16-ndb-7.5.5)
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.6, “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.7.16-ndb-7.5.5
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.12.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.27, “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.3.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.3.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.5 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.
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. See
Upgrading MySQL.
The table shown here provides information on NDB Cluster upgrade and downgrade compatibility among different releases of NDB 7.5. Additional notes about upgrades and downgrades to, from, or within the NDB Cluster 7.5 release series can be found following the table.
Version support. The following versions of NDB Cluster are supported for upgrades to GA releases of NDB Cluster 7.5 (7.5.4 and later):
NDB Cluster 7.4 GA releases (7.4.4 and later)
NDB Cluster 7.3 GA releases (7.3.2 and later)
NDB Cluster 7.2 GA releases (7.2.4 and later)
Known Issues. The following issues are known to occur when upgrading to or between the stated releases:
When upgrading from NDB 7.5.2 or 7.5.3 to a later version, the
use of mysqld with the
--initialize and
--ndbcluster options together
caused problems later running
mysql_upgrade.
When run with --initialize, the server does
not require NDB support; having
NDB enabled at this time can cause problems
with ndbinfo tables. To keep
this from happening, the --initialize option
now causes mysqld to ignore the
--ndbcluster option if the latter is also
specified.
A workaround for an upgrade that has failed for these reasons can be accomplished as follows:
Perform a rolling restart of the entire cluster
Delete all .frm files in the
data/ndbinfo directory
Run mysql_upgrade.
(Bug #81689, Bug #82724, Bug #24521927, Bug #23518923)
During an online upgrade from an NDB Cluster 7.3 release to an
NDB 7.4 (or later) release, the failures of several data nodes
running the lower version during local checkpoints (LCPs), and
just prior to upgrading these nodes, led to additional node
failures following the upgrade. This was due to lingering
elements of the EMPTY_LCP protocol
initiated by the older nodes as part of an LCP-plus-restart
sequence, and which is no longer used in NDB 7.4 and later due
to LCP optimizations implemented in those versions. This issue
was fixed in NDB 7.5.4. (Bug #23129433)
Beginning with NDB 7.5.2, the
ndb_binlog_index table uses the
InnoDB storage engine. (Use of
the MyISAM storage engine for this table
continues to be supported for backward compatibility.)
When upgrading a previous release to NDB 7.5.2 or later, you
can use the --force
--upgrade-system-tables
options with mysql_upgrade so that it
performs ALTER
TABLE ... ENGINE=INNODB on the
ndb_binlog_index table.
For more information, see Section 8.4, “NDB Cluster Replication Schema and Tables”.
Online upgrades from previous versions of NDB Cluster to NDB 7.5.1 were not possible due to missing entries in the matrix used to test upgrade compatibility between versions. (Bug #22024947)
Also in NDB 7.5.1, mysql_upgrade failed to
upgrade the sys schema if a
sys database directory existed but was
empty. (Bug #81352, Bug #23249846, Bug #22875519)