Hi everyone!
Any idea how I can upgrade MariaDB on my Ubuntu Linux 22.04.5 through Virtualmin?
Or do I have to do it in SSH directly?
Any help would be greatly appreciated!
Also, I am not sure if I can change the version of MariaDB or see the version in Virtualmin?
Thanks!
| SYSTEM INFORMATION | |
|---|---|
| OS type and version | Ubuntu Linux 22.04.5 |
| Webmin version | 2.202 |
| Virtualmin version | 7.20.2 Pro |
You shouldn’t do it at all. But if, here are the steps… Pay attention at every step and don’t do without a current backup!
All steps assume you’re logged in as root. Otherwise, prefix with sudo.
Perform database backup:
mysqldump -u [username] -p[password] [database_name] > backup.sql
Stop MariaDB server:
systemctl stop mariadb
Find the to be installed version number on mariadb.org and pop it in at the end (e. g. 11.2.3):
apt install software-properties-common;apt-key adv --fetch-keys 'https://mariadb.org/mariadb_release_signing_key.asc';curl -LsS https://r.mariadb.com/downloads/mariadb_repo_setup | sudo bash -s -- --mariadb-server-version=11.2.3
Backup MySQL data:
cp -v -a /var/lib/mysql/ /var/lib/mysql_backup
Perform upgrade:
apt-get update;apt-get install mariadb-server
Modify my.cnf:
sed -i 's/bind-address = ::ffff:127.0.0.1/bind-address = 127.0.0.1/g' /etc/mysql/my.cnf
Start MariaDB service:
service mariadb start
Update MySQL/MariaDB databases:
mariadb-upgrade
Restart MySQL service:
service mariadb restart
thanks a lot @Steini !
I just realised reading some more that I might not need to.
I am now on MariaDB 10.6.20 and it’s stable:
mariadb Ver 15.1 Distrib 10.6.20-MariaDB, for debian-linux-gnu (x86_64) using EditLine wrapper
I was having issue with another script and I thought I need to upgrade it, but don’t think so.
Do you know if Virtualmin upgrades MariaDB automatically from the dashboard itself when it’s a new stable version?
Or do I have to run the ssh commands like you mentioned?
Thx!
Virtualmin won’t do it. MariaDB is part of the distribution. If Ubuntu does, then it’ll be upgraded. But defo not by Virtualmin.
got it cool, thx man!
I am a windows guy, can you just tell me why?
Thanks
There’s no reason to.
Your OS vendor (Ubuntu or whatever) will maintain the version you have throughout the life of the distribution, including backporting security patches, if needed, which is great for longterm stability and compatibility. When you upgrade across major versions of MariaDB, MySQL, or Postgresql, it is often best practice to perform a dump and restore (though check the upgrade docs for your specific versions of your specific database), which is a time-consuming process that requires downtime. Those are best planned as part of an OS upgrade for the vast majority of users. There may be other changes that require code changes in your applications, again check the upgrade docs for your specific versions of your specific database.
If you install a different version of Mariadb from the one provided by your distro, you do not get the long-term update assurance, and you’re then on the hook to always upgrade from that new source…meaning you may be signing up for more frequent dump/restore cycles (Mariadb doesn’t change major versions extremely often, and they maintain a couple of major versions via a long term support model, so it’s not a super big deal in this case, but it can happen).
There is no benefit to going off-roading for most users most of the time. The path of least pain for almost everyone (including most experts!) is to pick a distribution you like made by people you trust, use the latest version available, and use exactly the packages they provide for you. Your applications, custom code, and specific scaling issues are more than enough problems for most people, why make more problems for yourself?
Databases move slowly, and applications trail behind the latest features by a year or two, at least. You’re really not missing anything by being on a major version of Mariadb that’s a year or two old.
And, finally, for OP: We do not provide any of these packages (Mariadb, Apache, nginx, Postfix, SpamAssassin, etc.). Your OS does. If you want new packages, pick a new OS. If you’re thinking about spending a bunch of time deploying a custom Mariadb version from upstream, I would suggest you spend that time planning a migration to Ubuntu 24.04. It’s not a lot more time, and you get all new packages, not just Mariadb, and you aren’t going off on your own making more problems for yourself.
Thanx!
However, after any upgrade, any edits in the “MariaDB Server Configuration” appear empty… What can be done about this? I’ve already restored backups of /etc/mysql and /var/lib/mysql, but the result is the same. I’m at my wit’s end; please help.
My Ubuntu version is 24.04.
When you upgrade MariaDB it won’t be properly covered by *min any longer. These are side effects that occur. Hence, I wouldn’t upgrade but stick to the version that the distro was shipped with.
Thanx!
And whose fault is it? Is it Virtualmin itself or the operating system?
There’s a significant difference between MariaDB 10 and 11. 
That depends on the package you installed. Packages might put configuration and data in different places from the defaults that Webmin knows about. You’ll need to figure out where those places are, and update the module configuration for the Webmin Mariadb module (click the gear 
icon in the upper left corner of the Mariadb module front page).
You’ve gone off-roading, you’ll need to do some work. I don’t use any Mariadb version except the one that comes from my distribution provider, so I have no specific advice to offer.
For anyone else following along: the best option for upgrading anything is to choose a newer OS. In this case Ubuntu 24.04 would provide a new Mariadb (and newer everything else), and it would all be in places that Webmin already knows about.
on 24.04 LTS have MariaDB version 10.11.8…
It’s your fault, obviously. 
Virtualmin works, out of the box, with the packages provided by the OS, for all supported operating systems.
And, the OS picks a version and sticks with it through the life of the OS. That’s a feature, not a bug, it means that code you wrote when you first deployed on the OS will continue to work through the life of the OS, and you’ll never need to do a dump/restore for normal OS updates.
I installed Virtualmin after updating the packages to the latest version 11.4.4 
and the same problem persists, though I think I might have the wrong line of reasoning.
Yes, you’re misunderstanding the problem. I’ve explained why it’s happening and what you need to do above. Webmin expects to find all of the configuration in the locations from the system-provided package, and it expects the service name to be the one provided by the system package. You installed a package from a different source, and it could put those things in completely different places. I don’t know what those places are, you’ll need to figure that out, and you’ll need to tell Webmin.
on RHEL9/Alma/Rocky you can do:
dnf module install mariadb:10.11/server
and then:
mysql_upgrade -u root -p
The last command is important so virtualmin backups still work.
The method seems safe, because it replaces the stock install. You are not dealing with new dirs or something optional.
There are scripts in 2024 that claim 10.6 is outdated so I think it is a fair question.
Thx a lot man, i actually in my silliness i upgraded on my Ubuntu 22.04 to MariaDB 10.6.20. I should have come back to this thread earlier.
I’ll upgrade to Ubuntu 24.04 when I get the chance in a few weeks time.
For now I just upgraded because I though I had to with the diff scripts I got running.
Would you recommend then porting easily MariaDB to the new Ubuntu 24.04?
I mean is there a way with Virtualmin when you upgrade the OS from Ubuntu 22.04 to also port all config files from MariaDB 10.6.20 to the new MariaDB that will be on Ubuntu 24.04?
Thanks a lot !
Is this way pretty safe to test first?
I mean is there a way to test first that the new Ubuntu 24.04 will have the right backup?
Last time i tried something similar to this (no these commands), I ended up wiping my MariaDB : /
So I was hoping I could do a test-run first to see it backs up correctly.
That’s not Virtualmin’s business. It’s handled as part of the OS upgrade, in the vast majority of cases. Which is why I’m recommending you upgrade your OS, instead of doing a hodgepodge of random package upgrades from random sources.
Of course you should make sure you have good backups of everything, including dumps of all databases, before embarking on a serious thing like an OS upgrade. But, I’ve rarely had a problem with an OS upgrade using the tools provided by the OS.
I have no idea how that would happen following the recommended process for upgrading Ubuntu. Seems like a case of going off-roading, and doing something unusual and more complicated than the recommended process.
And, major version upgrades of databases (e.g. from 10.x.y to 11.x.y) may be more dramatic, even in cases of upgrading as part of the standard OS upgrade process, and you should do some reading to understand the implications.
Again, you need good backups always, and you especially need good backups when doing something dramatic. But, upgrading your OS following the documentation for your OS is less dramatic and less risky than trying to piece together a custom distribution of your own devising from sources of your choosing.