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 3.3, “Starting the MySQL Cluster Manager Client”).
Management site definition.
Define a MySQL Cluster Manager site that includes all hosts in the
cluster, using the
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. Be
sure to specify the actual location of the MySQL Cluster
software on each host.
Define a cluster in MySQL Cluster Manager using the
create cluster command,
making sure to reference all cluster processes and hosts
when doing so.
Node IDs generated by MySQL Cluster Manager.
When creating a cluster, MySQL Cluster Manager automatically assigns
sequential node IDs, in the order specified by the process
host list used in the
cluster command, using the ranges listed here
for each type of process:
Data nodes: 1-48
Management nodes: 48-49
SQL/API nodes: 50-255
Processes of each type are assigned consecutive IDs from the beginning of the range indicated for that type.
There is no facility in MySQL Cluster Manager 1.2.3 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
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
set statement should be
ndbapi as the
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:
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
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.