MySQL Cluster Manager is designed primarily for managing MySQL Cluster deployments that are created by it, rather than introducing it into existing MySQL Cluster instances that are already in use. Currently, there is no integrated functionality for importing an existing MySQL Cluster into MySQL Cluster Manager, and it is not currently possible to perform this task without shutting down and restarting the cluster.
This section outlines a suggested procedure for importing an existing MySQL Cluster manually into MySQL Cluster Manager. It is in many ways similar to creating a new cluster in MySQL Cluster Manager, but differs in how initial configuration of the cluster is carried out. The importation procedure includes the following steps:
MySQL Cluster Manager agent installation and startup. Deploy the MySQL Cluster Manager software distribution on the cluster hosts, perform any necessary agent configuration, then start the MySQL Cluster Manager agent, as described in Chapter 2, MySQL Cluster Manager Installation, Configuration, Cluster Setup. MySQL Cluster Manager agent processes must be running on all hosts where cluster processes are running before proceeding any further.
MySQL Cluster Manager client session startup. Start a MySQL Cluster Manager client session; you can connect to a MySQL Cluster Manager agent process running on any of the cluster hosts (see Section 2.6, “Starting the MySQL Cluster Manager Client”).
Management site definition.
Define a MySQL Cluster Manager site that includes all hosts in the
cluster, using the
create site command.
See Section 3.2.1, “The
create site Command”, for syntax and
MySQL Cluster software package registration.
Register a package referencing the location of the MySQL
Cluster software on each cluster host using one or more
add package commands (see
Section 3.3.1, “The
add package Command”). Be sure to specify the
actual location of the MySQL Cluster software on each
Define a cluster in MySQL Cluster Manager using the
cluster command (see
Section 3.4.1, “The
create cluster Command”), making sure to
reference all cluster processes and hosts when doing so.
When creating a cluster, MySQL Cluster Manager automatically assigns
sequential node IDs (beginning with
in the order specified by the process host list used in
create cluster command. If the node
IDs in the existing cluster are not purely sequential
(without any gaps between consecutive node IDs, or if the
node IDs taken in order do not begin with
Workaround for non-sequential node IDs,
There is no facility in MySQL Cluster Manager 1.1.6 for importing
configuration data from an existing cluster; therefore,
this step must be performed manually. Consolidate all
configuration information from the existing cluster; this
includes parameters set in the cluster's
config.ini file (or files),
mysqld options set in
files, and any arguments that were passed to MySQL Cluster
executables on the command line when invoking them. For
most attributes, you need to execute a
set statement that is equivalent to a
setting in a
my.cnf file. Suppose that the
config.ini file contains an
[ndbd default] setting such as this
DataMemory = 2400G
In this case, you would need to execute this
set command in the MySQL Cluster Manager client:
DataMemory:ndbd = 2400G;
More generally, if you have a
file entry in a
[ section of
process_type is the name of a
MySQL Cluster process (
api) then you can use the following
regular expression to derive an equivalent MySQL Cluster Manager client
set statement from it.
In the case of
[api] sections of the
config.ini file, you also need to
determine whether the eqivalent
statement should be applied using
ndbapi as the
Some attributes such as
Id are read-only
HostName is already defined by
create site and
cluster; node IDs are determined by MySQL Cluster Manager and
cannot be overridden).
In addition, you should always keep in mind that MySQL
Cluster and MySQL Cluster Manager do not always use the same default
values for parameters and their corresponding attributes.
This is crucial especially in the case of
DataDirectory, since the data nodes
must be able to read these following the importation to
acess the cluster's data. See
Migrating data directories.
Migrating data directories. Do not start the new cluster before making sure that you have configured all processes in the new cluster to use the same data directories used by all nodes in the original cluster. If the data nodes of the imported cluster are not configured to read the original data directories, the imported cluster will be unable to access the original cluster's data.
Keep in mind that the default value used by MySQL Cluster Manager for the
is not the same as the default set by
MySQL Cluster or MySQL Server, as described here:
For a management node or data node, MySQL Cluster uses the
process working directory as the
DataDirectory, which means that, if the
DataDirectory was not set explicitly to
an absolute path in the original cluster's
config.ini file, the arguments with
which which the cluster executable was invoked and the
location it was started from may also affect this value. For
a mysqld processes, the default location
of the data directory depends on the method that was used to
install the mysqld binary (see
Installation Layouts, for more
information); this value can also be overridden from the
command line or in the mysqld's
Due to these many factors which can affect the locations of
the nodes' data directories, you should always verify
the true location of the original data directory for each
node in the original cluster by inspection of the file
system, then set
MySQL Cluster Manager) for each node in the new cluster explicitly.
config.ini setting that applies
to a single process of type
process_type and having node ID
node_id, you can use the
following regular expression to generate a
set statement that applies the same
setting to the same cluster process:
Cluster shutdown and startup. Once you have finished migrating the cluster configuration data, you are ready to restart the Cluster under control of MySQL Cluster Manager. This requires a system restart; that is, the cluster must be completely shut down, then restarted.
Before proceding with this step, make certain that the configuration you have set up for the cluster in MySQL Cluster Manager is correct. In particular, make sure that the node ID and data directory are the same for each node, in both the original configuration and the new configuration you have just created using MySQL Cluster Manager. Also verify that you have set any attributes that cannot be changed once the cluster has been started for the first time.
Shutting down the cluster consists of the following two steps:
Issue an ndb_mgm
SHUTDOWN command. You can do this
either in an ndb_mgm client session,
or by invoking ndb_mgm from the
system shell, like this:
ndb_mgm -e "SHUTDOWN"
(Here, the quotation marks are optional.) For more information, see Commands in the MySQL Cluster Management Client.
Stop all mysqld processes that were connected to the cluster. To do this, issue the following command on each host running an SQL node:
mysqladmin -uroot shutdown
If the MySQL
root user password has
been set, you can supply it when invoking the command,
mysqladmin -uroot -p
If more than one mysqld process is
running on the same host, each process must use a
different port. In such cases, you must invoke
mysqladmin separately for each
mysqld process, specifying the port
each time with the
-P option, similar to what is shown
./mysqladmin -uroot -P3306 shutdown110919 12:41:26 mysqld_safe mysqld from pid file /usr/local/mysql/data/m1.pid ended + Done ./mysqld_safe --port=3306 --pid-file=/usr/local/mysql/data/m1.pid shell>
./mysqladmin -uroot -P3307 shutdown110919 12:41:26 mysqld_safe mysqld from pid file /usr/local/mysql/data/m2.pid ended + Done ./mysqld_safe --port=3307 --pid-file=/usr/local/mysql/data/m2.pid
See mysqladmin — Client for Administering a MySQL Server, for more information.
Once all cluster processes have stopped, you can start the
cluster using MySQL Cluster Manager. Start the MySQL Cluster Manager agent and a MySQL Cluster Manager
client session if these are not already running, then issue
start cluster command in the MySQL Cluster Manager
client (substituting the name of the imported cluster for
start cluster mycluster;
Once the cluster has started successfully, the importation process is complete, and you should be able from this point onwards to manage the cluster as if you had actually created it using MySQL Cluster Manager.
Workaround for non-sequential node IDs.
If the node IDs in the existing cluster are not strictly
consecutive, beginning with
1, this causes
problems when trying to import it into MySQL Cluster Manager because
MySQL Cluster Manager's internal representation of the cluster requires
them to be. One way to surmount this issue is to insert
ndbapi entries into
the process hosts list used in the
cluster statement. The following example illustrates
how this can be done.
Suppose the original cluster has 8 nodes that use the process types, the node IDs, and hosts shown in the following table:
|Process type||Node ID||Host|
Assuming that a package named
already been registered, a cluster named
mycluster having the preceding distribution
of nodes on hosts can be created in the mcm
client like this:
create cluster -P mypackage -R->
However, the node IDs generated by this statement are the
8. In order to
preserve the original numbering, we need to account for the
11. The following
version of the command has been modified such that
ndbapi process entries
have been inserted into the list of processes on hosts; the
“extra” entries are shown in a contrasting style:
create cluster -P mypackage -R->
Since MySQL Cluster Manager does not expect to execute
processes itself, the host names used with these
“dummy” items are arbitrary; the only requirement
for these is that they are names of hosts belonging to the