This article is specific to this known issue stated in https://jira.mariadb.org/browse/MDEV-17379 which caused failure during deployment as we have stated in this Twitter post.
We have discuss this internally to find a solution. However, since the issue depends on the MariaDB to resolve this issue, we think of a workaround that would be feasible but not seamless compared to how the ClusterControl deployment is supposed to work but will work for you as of this time.
In this example, I want a 3-node MariaDB 10.3. Galera Cluster to be deployed. So here are the steps I took:
1.) Let the ClusterControl handle the installation for all your nodes to make it quicker and no manual hands-on to be applied:
- Deploy -> Select MySQL Galera -> Setup your SSH user credentials and cluster name -> Select MariaDB 10.3 -> Add Node one at a time. This means let CC install the packages for each and every node. The downside is that you have to duplicate this task each on every node but only replace the IP/Hostname on the "Add Node" part with the IP/hostname of the current node you're targeting to install
2.) Stop all the mariadb processes on all of the nodes i.e.
systemctl stop mariadb
3.) Edit /bin/galera_new_cluster and on the last line, replace the "return" command with "exit" which would be the expected output of the last line would look like as follows:
exit $extcode
4.) Once done with installing the packages on all of the 3 nodes, go back again to ClusterControl then,
"Deploy -> Select MySQL Galera -> Setup your SSH user credentials and cluster name and down below the "Cluster Name", you see the checkbox "Install Software". Set this to NO by clicking it leaving it just like 
then hit continue -> Select MariaDB 10.3 -> Add Node. This time, you can add all the nodes with it's IP/Hostname in order to setup your desired cluster.
This works for me without any errors and I was able to run it without any issues:
Let us know if this works for you.
Comments
8 comments
Just an update:
MaiaDB 10.3.11 has already fixed this. So you'll notice that in /bin/galera_new_cluster, instead of "return", the "exit" function is now used.
Very useful. Thanks for Sharing.
The new update is pretty complete and I like it.
basket random
Thanks for sharing these detailed steps! It’s a solid workaround for deploying a 3-node MariaDB 10.3 Galera Cluster despite the current limitations with the known issue. Your method of letting ClusterControl handle each node’s installation individually, followed by manually editing the galera_new_cluster script, seems like an effective approach to bypass the issue until MariaDB resolves it. This will help others facing deployment challenges with ClusterControl to achieve a stable setup for their clusters, even if it requires a bit more manual input. Great work, and thanks for contributing to the community!
1. Install Software on All Nodes (Individually):
In ClusterControl:
Deploy -> MySQL Galera -> Setup SSH and Cluster Name -> Select MariaDB 10.3Add one node at a time (change IP/hostname per node).
This installs the packages via ClusterControl, but not the full cluster.
2. Stop MariaDB on All Nodes:
systemctl stop mariadb3. Modify galera_new_cluster Script:
Edit
/bin/galera_new_clusterChange the final line from:
return $extcodeto:
exit $extcode4. Deploy the Cluster (Without Reinstalling Software):
Back in ClusterControl:
Deploy -> MySQL GaleraUncheck "Install Software" (leave it blank)
Continue, select MariaDB 10.3
Now add all 3 nodes at once
Thanks for sharing this workaround, Paul! This is really helpful for anyone struggling with MariaDB 10.3 deployment on ClusterControl.
To summarize your approach:
Initial Package Installation: Let ClusterControl install MariaDB 10.3 on each node individually. Yes, it’s a bit repetitive, but it ensures all necessary packages are correctly set up.
Stop MariaDB Services: Run systemctl stop mariadb on all nodes before modifying the Galera script.
Edit galera new cluster: Change the last line from return to exit $extcode. This prevents the script from failing during initialization.
Final Cluster Deployment: Go back to ClusterControl, disable the “Install Software” option, and add all nodes to finalize the cluster setup.
It’s a bit of a manual workaround, but it seems to reliably bypass the MDEV-17379 issue.
Have you noticed any edge cases or limitations with this approach, especially with larger clusters?
Hi Gohar,
If you see above, there's a link showing Create Support Request and we encourage you to file in case you find a bug upon using ClusterControl.
this is very interesting.
Please sign in to leave a comment.