Wikimedia Bugzilla is closed!

I doubt most MediaWiki sites use MariaDB. That's just a Wikimedia thing...

(In reply to comment #0)
> To better match between development and production environments, vagrant could
> install the same version of MariaDB used for wikimedia production databases.

I support the idea in principle. Do you have a scenario in mind where the difference is likely to be significant?

I'd simply like to understand the trade-offs. Even if we use the same binaries as prod, there is a massive difference between a single MySQL instance under single-user load vs. a massive MySQL cluster w/master-slave replication operating under standard Wikimedia load. So all other things being equal, sure, let's use MariaDB, but if it is even slightly more complicated to install and configure, it may not be worth it.


(In reply to comment #1)
> That's just a Wikimedia thing...

Hardly. openSUSE[0], Slackware[1], Arch[2], Fedora[3], RHEL[4], and OpenBSD[5] have replaced Oracle's MySQL with MariaDB as the default. Debian & Ubuntu have been dragging their feet a little, but I bet it won't be very long before they too make the switch.

  [0]: http://blog.mariadb.org/opensuse-12-3-released-with-mariadb-as-default/
  [1]: http://slackware.com/
  [2]: https://www.archlinux.org/news/mariadb-replaces-mysql-in-repositories/
  [3]: http://www.zdnet.com/oracle-who-fedora-and-opensuse-will-replace-mysql-with-mariadb-7000010640/
  [4]: http://www.theregister.co.uk/2013/06/15/red_hat_to_ditch_mysql_for_mariadb_in_rhel_7/
  [5]: http://blog.mariadb.org/mariadb-now-in-openbsd-ports-tree/

There are not any large differences i'm aware of that would make the difference,  i suppose i should have left out the part about dev/prod matching as its still a large difference.   Mostly i was just surprised to find mysql being used rather than mariadb as it is the "more free" one ;-)

The reason i noticed isn't so relevant, i was investigating various possible distributed id generation systems.  One system documented by instagram involves ms timestamps. Mariadb has ms timestamps, mysql doesnt.  But this isn't really relevant to normal development work mostly just investigating something there.

Not sure how hard it would be in puppet, one possible install method is adding a ppa and installing the mariadb-server package.  The mariadb package uses the same config files and same database files in same paths, in a quick test it replaced the mysql5.5-server and loaded up its data files no problem.

sudo apt-get install python-software-properties
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
sudo add-apt-repository 'deb http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu precise main'
sudo apt-get update
sudo apt-get install mariadb-server

This uses all the same config files, etc.

Indeed, it should just drop in. With no prior modifications to the my.cnf file, it should be fine.

One thing that might want to be explicitly done, is to pin the version of mariadb-server [1], to save unwanted complications

After the 12.10 -> 13.04 Ubuntu upgrade, due to there being no newer version of mariadb yet, Ubuntu got into a mess, with some mariadb packages installed, and some for mysql as they were "newer".

Not sure how much of a problem this might be for vagrant, but as it should be able to be done easily, I can't see it causing much of an issue.



[1] https://kb.askmonty.org/en/installing-mariadb-deb-files/#pinning-the-mariadb-repository

This is not amazingly complicated to do or anything, but it does involve adding another apt repository, which sucks for two reasons:

a) It adds another external resource as a dependency
b) It introduces yet another ordering requirement (the repo has to be added and its package list fetched before installing the database)

So my preference is to not to migrate just yet, unless there is some deeply compelling reason to do it. If you have a reason, or if the packaging situation for MariaDB changes, feel free to re-open.

(In reply to comment #5)
> So my preference is to not to migrate just yet [...]

What does "just yet" mean here?

Generally bugs are only marked resolved/wontfix if we want to convey "this is never going to happen, so stop asking." OTOH, we've gotten rid of resolved/later, apparently. Hrmph.

(In reply to comment #6)
> What does "just yet" mean here?

It'll happen eventually. I'm betting against MySQL, too.

If MariaDB is added to the official Ubuntu repositories, or if the differences between it and MySQL prove salient to MediaWiki development, I'll consider making it the default.

The best-case scenario from my perspective is that this bug is resolved upstream, with Ubuntu dropping MySQL for MariaDB and making MariaDB the default target for 'apt-get install mysql-server'. Then nothing would have to change.

It's worth waiting for that, I think, since there's no real cost to not migrating at the moment, and an upstream fix looks totally plausible.

Does WORKSFORME status work better? I don't mind re-opening, either, if that's the most apt (heh) status for the bug.

I'll re-open, because I'd also accept a patch implementing an optional MariaDB role.

[mass-moving from Tools>MediaWiki-Vagrant to separate product. See bug 54041. Filter bugmail on this comment.]

The mariadb puppet module has been split out of operations/puppet.git and included in MediaWiki-Vagrant via a git submodule in Ibd1b9d29c76c790efc363249e2caded950f5c66a. This should pave the way for a role that switches to MariaDB or just changing the default to MariaDB.

(Added Sean in case he wants to poke at this at some point.)

I looked at the mariadb module and I don't think it will actually be useful from MediaWiki-Vagrant at this point. If we used the ::mariadb class it would fail because it unconditionally requires ::nrpe::monitor_service which we don't have. The ::mariadb::packages class needs an ::apt::repository resource we don't have in MWV either.

Probably the easiest thing to do would be to change the implementation of our ::mysql::packages class to install the mariadb packages. They all seem to be available via the apt repositories we already have available in the trusty apt repos. I guess the remaining question is whether we should switch unconditionally (easiest) or with a role.

Bulk unassigning bugs from Ori.