MySQL Cluster Manager acts through a MySQL user named mcmd on each SQL node. It is therefore necessary to create this user and grant root privileges to it. To do this, log in to the SQL node running on host delta and execute in the mysql client the SQL statements shown here:

CREATE USER 'mcmd'@'delta' IDENTIFIED BY 'super';

GRANT ALL PRIVILEGES ON *.* TO 'mcmd'@'delta' WITH GRANT OPTION;

Keep in mind that, if the “wild” cluster has more than one SQL node, you must create the mcmd user on every one of these nodes.

Kill each data node angel process using the system's facility for doing so. Do not kill any non-angel data node daemons. On a Linux system, you can identify angel processes by matching their process IDs with the owner IDs of the remaining ndbd processes in the output of ps executed on host beta of the example cluster, as shown here, with the relevant process IDs shown in emphasized text:

$> ps -ef | grep ndbd
jon       2023     1  0 18:46 ?        00:00:00 ./ndbd -c alpha
jon    2024  2023  1 18:46 ?        00:00:00 ./ndbd -c alpha
jon    2124  1819  0 18:46 pts/2    00:00:00 grep --color=auto ndbd

Use the kill command to terminate the process with the indicated process ID, like this:

$> kill -9 2023

Verify that the angel process has been killed, and that only one of the two original ndbd processes remain, by issuing ps again, as shown here:

$> ps -ef | grep ndbd
jon    2024     1  1 18:46 ?        00:00:01 ./ndbd -c alpha
jon    2150  1819  0 18:47 pts/2    00:00:00 grep --color=auto ndbd

Now repeat this process from a login shell on host gamma, as shown here:

$> ps -ef | grep ndbd
jon       2066     1  0 18:46 ?        00:00:00 ./ndbd -c alpha
jon    2067  2066  1 18:46 ?        00:00:00 ./ndbd -c alpha
jon    3712  1704  0 18:46 pts/2    00:00:00 grep --color=auto ndbd

$> kill -9 2066

$> ps -ef | grep ndbd
jon    2067     1  1 18:46 ?        00:00:01 ./ndbd -c alpha
jon    2150  1819  0 18:47 pts/2    00:00:00 grep --color=auto ndbd

The wild cluster's data nodes are now ready for migration.

Kill and restart each management node process. When restarting ndb_mgmd, its configuration cache must be disabled; since this is enabled by default, you must start the management server with --config-cache=false, in addition to any other options that it was previously started with.

On Linux, we can once again use ps to obtain the information we need to accomplish this, this time in a shell on host alpha:

$> ps -ef | grep ndb_mgmd
jon   16005     1  1 18:46 ?        00:00:09 ./ndb_mgmd -f /etc/mysql-cluster/config.ini
jon   16401  1819  0 18:58 pts/2    00:00:00 grep --color=auto ndb_mgmd

The process ID is 16005, and the management node was started with the -f option (the short form for --config-file). First, terminate the management using kill, as shown here, with the process ID obtained from ps previously:

$> kill -9 16005

Verify that the management node process was killed, like this:

$> ps -ef | grep ndb_mgmd
jon    16532  1819  0 19:03 pts/2    00:00:00 grep --color=auto ndb_mgmd

Now restart the management node as described previously, with the same options that it was started with previously, and with the configuration cache disabled. Change to the directory where ndb_mgmd is located, and restart it, like this:

$> ./ndb_mgmd -f /etc/mysql-cluster/config.ini --config-cache=false
MySQL Cluster Management Server mysql-5.6.24-ndb-7.4.6
2013-12-06 19:16:08 [MgmtSrvr] INFO -- Skipping check of config directory since
config cache is disabled.

Verify that the process is running as expected, using ps:

$> ps -ef | grep ndb_mgmd
jon    17066  1  1 19:16 ?      00:00:01 ./ndb_mgmd -f
/etc/mysql-cluster/config.ini --config-cache=false
jon    17311  1819  0 19:17 pts/2  00:00:00 grep --color=auto ndb_mgmd

The management node is now ready for migration.

Any cluster processes that are under the control of a system boot process management facility, such as /etc/init.d on Linux systems or the Services Manager on Windows platforms, should be removed from this facility's control. Consult your system operating documentation for information about how to do this. Be sure not to stop any running cluster processes in the course of doing so.

It is highly recommended that you take a complete backup of the “wild” cluster before proceeding any further, using the ndb_mgm client's START BACKUP command:

ndb_mgm> START BACKUP
Waiting for completed, this may take several minutes
Node 5: Backup 1 started from node 1
Node 5: Backup 1 started from node 1 completed
 StartGCP: 1338 StopGCP: 20134
 #Records: 205044 #LogRecords: 10112
 Data: 492807474 bytes Log: 317805 bytes

It may require some time for the backup to complete, depending on the size of the cluster's data and logs. For START BACKUP command options and additional information, see Using The NDB Cluster Management Client to Create a Backup.