In the past five posts of the blog series, we covered deployment of clustering/replication (MySQL / Galera, MySQL Replication, MongoDB & PostgreSQL), management & monitoring of your existing databases and clusters, performance monitoring and health, how to make your setup highly available through HAProxy and MaxScale and in the last post, how to prepare yourself for disasters by scheduling backups.
With ClusterControl 1.2.11, we made major enhancements to the database configuration manager. The new version allows changing of parameters on multiple database hosts at the same time and, if possible, changing their values at runtime.
We featured the new MySQL Configuration Management in a Tips & Tricks blog post, but this blog post will go more in depth and cover Configuration Management within ClusterControl for MySQL, PostgreSQL and MongoDB.
Cluster Control Configuration management
The configuration management interface can be found under Manage > Configurations. From here, you can view or change the configurations of your database nodes and other tools that ClusterControl manages. ClusterControl will import the latest configuration from all nodes and overwrite previous copies made. Currently there is no historical data kept.
If you’d rather like to manually edit the config files directly on the nodes, you can re-import the altered configuration by pressing the Import button.
And last but not least: you can create or edit configuration templates. These templates are used whenever you deploy new nodes in your cluster. Of course any changes made to the templates will not retroactively applied to the already deployed nodes that were created using these templates.
MySQL Configuration Management
As previously mentioned, the MySQL configuration management got a complete overhaul in ClusterControl 1.2.11. The interface is now more intuitive. When changing the parameters ClusterControl checks whether the parameter actually exists. This ensures your configuration will not deny startup of MySQL due to parameters that don’t exist.
From Manage -> Configurations, you will find an overview of all config files used within the selected cluster, including MaxScale nodes.
We use a tree structure to easily view hosts and their respective configuration files. At the bottom of the tree, you will find the configuration templates available for this cluster.
Changing parameters
Suppose we need to change a simple parameter like the maximum number of allowed connections (max_connections), we can simply change this parameter at runtime.
First select the hosts to apply this change to.
Then select the section you want to change. In most cases, you will want to change the MYSQLD section. If you would like to change the default character set for MySQL, you will have to change that in both MYSQLD and client sections.
If necessary you can also create a new section by simply typing the new section name. This will create a new section in the my.cnf.
Once we change a parameter and set its new value by pressing “proceed”, ClusterControl will check if the parameter exists for this version of MySQL. This is to prevent any non-existent parameters to block the initialization of MySQL on the next restart.
When we press “proceed” for the max_connections change, we will receive a confirmation that it has been applied to the configuration and set at runtime using SET GLOBAL. A restart is not required as max_connections is a parameter we can change at runtime.
Now suppose we want to change the bufferpool size, this would require a restart of MySQL before it takes effect:
And as expected the value has been changed in the configuration file, but a restart is required. You can do this by logging into the host manually and restarting the MySQL process. Another way to do this from ClusterControl is by using the Nodes dashboard.
Restarting nodes in a Galera cluster
You can perform a restart per node by selecting “Shutdown Node” and pressing the “Execute” button.
This will stop MySQL on the host but depending on your workload and bufferpool size this could take a while as MySQL will start flushing the dirty pages from the InnoDB bufferpool to disk. These are the pages that have been modified in memory but not on disk.
Once the host has stopped MySQL the “Start Node” button should become available:
Make sure you leave the “initial” checkbox unchecked in the confirmation:
When you select “initial start” on a Galera node, ClusterControl will empty the MySQL data directory and force a full copy this way. This is, obviously, unncessary for a configuration change.
Restarting nodes in a MySQL master-slave topologies
For MySQL master-slave topologies you can’t just restart node by node. Unless downtime of the master is acceptable, you will have to apply the configuration changes to the slaves first and then promote a slave to become the new master.
You can go through the slaves one by one and execute a “Shutdown node” on them and once MySQL has stopped execute the “Start node” again. Again make sure you leave the “initial” checkbox unchecked in the confirmation:
Just like the “Start Node” with Galera clusters, “initial start” will delete the MySQL data directory and copy the data from the master.
After applying the changes to all slaves, promote a slave to become the new master:
After the slave has become the new master, you can shutdown and start the old master node to apply the change.
Importing configurations
Now that we have applied the change directly on the database, as well as the configuration file, it will take until the next configuration import to see the change reflected in the configuration stored in ClusterControl. If you are less patient, you can schedule an immediate configuration import by pressing the “Import” button.
PostgreSQL Configuration Management
For PostgeSQL, the Configuration Management works a bit different from the MySQL Configuration Management. In general, you have the same functionality here: change the configuration, import configurations for all nodes and define/alter templates.
The difference here is that you can immediately change the whole configuration file and write this configuration back to the database node.
If the changes made requires a restart, a “Restart” button will appear that allows you to restart the node to apply the changes.
MongoDB Configuration Management
The MongoDB Configuration Management works similar to the PostgreSQL Configuration Management: you can change the configuration, import configurations for all nodes and alter templates.
Changing the configuration is, just like PostgreSQL, altering the whole configuration:
The biggest difference for MongoDB is that there are four configuration templates predefined:
The reason for this is that we support different types of MongoDB clusters, and this gets reflected in the cluster configurations.
Final thoughts
In this blog post we learned about how to manage, alter and template your configurations in ClusterControl. Changing the templates can save you a lot of time when you have deployed only one node in your topology. As the template will be used for new nodes, this will save you from altering all configurations afterwards. However for MySQL based nodes changing the configuration on all nodes has become trivial due to the new Configuration Management interface.
As a reminder, we recently covered in the same series deployment of clustering/replication (MySQL / Galera, MySQL Replication, MongoDB & PostgreSQL), management & monitoring of your existing databases and clusters, performance monitoring and health, how to make your setup highly available through HAProxy and MaxScale and in the last post, how to prepare yourself for disasters by scheduling backups.
Blog category:
