This section discusses how to perform a rolling restart of a MySQL Cluster installation, so called because it involves stopping and starting (or restarting) each node in turn, so that the cluster itself remains operational. This is often done as part of a rolling upgrade or rolling downgrade, where high availability of the cluster is mandatory and no downtime of the cluster as a whole is permissible. Where we refer to upgrades, the information provided here also generally applies to downgrades as well.
There are a number of reasons why a rolling restart might be desirable. These are described in the next few paragraphs.
MySQL Cluster software upgrade or downgrade. To upgrade the cluster to a newer version of the MySQL Cluster software (or to downgrade it to an older version). This is usually referred to as a “rolling upgrade” (or “rolling downgrade”, when reverting to an older version of MySQL Cluster).
Change on node host. To make changes in the hardware or operating system on which one or more MySQL Cluster node processes are running.
System reset (cluster reset). To reset the cluster because it has reached an undesirable state. In such cases it is often desirable to reload the data and metadata of one or more data nodes. This can be done in any of three ways:
Start each data node process (ndbd or possibly ndbmtd) with the
--initialoption, which forces the data node to clear its file system and to reload all MySQL Cluster data and metadata from the other data nodes.
See Section 18.5.3, “Online Backup of MySQL Cluster”, and Section 18.4.20, “ndb_restore — Restore a MySQL Cluster Backup”, for more information.
The process for performing a rolling restart may be generalized as follows:
Stop, reconfigure, then restart each cluster data node (ndbd process) in turn.
Stop, reconfigure, then restart each cluster SQL node (mysqld process) in turn.
The specifics for implementing a given rolling upgrade depend upon the changes being made. A more detailed view of the process is presented here:
In the previous diagram, the Stop
and Start steps indicate that the
process must be stopped completely using a shell command (such as
kill on most Unix systems) or the management
STOP command, then
started again from a system shell by invoking the
ndbd or ndb_mgmd executable
as appropriate. On Windows, you can also use the system
NET START and
commands or the Windows Service Manager to start and stop nodes
which have been installed as Windows services (see
Section 184.108.40.206, “Installing MySQL Cluster Processes as Windows Services”).
Restart indicates that the
process may be restarted using the ndb_mgm
command (see Section 18.5.2, “Commands in the MySQL Cluster Management Client”).
MySQL Cluster supports a flexible order for upgrading nodes. When upgrading a MySQL Cluster, you may upgrade API nodes (including SQL nodes) before upgrading the management nodes, data nodes, or both. In other words, you are permitted to upgrade the API and SQL nodes in any order. This is subject to the following provisions:
This functionality is intended for use as part of an online upgrade only. A mix of node binaries from different MySQL Cluster releases is neither intended nor supported for continuous, long-term use in a production setting.
All management nodes must be upgraded before any data nodes are upgraded. This remains true regardless of the order in which you upgrade the cluster's API and SQL nodes.
Features specific to the “new” version must not be used until all management nodes and data nodes have been upgraded.
This also applies to any MySQL Server version change that may apply, in addition to the NDB engine version change, so do not forget to take this into account when planning the upgrade. (This is true for online upgrades of MySQL Cluster in general.)
See also Bug #48528 and Bug #49163.
It is not possible for any API node to perform schema operations (such as data definition statements) during a node restart.
Rolling restarts with multiple management servers. When performing a rolling restart of a MySQL Cluster with multiple management nodes, you should keep in mind that ndb_mgmd checks to see if any other management node is running, and, if so, tries to use that node's configuration data. To keep this from occurring, and to force ndb_mgmd to reread its configuration file, perform the following steps:
Stop all MySQL Cluster ndb_mgmd processes.
Complete the rolling restarts of the data nodes and API nodes as normal.
When performing a rolling restart to update the cluster's
configuration, you can use the
config_generation column of the
ndbinfo.nodes table to keep
track of which data nodes have been successfully restarted with
the new configuration. See
Section 220.127.116.11, “The ndbinfo nodes Table”.