3.5.2.4 Testing and Migrating the Standalone Cluster

Testing and performing the migration of a standalone MySQL NDB Cluster into MySQL Cluster Manager consists of the following steps:

1. Perform a test run of the proposed import using import cluster with the --dryrun option. When this option is used, MySQL Cluster Manager checks for mismatched configuration attributes, missing or invalid processes or hosts, missing or invalid PID files, and other errors, and warns of any it finds, without actually performing any migration of processes or data (the step only works if you have created the mcmd user on the cluster's mysqld nodes):

   mcm> import cluster --dryrun newcluster;

2. If errors occur, correct them, and repeat the dry run shown in the previous step until it returns no more errors. The following list contains some common errors you may encounter, and their likely causes:

   • MySQL Cluster Manager requires a specific MySQL user and privileges to manage SQL nodes. If the mcmd MySQL user account is not set up properly, you may see No access for user..., Incorrect grants for user..., or possibly other errors. Follow the instructions given in this step in Section 3.5.2.1, “Preparing the Standalone Cluster for Migration” to remedy the issue.

   • As described previously, each cluster process (other than a process whose type is ndbapi) being brought under MySQL Cluster Manager control must have a valid PID file. Missing, misnamed, or invalid PID files can produce errors such as PID file does not exist for process..., PID ... is not running ..., and PID ... is type .... See Section 3.5.2.2, “Verify All Cluster Process PID Files”.

   • Process version mismatches can also produce seemingly random errors whose cause can sometime prove difficult to track down. Ensure that all nodes are supplied with the correct release of the MySQL NDB Cluster software, and that it is the same release and version of the software.

   • Each data node angel process in the standalone cluster must be killed prior to import. A running angel process can cause errors such as Angel process pid exists ... or Process pid is an angel process for .... Do the following when you see such errors:

     • For MySQL Cluster Manager 1.4.6 and earlier: See this step in Section 3.5.2.1, “Preparing the Standalone Cluster for Migration”.

     • For MySQL Cluster Manager 1.4.7 and later: Proceed to the next step if these are the only errors you get. The angel processes and the data node PIDs will be taken care of by the --remove-angel option used with the import cluster command at the last step of the import process.

   • The number of processes, their types, and the hosts where they reside in the standalone cluster must be reflected accurately when creating the target site, package, and cluster for import. Otherwise, you may get errors such as Process id reported # processes ..., Process id ... does not match configured process ..., Process id not configured ..., and Process id does not match configured process .... See Section 3.5.2.3, “Creating and Configuring the Target Cluster”.

   • Other factors that can cause specific errors include processes in the wrong state, processes that were started with unsupported command-line options (see Section 3.5.2.3, “Creating and Configuring the Target Cluster” for details) or without required options, and processes having the wrong process ID, or using the wrong node ID.

3. When import cluster --dryrun no longer warns of any errors, you can perform the import with the import cluster command, this time omitting the --dryrun option.

   For MySQL Cluster Manager 1.4.6 and earlier:

   mcm> import cluster newcluster;
   +-------------------------------+
   | Command result                |
   +-------------------------------+
   | Cluster imported successfully |
   +-------------------------------+
   1 row in set (5.58 sec)

   For MySQL Cluster Manager 1.4.7 and later: Use the --remove-angel option for the import cluster command, which kills the angel processes for the data nodes and adjusts the data nodes' PID files to contain the data node processes' own PIDs before importing the cluster:

   mcm> import cluster --remove-angel newcluster;
   +-------------------------------+
   | Command result                |
   +-------------------------------+
   | Cluster imported successfully |
   +-------------------------------+
   1 row in set (5.58 sec)

   You can check that the wild cluster has now been imported, and is now under management of MySQL Cluster Manager:

   mcm> show status -r newcluster;
   +--------+----------+----------------+---------+-----------+------------+
   | NodeId | Process  | Host           | Status  | Nodegroup | Package    |
   +--------+----------+----------------+---------+-----------+------------+
   | 50     | ndb_mgmd | 198.51.100.102 | running |           | newpackage |
   | 2      | ndbd     | 198.51.100.103 | running | 0         | newpackage |
   | 3      | ndbd     | 198.51.100.104 | running | 0         | newpackage |
   | 51     | mysqld   | 198.51.100.102 | running |           | newpackage |
   | 52     | ndbapi   | *              | added   |           |            |
   +--------+----------+----------------+---------+-----------+------------+
   5 rows in set (0.01 sec)