Any cluster processes that are under the control of the
system's boot-time process management facility,
such as /etc/init.d on Linux
systems or the Services Manager on Windows platforms,
should be removed from its control.

The wild cluster's configuration must meet the following
requirements, and it should be reconfigured and
restarted if it does not:

NodeID must be assigned for every
node.

DataDir must be specified for
each management and data node, and the data
directories for different nodes cannot overlap with
each other.

A “free” API node not bounded to any
host must be provisioned, through which the
mcmd agent can communicate with
the cluster.

Create a MySQL user named mcmd on
each SQL node, and grant root privileges to the user.

Make sure that the configuration cache is disabled for
each management node. Since the configuration cache is
enabled by default, unless the management node has been
started with the
--config-cache=false
option, you will need to stop and restart it with that
option, in addition to other options that it has been
started with previously.

Create a MySQL Cluster Manager site encompassing these hosts, using the
create
site command.

Add a MySQL Cluster Manager package referencing the MySQL NDB Cluster binaries,
using the add
package command. Use this command's
--basedir option to point to the
location of the MySQL NDB Cluster installation directory.

Create the target cluster using the
create
cluster command, including the same processes
and hosts used by the wild cluster. Use the command's
--import option to specify that the
cluster is a target for import.

If the wild cluster adheres to the recommendation for
node ID assignments given in the description for the
create
cluster command (that is, having node ID 1 to
48 assigned to data nodes, and 49 and above assigned to
other node types), you need not specify the node IDs for
the processes in the
create
cluster command.

Use import config to
copy the wild cluster's configuration data into the
target cluster. Use this command's
--dryrun
option (short form: -y) to perform a
test run that merely logs the configuration information
the command copies when it is executed without the
option.

If any ndb_mgmd or
mysqld processes in the wild cluster
are running on ports other than the default, you must
first perform set
commands to assign the correct port numbers for them in
the target cluster. When all such processes are running
on the correct ports and the dry run is successful, you
can execute import config (without
the
--dryrun
option) to copy the wild cluster's configuration
data. Following this step, you should check the log as
well as the configuration of the target cluster to
ensure that all configuration attributes were copied
correctly and with the correct scope. Correct any
inconsistencies with the wild cluster's
configuration using the appropriate
set commands.

Test and perform migration of wild
cluster.

Perform a test run of the proposed migration using
import
cluster with the
--dryrun
option, which causes MySQL Cluster Manager to check for errors, but not
actually migrate any processes or data.

Correct any errors found using
--dryrun.
Repeat the dry run from the previous step to ensure that
no errors were missed.

When the dry run no longer reports any errors, you can
perform the migration using import
cluster, but without the
--dryrun
option.