The importation process consists generally of following the steps listed here:
Create and configure in MySQL Cluster Manager a “target” cluster whose configuration matches that of the “wild” cluster.
Prepare the “wild” cluster for migration.
Verify PID files for cluster processes.
Perform a test run, and then execute the
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.
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 Cluster binaries, using the
add packagecommand. Use this command's
--basediroption to point to the correct location.
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 (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
MySQL Cluster Manager 1.3.1 and later: Use
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 that 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 perform
setcommands 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
--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 attribute values were copied correctly and with the correct scope. Correct any inconsistencies with the wild cluster's configuration using the appropriate
MySQL Cluster Manager 1.3.0: Since
import configis 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
setcommands 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 MySQL Cluster Configuration Files, and MySQL 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 VARIABLESstatement, and execute appropriate
setcommands for values differing from their defaults.
Prepare the “wild” cluster for migration
Create a MySQL user named
mcmdon each SQL node, and grant root privileges to this user.
Kill each data node angel process using your system's facility for doing so. Do not kill any non-angel data node daemons.
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=falseto deactivate it.
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.
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 MySQL Cluster Management Client to Create a Backup.
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 184.108.40.206, “Verify All Cluster Process PID Files”, for a more detailed explanation and examples.
Test and perform migration of “wild” cluster.
Perform a test run of the proposed migration using
import clusterwith the
--dryrunoption, which causes MySQL Cluster Manager to check for errors, but not actually migrate any processes or data.
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