In our previous blog post we covered the deployment of four types of clustering/replication: MySQL Galera, MySQL master-slave replication, PostgreSQL replication set and MongoDB replication set. This should enable you to create new clusters with great ease, but what if you already have 20 replication setups deployed and wish to manage them with ClusterControl?
This blog post will cover adding existing infrastructure components for these four types of clustering/replication to ClusterControl and how to have ClusterControl manage them.
Adding an existing Galera cluster to ClusterControl
Adding an existing Galera cluster to ClusterControl requires: mysql user with the proper grants and a ssh user that is able to login (without password) from the ClusterControl node to your existing databases and clusters.
Install ClusterControl on a separate VM. Once it is up, open the two-step dialogue for adding an existing cluster. All you have to do is to add one of the Galera nodes and ClusterControl will figure out the rest:
After this behind the scenes, ClusterControl will connect to this host and detect all the necessary details for the full cluster and register the cluster in the overview.
Adding an existing MySQL master-slave to ClusterControl
Adding of an existing MySQL master-slave topology requires a bit more work than adding a Galera cluster. As ClusterControl is able to extract the necessary information for Galera, in the case of master-slave, you need to specify every host within the replication setup.
After this, ClusterControl will connect to every host, see if they are part of the same topology and register them as part of one cluster (or server group) in the GUI.
Adding an MySQL NDB Cluster to ClusterControl
Adding an existing MySQL NDB Cluster takes four steps in total: defining SSH, management nodes, data nodes and finally the MySQL nodes.
After this ClusterControl will connect to the management, data and MySQL nodes and see if they are indeed part of the cluster. Then it will register the cluster, start monitoring and managing it.
Adding an existing PostgreSQL replication set to ClusterControl
Similar to adding the MySQL master-slave above, the PostgreSQL replication set also requires to fill in all hosts within the same replication set.
After this, ClusterControl will connect to every host, see if they are part of the same topology and register them as part of the same group.
Adding an existing MongoDB replica set to ClusterControl
Adding an existing MongoDB replica set is just as easy as Galera: just one of the hosts in the replica set needs to be specified with its credentials and ClusterControl will automatically discover the other nodes in the replica set.
Adding an existing MongoDB sharded cluster set to ClusterControl
Adding an existing MongoDB sharded cluster is almost as easy as a MongoDB replica set: all shard routers in the cluster need to be specified with its credentials, and ClusterControl will automatically discover all shards and replica sets in the cluster.
Expanding your existing infrastructure
After adding the existing databases and clusters, they now have become manageable via ClusterControl and thus we can scale out our clusters.
For MySQL, MongoDB and PostgreSQL replication sets, this can easily be achieved via the same way we showed in our previous blogpost: simply add a node and ClusterControl will take care of the rest.
For Galera, there is a bit more choice. The most obvious choice is to add a (Galera) node to the cluster by simply choosing “add node” in the cluster list or cluster overview. Expanding your Galera cluster this way should happen with increments of two to ensure your cluster always can have majority during a split brain situation.
Alternatively you could add a replication slave and thus create asynchronous slave in your synchronous cluster that looks like this:
Adding a slave node blindly under one of the Galera nodes can be dangerous since if this node goes down, the slave won’t receive updates anymore from its master. We blogged about paradigm earlier and you can read how to solve this in this blog post:
We showed you how easy it is to add existing databases and clusters to ClusterControl, you can literally add clusters within minutes. So nothing should hold you back from using ClusterControl to manage your existing infrastructure. If you have a large infrastructure, the addition of ClusterControl will give you more overview and save time in troubleshooting and maintaining your clusters.
Now the challenge is how to leverage ClusterControl to keep track of key performance indicators, show the global health of your clusters and proactively alert you in time when something is predicted to happen. And that’s the subject we'll cover next time.
Read also in the same series: Become a ClusterControl DBA - Deploying your Databases and Clusters
Download our whitepaper on upgrading to MySQL 5.7
Upgrading to a new major version involves risk, and it is important to plan the whole process carefully. In this whitepaper, we look at the important new changes in MySQL 5.7 and show you how to plan the test process. We then look at how to do a live system upgrade without downtime. For those who want to avoid connection failures during slave restarts and switchover, this document goes even further and shows you how to leverage ProxySQL to achieve a graceful upgrade process.