Any way to add MariaDB without having to remove Mysql ?

5 posts / 0 new
Last post
#1 Tue, 07/15/2014 - 12:40

Any way to add MariaDB without having to remove Mysql ?


I have a script doing a relatively poor job with its MySQL queries, and I have been SUPER STRONGLY (the full-caps is an understatement) avised to use MariaDB instead.

Thing is, to be frank, my dedicated server's webmin and virtualmin have been installed for me by a professional, and while I can handle the daily management and relatively small fixes or updates, or change the existing server configuration to suit my needs, I must be honest and confess I'm not yet capable of fully removing and replacing fundamental "bricks" of the machine.

In this context, I would be OK with adding MariaDB to my server, as an optional alternate engine, but in no way in hell would I want to remove MySQL to fully replace it with MariaDB, if it turns out I screwed up something, I have important for me websites that would go offline for an indefinite period of time.

Please, this is an open question, do you know if it's possible to install MariaDB within webmin and virtualmin, while keeping and not changing MySQL ? So that I could choose to use it, as an option, simply, if I prefer it ?

I searched the modules listed for webmin, and, regrettably, there's noone for MariaDB, sigh ^^ I can come up with an apt-get install in putty of course, hopefully there wouln't be too many additions to make to system configuration files, but, the main thing is, it's got to be an addition of an option, it musn't break what's already in place...

Sorry if my question is newbie-ish, but, heh, we all gotta learn some day ;) Thanks if you can tell me :)

Tue, 07/15/2014 - 14:37


I'm not familiar with a supported way to run them both side-by-side... even if you found packages that enabled you to do that, Webmin/Virtualmin don't know to look for both of them at the moment. It looks for one or the other.

However, one possibility is that if you can wait a few weeks, the newly released CentOS 7 actually comes with MariaDB. While Virtualmin doesn't support that distro quite yet, it will shortly.

What you could do is migrate all your domains over to a server running CentOS 7. Since MariaDB is designed to act as a drop-in replacement for MySQL, your current domains should all continue to run fine using that database.


Thu, 07/31/2014 - 17:05

Hello Eric !

I imagined it would be possible to have different variations of a database language (MariaDB/MySQL), just like there are different versions of PHP. I was mistaken, then.

Thank you very much for your explanation, with this I can move on. Have a great day ! :)

Thu, 07/31/2014 - 17:36


Well, in the case of PHP, that's accessed by Apache via the command line, as a command one runs on the server.

It's really simple for Virtualmin to switch out which PHP version is being used by any given domain, as all it does is point it to a different PHP binary.

With MySQL/MariaDB, that's a bit trickier as it's a running service. It has a number of associated libraries command line tools, and a data location. There's also a particular port each one would listen on. And the packages would need to support them both running on the same server.

It's not that it couldn't work, but it's a lot more complicated.

Here's another thought though --

Rather than trying to get MySQL and MariaDB on the same server, do you happen to have another server available to you? You could always setup MariaDB on another server, import your data into it, and then configure a particular website to use that server as it's data source.

You wouldn't need to move the website itself, just configure PHP in that domain so that it uses this other server when performing database connections.


Thu, 07/31/2014 - 18:28

Haha, I've only got one server, so that wouldn't do.

Actually, I "cheated" with the problematic script. Its slugginess was caused, we eventually found out, by very numerous SELECT DISTINCT queries (firstly discovered with a SHOW PROCESSLIST, and also listed in mysql-slow.log) applying themselves to the entirety of a database's largest table. While that may be OK for small tables or databases not under heavy load, that's a whole other business for really huge databases with very numerous entries from which many people demand many things. The developers of the script agreed this SELECT DISTINCT wasn't their brighest idea, and until they fix it with a new version, in the meantime, I duplicated my script into another subfolder and a new database. Dividing the load, incrementing a brand new database rather than the old fat one, we're back to a state where the server doesn't "bottleneck itself" and works fast.

I doubt these details are really relevant, but, who knows, maybe other people may be facing the same kind of issue some day in a distant future, so I may as well describe how I escaped the issue :)

Topic locked