The importing process consists generally of the steps listed here:
Prepare the “wild” cluster for migration.
Verify PID files for cluster processes.
Create and configure in MySQL Cluster Manager a “target” cluster whose configuration matches that of the “wild” cluster.
Perform a test run, and then execute the
This expanded listing breaks down each of the tasks just mentioned into smaller steps:
Prepare the “wild” cluster for migration
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.don 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:
NodeIDmust be assigned for every node.
DataDirmust 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.
Create a MySQL user named
mcmdon 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=falseoption, you will need to stop and restart it with that option, in addition to other options that it has been started with previously.
For MySQL Cluster Manager 1.4.6 and earlier: Kill each data node angel process using your system's facility for doing so. Do not kill any non-angel data node daemons.
(This step is unnecessary for MySQL Cluster Manager 1.4.7 and later.)
Verify cluster process PID files.
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.
See Section 220.127.116.11, “Verify All Cluster Process PID Files”, for a more detailed explanation and examples.
Create and configure “target” cluster under MySQL Cluster Manager control
Create a MySQL Cluster Manager site encompassing these hosts, using the
Add a MySQL Cluster Manager package referencing the MySQL NDB Cluster binaries, using the
add packagecommand. Use this command's
--basediroption to point to the location of the MySQL NDB Cluster installation directory.
Create the target cluster using the
create clustercommand, including the same processes and hosts used by the wild cluster. Use the command's
--importoption 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 clustercommand, you need not specify the node IDs for the processes in the
Also, this step may be split into a
create clustercommand followed by one or more
add processcommands (see Section 18.104.22.168, “Creating and Configuring the Target Cluster”).
import configto copy the wild cluster's configuration data into the target cluster. Use this command's
--dryrunoption (short form:
-y) to perform a test run that merely logs the configuration information the command copies when it is executed without the option.
mysqldprocesses in the wild cluster are running on ports other than the default, you must first perform
setcommands 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
--dryrunoption) 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
Test and perform migration of wild cluster.
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