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 packagecommands. Be sure to specify the actual location of the MySQL Cluster software on each host.
Cluster definition. Define a cluster in MySQL Cluster Manager using the
create clustercommand, 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
create clustercommand, 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.
Cluster configuration. There is no facility in MySQL Cluster Manager 1.2.4 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.inifile (or files), mysqld options set in
my.inifiles, 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
setstatement that is equivalent to a setting in a
my.cnffile. Suppose that the
config.inifile contains an
[ndbd default]setting such as this one:
DataMemory = 2400G
In this case, you would need to execute this
setcommand in the MySQL Cluster Manager client:
mcm> set DataMemory:ndbd = 2400G;
More generally, if you have a
my.cnffile entry in a
process_typeis the name of a MySQL Cluster process (
api) then you can use the following regular expression to derive an equivalent MySQL Cluster Manager client
setstatement from it.
s/(\w*)\s?=\s?(\w*)/set $1:process_type = $2;/
In the case of
[api]sections of the
config.inifile, you also need to determine whether the eqivalent
setstatement should be applied using
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
DataDirectorywas not set explicitly to an absolute path in the original cluster's
config.inifile, 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
DataDirectory(using MySQL Cluster Manager) for each node in the new cluster explicitly.
config.inisetting that applies to a single process of type
process_typeand having node ID
node_id, you can use the following regular expression to generate a
setstatement that applies the same setting to the same cluster process:
s/(\w*)\s?=\s?(\w*)/set $1:process_name:node_id = $2;/
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.Important
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:
shell> 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:
shell> mysqladmin -uroot shutdown
If the MySQL
rootuser password has been set, you can supply it when invoking the command, like this:
shell> mysqladmin -uroot -prootpassword shutdown
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
-Poption, similar to what is shown here:
shell> ./mysqladmin -uroot -P3306 shutdown 110919 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 shutdown 110919 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 a
start clustercommand in the MySQL Cluster Manager client (substituting the name of the imported cluster for
mcm> 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.