4.5.1 Importing a Cluster Into MySQL Cluster Manager: Basic Procedure

The importing process consists generally of the steps listed here:

1. Prepare the “wild” cluster for migration.

2. Verify PID files for cluster processes.

3. Create and configure in MySQL Cluster Manager a “target” cluster whose configuration matches that of the “wild” cluster.

4. Perform a test run, and then execute the import cluster command.

This expanded listing breaks down each of the tasks just mentioned into smaller steps:

1. Prepare the “wild” cluster for migration

   1. 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.

   2. 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.

   3. 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.

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

   5. 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.

2. Verify cluster process PID files.

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

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

   See Section 4.5.2.2, “Verify All Cluster Process PID Files”, for a more detailed explanation and examples.

3. Create and configure “target” cluster under MySQL Cluster Manager control

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

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

   3. 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.

   4. 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”).

   5. 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.

4. Test and perform migration of wild cluster.

   1. 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.

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

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