Table of Contents
- 4.1 The NDB Cluster Auto-Installer
- 4.2 Installation of NDB Cluster on Linux
- 4.3 Installing NDB Cluster on Windows
- 4.4 Initial Configuration of NDB Cluster
- 4.5 Initial Startup of NDB Cluster
- 4.6 NDB Cluster Example with Tables and Data
- 4.7 Safe Shutdown and Restart of NDB Cluster
- 4.8 Upgrading and Downgrading NDB Cluster
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.3 and later also provides the 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:
This setup is also shown in 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 forndb1.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 website (seehttp://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, seeSection 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 beginning with NDB 7.3.1. 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.
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. 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”).
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 Cluster 7.3 and later 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, seehttp://www.mysql.com/support/supportedplatforms/cluster.html.
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, seehttp://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.
ImportantYou should never use the system
rootaccount for remote access, as this is extremely insecure. In addition, mysqld cannot normally be started by systemroot. For these and other reasons, you should provide SSH credentials for a regular user account on the target system, and not for systemroot. 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-httpsand--cert-fileoptions.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-fileoption.
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.11, “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 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.
You should run the ndb_setup.py as a normal user; no special privileges are needed to do so. You should notrun this program as the mysql user, or using the system root or Administrator account; doing so may cause the installation to fail.
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
bindirectory in a terminal and invoke it from the command line, without any additional arguments or options, like this:shell>ndb_setupThis works regardless of operating platform.
Navigate to the NDB Cluster
bindirectory 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.25, “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 Credentialssupplied.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 fields 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:
This screen contains a process tree showing cluster hosts and processes set up to run on each one, as well as 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
NDBby 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 information panel, 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, including a process tree. 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 . An information panel displays information regarding the item currently selected. The Define Attributes screen is shown here:
The checkbox labelled Show advanced configuration, when checked, 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, which means that the value of the 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, deploythe cluster as presently configured
Start and stop the cluster
The Deploy Cluster screen is shown here:
Like the Define Attributes screen, this screen features a process tree which is organized by process type. Next to each process in the tree is a status icon indicating the current status of the process: connected (CONNECTED), starting (STARTING), running (STARTED), stopping (STOPPING), or disconnected (NO_CONTACT). The icon shows green if the process is connected or running; yellow if it is starting or stopping; red if the process is stopped or cannot be contacted by the management server.
This screen also contains two information panels, one 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 other 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.
This screen also contains three buttons, labelled as and performing 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 this button. 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.
Prior to NDB 7.3.3, SQL nodes were started with all options employed on the command line. Beginning with NDB 7.3.3, the Auto-Installer generates a my.cnf file containing the appropriate options for each mysqld process in the cluster. (Bug #16994782)
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 binary archive from the NDB Cluster downloads page. (For the most recent 64-bit NDB 7.4 release, this is mysql-cluster-gpl-7.4.21-linux-glibc2.12-x86_64.tar.gz.) We assume that you have placed this file in each machine's /var/tmp directory.
If you 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/passwdand/etc/groupfiles (or use whatever tools are provided by your operating system for managing users and groups) to see whether there is already amysqlgroup andmysqluser on the system. Some OS distributions create these as part of the operating system installation process. If they are not already present, create a newmysqluser group, and then add amysqluser to this group:shell>
groupadd mysqlshell>useradd -g mysql -s /bin/false mysqlThe 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
mysqlto themysqldirectory.NoteThe 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.4.21-linux-glibc2.12-x86_64.tar.gzshell>ln -s /usr/local/mysql-cluster-gpl-7.4.21-linux-glibc2.12-x86_64 /usr/local/mysqlChange location to the
mysqldirectory and run the supplied script for creating the system databases:shell>
cd mysqlshell>scripts/mysql_install_db --user=mysqlSet 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/tmpdirectory, 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-cluster-gpl-7.4.21-linux-glibc2.12-x86_64.tar.gzshell>cd mysql-cluster-gpl-7.4.21-linux-glibc2.12-x86_64shell>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/tmponce 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/tmpdirectory, 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-cluster-gpl-7.4.21-linux-glibc2.12-x86_64.tar.gzshell>cd mysql-cluster-gpl-7.4.21-linux-glibc2.12-x86_64shell>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/tmponce 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.
RPMs are available for both 32-bit and 64-bit Linux platforms. The filenames for these RPMs use the following pattern:
MySQL-Cluster-component-producttype-ndbversion.distribution.architecture.rpmcomponent:= {server | client [|other]}producttype:= {gpl | advanced}ndbversion:=major.minor.releasedistribution:= {sles10 | rhel5 | el6}architecture:= {i386 | x86_64}
The component can be server or client. (Other values are possible, but since only the server and clientcomponents are required for a working NDB Cluster installation, we do not discuss them here.) Theproducttype 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.3.x or 7.4.x format. The distribution can be one of sles11 (SUSE Enterprise Linux 11),rhel5 (Oracle Linux 5, Red Hat Enterprise Linux 4 and 5), or el6 (Oracle Linux 6, Red Hat Enterprise Linux 6) The architecture is i386 for 32-bit RPMs and x86_64 for 64-bit versions.
For an NDB Cluster, one and possibly two RPMs are required:
The
serverRPM (for example,MySQL-Cluster-server-gpl-7.3.22-1.sles11.i386.rpmorMySQL-Cluster-server-gpl-7.4.21-1.sles11.i386.rpm), which supplies the core files needed to run a MySQL Server withNDBCLUSTERstorage 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
clientRPM (for example,MySQL-Cluster-client-gpl-7.3.22-1.sles11.i386.rpmorMySQL-Cluster-client-gpl-7.4.21-1.sles11.i386.rpm), which supplies the mysql client
The NDB Cluster version number in the RPM file names (shown here as 7.3.22 or 7.4.21, depending on whether you are installing NDB Cluster 7.3 or NDB Cluster 7.4) can vary according to the version which you are actually using. It is very important that all of the Cluster RPMs to be installed have the same version number. The architecture designation should 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 website:
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.22-1.sles11.i386.rpm
or
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.21-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 website:
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.22-1.sles11.i386.rpm
or
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.21-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.3.22-1.sles11.i386.rpm
or
shell> rpm -Uhv MySQL-Cluster-client-gpl-7.4.21-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 serverRPM. 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 website):
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.3.22-1.sles11.i386.rpm
or
shell> rpm -Uhv MySQL-Cluster-server-gpl-7.4.21-1.sles11.i386.rpm
Although this RPM installs many other files, only the management server binary ndb_mgmd (in the /usr/sbindirectory) is actually required for running a management node. The server RPM also installs ndb_mgm, theNDB management client.
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 as discussed in Section 4.4, “Initial Configuration of NDB Cluster”.
A number of RPMs used by NDB Cluster 7.1 were made obsolete and discontinued in NDB Cluster 7.3. These include the former MySQL-Cluster-clusterj, MySQL-Cluster-extra, MySQL-Cluster-management, MySQL-Cluster-storage, and NDB Cluster-tools RPMs. The former contents of all of these packages are now included in the MySQL-Cluster-server RPM.
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.3 and NDB Cluster 7.4 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.4.9 on a 64-bit Debian 7 system; in this case, the installer file is named mysql-cluster-gpl-7.4.9-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.4.9-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 both NDB Cluster 7.3 and NDB Cluster 7.4, this is always 5.6. 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.3.22.tar.gz (NDB Cluster 7.3) or mysql-cluster-gpl-7.4.21.tar.gz (NDB Cluster 7.4). You can also obtain MySQL development sources from launchpad.net. Building NDB Cluster from standard MySQL Server 5.6 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.
In NDB Cluster 7.3 and later, the WITH_NDB_JAVA option is enabled by default. This means that, by default, ifCMake 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. Onlyndb_mgmd is required to be present on a management node host; however, it is also a good idea to havendb_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.3 and NDB Cluster 7.4 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:
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 ZIP binary archive from http://dev.mysql.com/downloads/cluster/. This archive has a filename of the mysql-cluster-gpl-, where ver-winarch.zipver is the NDB storage engine version (such as 7.4.21), and arch is the architecture (32 for 32-bit binaries, and 64 for 64-bit binaries). For example, the NDB Cluster 7.4.21 archive for 64-bit Windows systems is named mysql-cluster-gpl-7.4.21-win64.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 archive in the directory C:\Documents and Settings\ on the computer having the IP address 198.51.100.20, whereusername\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-. 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.6, 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.6\data, extra configuration options must be used on the command line or added to the my.ini ormy.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=198.51.100.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 198.51.100.30 and 198.51.100.40), create the directories C:\mysql, C:\mysql\bin, andC:\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=198.51.100.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 198.51.100.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 (
HostNameconfiguration 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 (
DataMemoryandIndexMemoryconfiguration parameters)The number of replicas, using the
NoOfReplicasconfiguration 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
DataDirconfiguration 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=198.51.100.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=198.51.100.30 # Hostname or IP address [ndbd] # Options for data node "B": HostName=198.51.100.40 # Hostname or IP address [mysqld] # SQL node options: HostName=198.51.100.20 # Hostname or IP addressSave 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 fromhttp://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_ENGINEorWITH_NDBCLUSTERoption in addition to any other build options you wish to use with CMake. (WITH_NDBCLUSTERis supported as an alias forWITH_NDBCLUSTER_STORAGE_ENGINE, and works in exactly the same way.)
In NDB Cluster 7.3 and later, the WITH_NDB_JAVA option is enabled by default. This means that, by default, ifCMake 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_mgmd2010-06-23 07:53:34 [MgmtSrvr] INFO -- NDB Cluster Management Server. mysql-5.6.40-ndb-7.4.21 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
-foption tells the management node where to find the global configuration file (config.ini). The long form of this option is--config-file.ImportantAn NDB Cluster management node caches the configuration data that it reads from
config.ini; once it has created a configuration cache, it ignores theconfig.inifile 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-readconfig.iniafter you have corrected any errors in it. You can do this by starting ndb_mgmd.exewith the--reloador--initialoption 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.inifile.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.29, “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>ndbd2010-06-23 07:53:46 [ndbd] INFO -- Configuration fetched from 'localhost:1186', generation: 1In 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, seeSection 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\binon 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 enteringALL STATUSat 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 STATUSConnected to Management Server at: localhost:1186 Node 2: starting (Last completed phase 3) (mysql-5.6.40-ndb-7.4.21) Node 3: starting (Last completed phase 3) (mysql-5.6.40-ndb-7.4.21) Node 2: starting (Last completed phase 4) (mysql-5.6.40-ndb-7.4.21) Node 3: starting (Last completed phase 4) (mysql-5.6.40-ndb-7.4.21) Node 2: Started (version 7.4.21) Node 3: Started (version 7.4.21) ndb_mgm>NoteCommands 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_mgmclient. For more information, see Section 7.2, “Commands in the NDB Cluster Management Client”.
The output produced by
ALL STATUSis 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 --consoleThe
--consoleoption 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--consoleoption, 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
SHOWcommand, which should produce output similar to what is shown here:ndb_mgm>SHOWConnected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 @198.51.100.30 (Version: 5.6.40-ndb-7.4.21, Nodegroup: 0, *) id=3 @198.51.100.40 (Version: 5.6.40-ndb-7.4.21, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @198.51.100.10 (Version: 5.6.40-ndb-7.4.21) [mysqld(API)] 1 node(s) id=4 @198.51.100.20 (Version: 5.6.40-ndb-7.4.21)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 STATUSstatement.
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 (NDB versions 7.3 and later) 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.cnffile that provides two pieces of information: a connection stringthat 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 theNDBCLUSTERstorage engine.For more information on connection strings, see Section 5.3.3, “NDB Cluster Connection Strings”.
The management node needs a
config.inifile 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=198.51.100.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 asroot):
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 NDB Cluster setup.
ServerPort=2202 # This the default value; however, you can use any
# port that is free for all the hosts in the cluster
# Note1: It is recommended that you do not specify the port
# number at all and simply allow the default value to be used
# instead
# Note2: The port was formerly specified using the PortNumber
# TCP parameter; this parameter is no longer available in NDB
# Cluster 7.5.
[ndb_mgmd]
# Management process options:
HostName=198.51.100.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=198.51.100.30 # Hostname or IP address
NodeId=2 # Node ID for this data node
DataDir=/usr/local/mysql/data # Directory for this data node's data files
[ndbd]
# Options for data node "B":
HostName=198.51.100.40 # Hostname or IP address
NodeId=3 # Node ID for this data node
DataDir=/usr/local/mysql/data # Directory for this data node's data files
[mysqld]
# SQL node options:
HostName=198.51.100.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 inSection 4.5, “Initial Startup of NDB Cluster”.
For more detailed information about the available NDB Cluster configuration parameters and their uses, seeSection 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.iniThe first time that it is started, ndb_mgmd must be told where to find its configuration file, using the
-for--config-fileoption. (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.29, “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>ndbdIf 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 @198.51.100.30 (Version: 5.6.40-ndb-7.4.21, Nodegroup: 0, *) id=3 @198.51.100.40 (Version: 5.6.40-ndb-7.4.21, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @198.51.100.10 (Version: 5.6.40-ndb-7.4.21) [mysqld(API)] 1 node(s) id=4 @198.51.100.20 (Version: 5.6.40-ndb-7.4.21)
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
NDBCLUSTERstorage engine. To specify this, use theENGINE=NDBCLUSTERorENGINE=NDBoption when creating the table:CREATE TABLE
tbl_name(col_namecolumn_definitions) ENGINE=NDBCLUSTER;Alternatively, for an existing table that uses a different storage engine, use
ALTER TABLEto change the table to useNDBCLUSTER:ALTER TABLEtbl_nameENGINE=NDBCLUSTER;Every
NDBCLUSTERtable has a primary key. If no primary key is defined by the user when a table is created, theNDBCLUSTERstorage 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 ENGINEoptions. 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 ofTYPE= 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 198.51.100.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.6.40-ndb-7.4.21
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, seeSecuring the Initial MySQL Accounts.
It is worth taking into account that Cluster nodes do not make use of the MySQL privilege system when accessing one another. Setting or changing MySQL user accounts (including the root account) effects only applications that access the SQL node, not interaction between nodes. See Section 7.11.2, “NDB Cluster and MySQL Privileges”, for more information.
If you did not modify the ENGINE clauses in the table definitions prior to importing the SQL script, you should run the following statements at this point:
mysql>USE world;mysql>ALTER TABLE City ENGINE=NDBCLUSTER;mysql>ALTER TABLE Country ENGINE=NDBCLUSTER;mysql>ALTER TABLE CountryLanguage ENGINE=NDBCLUSTER;
Selecting a database and running a SELECT query against a table in that database is also accomplished in the usual manner, as is exiting the MySQL Monitor:
mysql>USE world;mysql>SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;+-----------+------------+ | Name | Population | +-----------+------------+ | Bombay | 10500000 | | Seoul | 9981619 | | São Paulo | 9968485 | | Shanghai | 9696300 | | Jakarta | 9604900 | +-----------+------------+ 5 rows in set (0.34 sec) mysql>\qBye shell>
Applications that use MySQL can employ standard APIs to access NDB tables. It is important to remember that your application must access the SQL node, and not the management or data nodes. This brief example shows how we might execute the SELECT statement just shown by using the PHP 5.X mysqli extension running on a Web server elsewhere on the network:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>SIMPLE mysqli SELECT</title>
</head>
<body>
<?php
# connect to SQL node:
$link = new mysqli('198.51.100.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.29, “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 ndbmtdprocesses 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 (
198.51.100.10in our example setup):shell>ndb_mgmd -f /var/lib/mysql-cluster/config.iniOn each of the data node hosts (
198.51.100.30and198.51.100.40):shell>ndbdUse the ndb_mgm client to verify that both data nodes have started successfully.
On the SQL host (
198.51.100.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 (
198.51.100.10in our example setup), execute the following command:C:\>NET START ndb_mgmdOn each of the data node hosts (
198.51.100.30and198.51.100.40), execute the following command:C:\>NET START ndbdOn 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 (
198.51.100.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.3 releases with regard to performing upgrades and downgrades as well as compatibility matrices and notes. You are expected already to be familiar with installing and configuring an NDB Cluster prior to attempting an upgrade or downgrade. See Chapter 5, Configuration of NDB Cluster.
For information regarding the rolling restart procedure used to perform an online upgrade, see Section 7.5, “Performing a Rolling Restart of an NDB Cluster”.
Only compatibility between MySQL versions with regard to NDBCLUSTER is taken into account in this section, and there are likely other issues to be considered. As with any other MySQL software upgrade or downgrade, you are strongly encouraged to review the relevant portions of the MySQL Manual for the MySQL versions from which and to which you intend to migrate, before attempting an upgrade or downgrade of the NDB Cluster software. See Upgrading MySQL.
The tables shown here provide information on NDB Cluster upgrade and downgrade compatibility among different releases of NDB Cluster 7.3 and of NDB Cluster 7.4, respectively. Additional notes about upgrades and downgrades to, from, or within the NDB Cluster 7.3 and NDB Cluster 7.4 release series can be found following the tables.
Upgrades and Downgrades, NDB Cluster 7.4
Version support. The following versions of NDB Cluster are supported for upgrades to NDB Cluster 7.4 (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)
NDB Cluster 7.1 GA releases (7.1.3 and later)
NDB Cluster 7.0 GA releases (7.0.5 and later)
NDB 7.4.10 Replacement Release. Shortly after the release of NDB 7.4.9, a regression was discovered that adversely affected node and system restarts (Bug #22582233). This issue was known to affect NDB 7.4.8 as well. NDB 7.4.10—incorporating a fix for this regression, but otherwise identical to NDB 7.4.9—was released shortly thereafter as a replacement. Users of the NDB 7.4 series are advised to bypass the 7.4.8 and 7.4.9 releases and to upgrade directly to NDB 7.4.10 (or later).
Known Issues—NDB 7.4
Prior to NDB 7.4.4, when upgrading from NDB 7.3 to NDB 7.4, the first new data node binary to be started caused the master node (still running NDB 7.3) to fail, then itself failed. (Bug #20608889)
Prior to NDB 7.4.3, mysql_upgrade failed to drop and recreate
ndbinfo. (Bug #74863, Bug #20031425) In addition, when running mysql_upgrade on an NDB Cluster SQL node, the expected drop of theperformance_schemadatabase on this node was instead performed on all SQL nodes connected to the cluster. (Bug #200328691)
Upgrades and Downgrades, NDB Cluster 7.3
Version support. The following versions of NDB Cluster are supported for upgrades to NDB Cluster 7.3 (7.3.2 and later):
NDB Cluster 7.2 GA releases (7.2.4 and later)
NDB Cluster 7.1 GA releases (7.1.3 and later)
NDB Cluster 7.0 GA releases (7.0.5 and later)
NDB Cluster 6.3 GA releases (6.3.8 and later) that can be upgraded to NDB Cluster 7.1
Known Issues—NDB 7.3
Prior to NDB 7.3.8, mysql_upgrade failed to drop and recreate
ndbinfo. (Bug #74863, Bug #20031425) In addition, when running mysql_upgrade on an NDB Cluster SQL node, the expected drop of theperformance_schemadatabase on this node was instead performed on all SQL nodes connected to the cluster. (Bug #200328691)NDB API, ClusterJ, and other applications used with recent releases of NDB Cluster 6.3 and later should continue to work with NDB 7.3.2 and later without rewriting or recompiling.
It is not possible to downgrade online to NDB 7.3.2 or earlier from NDB 7.3.3 or later. Online upgrades from NDB 7.3.2 to later NDB Cluster 7.3 releases are supported.
For information about upgrades and downgrades in previous NDB Cluster release series, seehttp://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-upgrade-downgrade-compatibility-6.x.html,http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-upgrade-downgrade-compatibility-7.x.html, and Upgrading and Downgrading NDB Cluster