It is highly recommended that you take a complete backup of the “wild” cluster before you make changes to it, using the ndb_mgm client. For more information, see Using The NDB Cluster Management Client to Create a Backup.

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:

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.

Verify that each process in the “wild” cluster has a valid PID file.

If a given process does not have a valid PID file, you must create one for it.

Install MySQL Cluster Manager and start mcmd on all hosts with the same system user who started the wild cluster processes.

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, you need not specify the node IDs for the processes in the create cluster command.

Also, this step may be split into a create cluster command followed by one or more add process commands (see Section 4.5.2.3, “Creating and Configuring the Target Cluster”).

For importing a cluster that uses TLS connections, perform the following steps (see TLS Link Encryption for NDB Cluster and Section 4.11, “Using TLS Connections for NDB Clusters” for details):

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.

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.