How to Migrate ClusterControl to a New Server

Ashraf Sharif


As your needs change, and you start managing more database instances or larger centralized backups with ClusterControl, you might find that your controller host is over-utilized. Or you might need to migrate your infrastructure to the cloud. If this is the case, you can migrate to another instance.

In this blog post, we’ll show you how to migrate ClusterControl to another server. Here is our architecture diagram:

We would like to migrate an existing ClusterControl instance to another server with bigger disk space and RAM. The ClusterControl node currently monitors a two-node Galera cluster, stores centralized database backups under /root/backups directory, runs garbd (Galera arbitrator daemon) as well as an HAProxy instance to load balance connections to the Galera nodes.

ClusterControl Migration

Migrating your ClusterControl instance should not have any detrimental effect on your database cluster. Note the list of things that need to be transferred to the new server:

  • Databases with monitoring data and cluster information – cmon and dcps
  • ClusterControl API token
  • MySQL grants for user cmon
  • ClusterControl files – ClusterControl binaries, CMONAPI and ClusterControl UI
  • If you have garbd, HAproxy or Keepalived running on the ClusterControl node, you need to reinstall (explicitly remove and then install) them again in the new server by using Cluster Actions > Add Load Balancer.
  • If you store your backups on ClusterControl node, you have to manually transfer them to the exact location on the new ClusterControl server

ClusterControl requires the new server to run on the same operating system family (Redhat-based or Debian-based). Further tweaking on the MySQL server running on ClusterControl host can help to improve the overall performance of ClusterControl after migration is completed.

Install new ClusterControl and merge data from old server

This is the recommended way to migrate, as it installs the latest version of ClusterControl and loads your settings and historical data. The steps include:

  1. Install ClusterControl on the new server by using script
  2. Export the cmon and dcps databases using mysqldump
  3. Copy the old CMON configuration files: /etc/cmon.cnf and /etc/cmon.d/* (if any)
  4. Replace any occurrences of old IP address in the new server
  5. Restore the cmon and dcps databases
  6. Transfer CMONAPI token value
  7. Setup passwordless SSH by copying the SSH key to all nodes
  8. Setup grant for cmon user on all MySQL nodes

Migration steps

1. On new server, install ClusterControl by using the installation script. This will install and configure all dependencies like MySQL, PHP and Apache web server:

root@newserver$ wget
root@newserver$ chmod u+x
root@newserver$ ./

** In the installation wizard, specify same password for MySQL root and cmon password with the old server.

2. Once the installation is done, stop the CMON service on the old server and the new server to get consistent data:

root@oldserver$ service cmon stop
root@newserver$ service cmon stop

3. On the existing server, take a MySQL dump of cmon and dcps databases from the current server with –replace, –no-create-info and –skip-triggers options:

root@oldserver$ mysqldump -uroot -p --databases cmon dcps --replace --no-create-info --skip-triggers > backup.sql

4. Copy the old CMON configuration file to the new server. Depending on your cluster, you might have configuration files under /etc/cmon.d/ directory. Copy all of them directly onto the new server:

root@oldserver$ scp /etc/cmon.cnf [email protected]:/etc
root@oldserver$ scp /etc/cmon.d/* [email protected]/etc/cmon.d/

5. Replace any existence of the old IP address in the CMON configuration file:

root@newserver$ sed -i 's|||g' /etc/cmon.cnf

** If you have CMON configuration file(s) under /etc/cmon.d/ directory, repeat above step for each configuration file.

6. On the new server, copy the MySQL dump file, replace the the old IP address and restore it onto the MySQL server:

root@newserver$ scp [email protected]:~/backup.sql .
root@newserver$ sed -i 's|||g' backup.sql
root@newserver$ mysql -uroot -p < backup.sql

7. Retrieve the CMON_TOKEN value from the old server and specify that information on the new server’s CMONAPI bootstrap file under $wwwroot/cmonapi/config/bootstrap.php on line 8:

root@oldserver$ grep CMON_TOKEN /var/www/html/cmonapi/config/bootstrap.php | awk {'print $2'} | tr -d ");'"
root@newserver$ vim /var/www/html/cmonapi/config/bootstrap.php

And replace the CMON_TOKEN value as per below:

define('CMON_TOKEN', '118653f268b218b015378f43e8e0c2b40a4c8d85');

8. Setup passwordless SSH to all nodes (including the ClusterControl node) on the new server:

root@newserver$ ssh-keygen -t rsa # Press enter on all prompts
root@newserver$ ssh-copy-id -i ~/.ssh/id_rsa
root@newserver$ ssh-copy-id -i ~/.ssh/id_rsa
root@newserver$ ssh-copy-id -i ~/.ssh/id_rsa

** If you are running ClusterControl as sudoer, ensure you enter the sudo user’s environment before running the above steps. The -i option should take the same key location as used in the old server.

9. Grant the new ClusterControl IP address on all MySQL database nodes:

db1> UPDATE mysql.user SET Host = '' WHERE Host = '';

db2> UPDATE mysql.user SET Host = '' WHERE Host = '';

10. Start CMON service:

root@newserver$ service cmon start

If you have garbd, HAproxy or Keepalived running on the ClusterControl node, go to Cluster Actions > Add Load Balancer to explicitly remove and install them again. If you store backups on the ClusterControl node, do not forget to copy them over to the new server and keep the same path.

Migration is now completed.


Verifying ClusterControl on the new server

Ensure you are able to login to ClusterControl on new server using the same username and password, and verify the cluster configuration. Things to look at:

  • Nodes tab
  • Backups > Schedules and Reports
  • Manage > Hosts
  • Manage > Processes
  • Everything under Settings tab

If you look into the Cluster Load graph, you should notice a slight gap in monitoring data due to the ClusterControl downtime during the migration. This indicates the previous monitoring data in the old server is correctly transferred to the new server:

Examine the CMON log file output under ClusterControl > Logs > CMON Logs and look for ERROR or WARNING debug level (if any):

Need help? Don’t hesitate to contact us via our support portal. Happy migration!

Subscribe below to be notified of fresh posts