Documentation Home
MySQL Cluster Manager 1.3 User Manual
Related Documentation Download this Manual

3.5.2.2 Preparing the Standalone Cluster for Migration

The next step in the import process is to prepare the wild cluster for migration. This requires creating an mcmd user account with root privileges on all hosts in the cluster; killing any data node angel processes that may be running; restarting all management nodes without configuration caching; removing cluster processes from control by any system service management facility. More detailed information about performing these tasks is provided in the remainder of this section.

Note

Before proceeding with any migration, the taking of a backup using the ndb_mgm client's BACKUP command is strongly recommended.

  1. MySQL Cluster Manager acts through a MySQL user named mcmd on each SQL node. It is therefore necessary to create this user and grant root privileges to it. To do this, log in to the SQL node running on host delta and execute in the mysql client the SQL statements shown here:

    CREATE USER 'mcmd'@'delta' IDENTIFIED BY 'super';
    
    GRANT ALL PRIVILEGES ON *.* TO 'mcmd'@'delta' WITH GRANT OPTION;

    Keep in mind that, if the wild cluster has more than one SQL node, you must create the mcmd user on every one of these nodes.

  2. Kill each data node angel process using the system's facility for doing so. Do not kill any non-angel data node daemons. On a Linux system, you can identify angel processes by matching their process IDs with the owner IDs of the remaining ndbd processes in the output of ps executed on host beta of the example cluster, as shown here, with the relevant process IDs shown in emphasized text:

    shell> ps -ef | grep ndbd
    jon       2023     1  0 18:46 ?        00:00:00 ./ndbd -c alpha
    jon    2024  2023  1 18:46 ?        00:00:00 ./ndbd -c alpha
    jon    2124  1819  0 18:46 pts/2    00:00:00 grep --color=auto ndbd

    Use the kill command to terminate the process with the indicated process ID, like this:

    shell> kill -9 2023

    Verify that the angel process has been killed, and that only one of the two original ndbd processes remain, by issuing ps again, as shown here:

    shell> ps -ef | grep ndbd
    jon    2024     1  1 18:46 ?        00:00:01 ./ndbd -c alpha
    jon    2150  1819  0 18:47 pts/2    00:00:00 grep --color=auto ndbd

    Now repeat this process from a login shell on host gamma, as shown here:

    shell> ps -ef | grep ndbd
    jon       2066     1  0 18:46 ?        00:00:00 ./ndbd -c alpha
    jon    2067  2066  1 18:46 ?        00:00:00 ./ndbd -c alpha
    jon    3712  1704  0 18:46 pts/2    00:00:00 grep --color=auto ndbd
    
    shell> kill -9 2066
    
    shell> ps -ef | grep ndbd
    jon    2067     1  1 18:46 ?        00:00:01 ./ndbd -c alpha
    jon    2150  1819  0 18:47 pts/2    00:00:00 grep --color=auto ndbd

    The wild cluster's data nodes are now ready for migration.

  3. Kill and restart each management node process. When restarting ndb_mgmd, its configuration cache must be disabled; since this is enabled by default, you must start the management server with --config-cache=false, in addition to any other options that it was previously started with.

    Caution

    Do not use 0 or OFF for the value of the --config-cache option when restarting ndb_mgmd in this step. Using either of these values instead of false at this time causes the migration of the management node process to fail at later point in the importation process.

    On Linux, we can once again use ps to obtain the information we need to accomplish this, this time in a shell on host alpha:

    shell> ps -ef | grep ndb_mgmd
    jon   16005     1  1 18:46 ?        00:00:09 ./ndb_mgmd -f /etc/mysql-cluster/config.ini
    jon   16401  1819  0 18:58 pts/2    00:00:00 grep --color=auto ndb_mgmd

    The process ID is 16005, and the management node was started with the -f option (the short form for --config-file). First, terminate the management using kill, as shown here, with the process ID obtained from ps previously:

    shell> kill -9 16005

    Verify that the management node process was killed, like this:

    shell> ps -ef | grep ndb_mgmd
    jon    16532  1819  0 19:03 pts/2    00:00:00 grep --color=auto ndb_mgmd

    Now restart the management node as described previously, with the same options that it was started with previously, and with the configuration cache disabled. Change to the directory where ndb_mgmd is located, and restart it, like this:

    shell> ./ndb_mgmd -f /etc/mysql-cluster/config.ini --config-cache=false
    MySQL Cluster Management Server mysql-5.6.24-ndb-7.4.6
    2013-12-06 19:16:08 [MgmtSrvr] INFO -- Skipping check of config directory since
    config cache is disabled.

    Verify that the process is running as expected, using ps:

    shell> ps -ef | grep ndb_mgmd
    jon    17066  1  1 19:16 ?      00:00:01 ./ndb_mgmd -f
    /etc/mysql-cluster/config.ini --config-cache=false
    jon    17311  1819  0 19:17 pts/2  00:00:00 grep --color=auto ndb_mgmd

    The management node is now ready for migration.

    Important

    While our example cluster has only a single management node, it is possible for a MySQL Cluster to have more than one. In such cases, you must stop and restart each management node process as just described in this step.

  4. Any cluster processes that are under the control of a system boot process management facility, such as /etc/init.d on Linux systems or the Services Manager on Windows platforms, should be removed from this facility's control. Consult your system operating documentation for information about how to do this. Be sure not to stop any running cluster processes in the course of doing so.

  5. It is highly recommended that you take a complete backup of the wild cluster before proceeding any further, using the ndb_mgm client's START BACKUP command:

    ndb_mgm> START BACKUP
    Waiting for completed, this may take several minutes
    Node 5: Backup 1 started from node 1
    Node 5: Backup 1 started from node 1 completed
     StartGCP: 1338 StopGCP: 20134
     #Records: 205044 #LogRecords: 10112
     Data: 492807474 bytes Log: 317805 bytes

    It may require some time for the backup to complete, depending on the size of the cluster's data and logs. For START BACKUP command options and additional information, see Using The NDB Cluster Management Client to Create a Backup.