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.

With the T181353: [EPIC] Migrate MediaWiki-Vagrant base image to Debian Stretch migration mariadb is the default packages from upstream. We need to update existing roles to install them and it should be mostly taken care of. Renaming things from "mysql" to "mariadb" in Puppet can be done or not, I don't have a strong opinion either way.

If the goal is to match production (which would be nice, MySQL and MariaDB have some significant query optimizer differences which means one might end up with different queries / indexes), vagrant should have 10.0, but stretch has 10.1... not sure how relevant that difference is. That problem would go away as production also migrates to stretch, but it seems like for vagrant the migration is planned significantly sooner than that?

The version in use in production varies from server to server I think. I know that the labsdb10{09,10,11} servers at least are using Stretch and mariadb Ver 15.1 Distrib 10.1.28-MariaDB, for Linux (x86_64) using readline 5.2.

Change 394818 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[operations/puppet/wikimetrics@master] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394818

Change 394819 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[mediawiki/vagrant@master] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394819

Change 394819 merged by jenkins-bot:
[mediawiki/vagrant@master] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394819

Change 394823 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[mediawiki/vagrant@stretch-migration] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394823

Change 394823 merged by jenkins-bot:
[mediawiki/vagrant@stretch-migration] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394823

Change 398648 had a related patch set (by Paladox) published:
[mediawiki/vagrant@stretch-migration] Migrate mysql to mariadb

https://gerrit.wikimedia.org/r/398648

For now, installing the package mysql-server works through this chain of compatibility packages that are present in the Stretch repos:

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 9.1 (stretch)
Release:	9.1
Codename:	stretch
$ apt-cache show mysql-server
Package: mysql-server
Source: mysql-transitional
Version: 5.5.9999+default
Installed-Size: 8
Maintainer: Ondřej Surý <ondrej@debian.org>
Architecture: amd64
Depends: default-mysql-server
Description: MySQL database server binaries and system database setup [transitional]
Description-md5: 9640aa018a23c1a7160742ea78f76557
Tag: devel::lang:sql, implemented-in::c, implemented-in::c++,
 interface::daemon, network::server, protocol::db:mysql,
 role::metapackage, role::program, scope::suite, works-with::db
Section: database
Priority: optional
Filename: pool/main/m/mysql-transitional/mysql-server_5.5.9999+default_amd64.deb
Size: 1706
MD5sum: 66a9e3bf518038bccf10f40ec29fa679
SHA256: 9b5ae21b4e251ec5caec212f98b12ea2549ce733e13b8f1667c8a7e0300a8001
$ apt-cache show default-mysql-server
Package: default-mysql-server
Source: mysql-defaults
Version: 1.0.2
Installed-Size: 9
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Architecture: all
Depends: mariadb-server-10.1
Description: MySQL database server binaries and system database setup (metapackage)
Description-md5: 9550a987565ff8657fc9f699871795c3
Section: database
Priority: optional
Filename: pool/main/m/mysql-defaults/default-mysql-server_1.0.2_all.deb
Size: 3048
MD5sum: 8ce98d0747071c3741ad8436d32584c6
SHA256: 0f3de40078e20e30fe54de367dc0a4096a22677d7c4362f64789e3d201bac0f9

It would be easy enough to change to installing the mariadb-server meta package instead so that things keep working in a future Debian release that removes the mysql-server compat package.

$ apt-cache show mariadb-server
Package: mariadb-server
Source: mariadb-10.1
Version: 10.1.26-0+deb9u1
Installed-Size: 62
Maintainer: Debian MySQL Maintainers <pkg-mysql-maint@lists.alioth.debian.org>
Architecture: all
Depends: mariadb-server-10.1 (>= 10.1.26-0+deb9u1)
Description: MariaDB database server (metapackage depending on the latest version)
Description-md5: 184dec3a9fb41c1cd31a78f54fa02394
Homepage: https://mariadb.org/
Tag: devel::lang:c++, devel::lang:sql, implemented-in::c++,
 interface::commandline, interface::daemon, network::server,
 protocol::db:mysql, role::metapackage, role::program, works-with::db
Section: database
Priority: optional
Filename: pool/main/m/mariadb-10.1/mariadb-server_10.1.26-0+deb9u1_all.deb
Size: 26180
MD5sum: 6da9eed1733b61eb9a60805e21c32320
SHA256: 951c0cce99b5a5a2728df8e917f7a813e36459c93c3f2bdced5e5036d6da3c37

The Wikimedia Foundation production servers use custom builds of MariaDB which also have custom package names. For Stretch the current name is wmf-mariadb101. I'm not entirely sure what the extent of customizations added to the production package are. Does anyone know if we need to add the complexity of tracking them?

Change 400119 had a related patch set uploaded (by BryanDavis; owner: Bryan Davis):
[mediawiki/vagrant@stretch-migration] mysql: remove unnecessary -p${mysql::root_password} usage

https://gerrit.wikimedia.org/r/400119

Change 394818 merged by Ottomata:
[operations/puppet/wikimetrics@master] Replace libmysqlclient-dev with default-libmysqlclient-dev

https://gerrit.wikimedia.org/r/394818

Change 400119 merged by jenkins-bot:
[mediawiki/vagrant@stretch-migration] mysql: remove unnecessary -p${mysql::root_password} usage

https://gerrit.wikimedia.org/r/400119

Change 398648 abandoned by Paladox:
Migrate mysql to mariadb

https://gerrit.wikimedia.org/r/398648