Database Clustering Tutorial 11 – ClusterControl Scripting With Developer Studio

We are finally to the cool part of the series!

ClusterControl allows us to do custom monitoring and automation through scripts that can be run regularly. These scripts are run through a tool called Developer Studio.

To begin looking at this, open your cluster and when you are in the cluster overview, hover over Manage and click Developer Studio.

From here you will see a ton of scripts that were already built into ClusterControl.

For example, s9s -> mysql -> schema -> schema_check_nopk.js.

In schema_check_nopk.js, you will find a comment describing what it does.

Now let’s look at the language used.


The language used here is an example of a domain specific language (DSL), which is basically a language that has absolutely no value outside of the application that it is in. Fortunately, this one is very similar to JavaScript, so it’s nothing too crazy. It even ends with .JS.

Script Categories

There are basically two categories of scripts:

  1. Those that get ran on a schedule (called advisors).
  2. Those you can run as needed. (This could simplify a process that woud take a while to do by hand).


Now let’s take a look at the advisors.

Click the little Advisors button.

This will bring up a menu which shows that these advisors are run on a regular basis. You can scroll down to see the one I just showed you and see that it is being ran every 20 minutes. You can see that these scripts are used to monitor the health of your database and it is all automated because they can be scheduled.

Script Breakdown

I am going to break down one of these scripts in order to go through the process of writing a script. This is going to be from a super high level but hopefully it will get you started and help you understand how this works.

Let’s take a look at s9s -> mysql -> programs -> change_user_password.js

The first thing you should notice is this:

Including this file allows us to connect to and query the database nodes. This is a file that you can view if you just follow the path.


The next section are these variables in all caps. For example:

I am guessing they are in all caps to treat them as if they were constants that are going to be referenced throughout the script. To appropriately use this script, you plug in a username and password, and then click compile and run.

Function Main

The function main is the part of the script that gets run line by line.

The first line in this script has the hosts variable cluster::mySqlNodes.

This will get all of the nodes in our cluster that are running mysql. We can then loop over them with this hosts variable to change the password for every node.

You can also use cluster::galeraNodes() here instead.

This is a little different but in our situation it will work the same. If you remember, a while ago I mentioned that Galera does synchronous replication. Well, this function will get all nodes that are part of Galera, whereas the mySqlNodes will get all nodes including any additional ones we might have added that are replicating asynchronously.

For Loop

The next section is a for loop which is used to iterate over all of the nodes.

The code inside of the for loop is going to be ran for each node. The very first thing inside of the for loop is getting a reference to that individual host rather than all of them. The first iteration idx is going to be zero, and the second time around idx will be 1. Thus, we can access different nodes each iteration.

Although I don’t understand them in their entirety, the next two lines are important because they allow us to later run a conditional on whether we can successfully connect to the database:

So if this connected variable evaluates as true, we are good. If not, we’re doomed.

Once we are connected to that node, we update the password. If there are any errors, we print those and stop running code. If we are error free, the success message is displayed and we move on to the next database node.


Now that you have a better understanding of writing scripts, maybe you can try writing one to be ran on a regular basis. There are two example articles on the Severalnines website that will guide you through a more advanced script that can be used to automatically monitor your database for you:

 Further Study

  • Read the two Severalnines articles mentioned above to get a more in depth look at examples of working with Developer Studio.

Leave a Reply

Your email address will not be published. Required fields are marked *