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
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.
Create and configure “target” cluster under MySQL Cluster Manager control
Install MySQL Cluster Manager and start mcmd on all hosts; see Section 2.3, “MySQL Cluster Manager Installation”, for more information.
Create a MySQL Cluster Manager site encompassing these hosts, using the
create site
command.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.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 thecreate cluster
command.Also, this step may be split into a
create cluster
command followed by one or moreadd process
commands (see an example of such splitting in the description for theadd process
command).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
ormysqld
processes in the wild cluster are running on ports other than the default, you must performset
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 executeimport 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 appropriateset
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, issuingset
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 ExampleIn 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 appropriateset
commands for values differing from their defaults.
Prepare the “wild” cluster for migration
Create a MySQL user named
mcmd
on 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=false
to deactivate it.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.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.
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 3.5.2.3, “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 cluster
with the--dryrun
option, 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--dryrun
option.