3.5.1 Importing a Cluster Into MySQL Cluster Manager: Basic Procedure

The importation process consists generally of following the steps listed here:

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

2. Prepare the “wild” cluster for migration.

3. Verify PID files for cluster processes.

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; an example with more detail is also provided following the listing.

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

   1. Install MySQL Cluster Manager and start mcmd on all hosts; see Section 2.3, “MySQL Cluster Manager Installation”, for more information.

   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 Cluster binaries, using the add package command. Use this command's --basedir option to point to the correct location.

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

      Also, this step may be split into a create cluster command followed by one or more add process commands (see an example of such splitting in the description for the add process command).

   5. MySQL Cluster Manager 1.3.1 and later: 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 that 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 perform set commands to assign the correct port numbers for these in the target cluster. When all such processes are running on the correct ports, 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 attribute values were copied correctly and with the correct scope. Correct any inconsistencies with the wild cluster's configuration using the appropriate set commands.

      MySQL Cluster Manager 1.3.0: Since import config is not supported prior to the MySQL Cluster Manager 1.3.1 release, you must copy the wild cluster's configuration information to the target cluster manually, issuing set commands in the mcm client that duplicate the wild cluster's configuration in the target cluster, as discussed in the paragraphs immediately following.

      MySQL Cluster global configuration data is stored in a file on the management node host which is usually (but not always) named config.ini. This global configuration file uses INI format which makes it simple to read or parse. For more information about this file, see NDB Cluster Configuration Files, and NDB Cluster Configuration: Basic Example

      In addition, each mysqld process (SQL node) has its own configuration data in the form of system variables which are specific to that mysqld, and many of which can be changed at runtime. You can check their values using the SQL SHOW VARIABLES statement, and execute appropriate set commands for values differing from their defaults.

2. Prepare the “wild” cluster for migration

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

   2. Kill each data node angel process using your system's facility for doing so. Do not kill any non-angel data node daemons.

   3. Kill and restart each management node process. When restarting ndb_mgmd, be sure to do so with the configuration cache disabled. Since the configuration cache is enabled by default, you must start the management node with --config-cache=false to deactivate it.

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

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

3. 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 3.5.2.3, “Verify All Cluster Process PID Files”, for a more detailed explanation and examples.

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.