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
create site command.
Use this command's
to specify that the cluster is a target for import.
Add a MySQL Cluster Manager package referencing the MySQL Cluster
binaries, using the
package command. Use this command's
--basedir option to point to the
Create the target cluster including at least some of the same processes and hosts used by the wild cluster (and no other processes or hosts).
If needed, add any remaining processes and hosts from
the wild cluster not included in the previous step using
one or more
MySQL Cluster Manager 1.3.1 and later: Use
import config to copy
the 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.
mysqld processes in the wild cluster
are running on ports other than the default, you must
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
config (without the
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
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
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
statement, and execute appropriate
set commands for values
differing from their defaults.
Prepare the “wild” cluster for migration
Create a MySQL user named
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
Any cluster processes that are under the control of the
system's boot-time process management facility,
/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 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 220.127.116.11, “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
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
cluster, but without the