[arch-dev-public] [RFC] Migration to MariaDB
Hello guys, Because Oracle is Oracle is Oracle(…) I would like to propose migration to MariaDB. Jokes aside, the biggest problem with MySQL situation is that it becomes more and more closed source. Oracle stopped publishing regression tests[1], informative security advisories, they even hide bug reports and not include them in release notes[2]. Very often their bzr repository is falling behind new releases[3]. On the other hand, MariaDB is truly open source (it doesn't have enterprise-only options) and has open development model. Security advisories are published first on the mailing list for packagers with a patch for current release and information when the bug will be fixed and when the information about security hole can be published (Another advantage for ricers -- some benchmarks show that MariaDB is faster.) From packaging side, MariaDB is (still) drop-in replacement for MySQL. Unfortunately they are not fully compatible[4] and I don't want to lie that I tested every package depending on MySQL before I pushed Maria to [community], but since April 2012 there has been no bug report about breakage. However I don't want to use replaces=, because clearly it won't work for everyone. Additionally switching now should be less problematic. MySQL 5.6 is already out and it is not as compatible with incoming MariaDB 10 as it was with 5.5 branch. While we keep Maria and MySQL branches in sync, it should be quite safe. To get back to the point… This is how I would see the migration plan: 1. Synchronize MariaDB and MySQL systemd units. 2. Move MariaDB to [extra]. 3. Rebuild packages depending on mysql/libmysqlclient/mysql-clients against its MariaDB counterparts. 4. Announce MySQL deprecation. 5. After month, drop MySQL to AUR. What do you think? Cheers, [1] http://blog.mariadb.org/disappearing-test-cases/ [2] http://ronaldbradford.com/blog/when-is-a-crashing-mysql-bug-not-a-bug-2012-0... [3] http://www.mysqlperformanceblog.com/2012/08/16/where-to-get-a-bzr-tree-of-th... [4] https://kb.askmonty.org/en/mariadb-vs-mysql-compatibility -- Bartłomiej Piotrowski http://bpiotrowski.pl/
On 19/02/13 04:42, Bartłomiej Piotrowski wrote:
To get back to the point… This is how I would see the migration plan:
1. Synchronize MariaDB and MySQL systemd units. 2. Move MariaDB to [extra]. 3. Rebuild packages depending on mysql/libmysqlclient/mysql-clients against its MariaDB counterparts. 4. Announce MySQL deprecation. 5. After month, drop MySQL to AUR.
That sounds a good plan (from someone who has no idea of the issues in this area...)
In related news, Fedora and OpenSUSE are supposedly switching over to MariaDB too: http://www.zdnet.com/oracle-who-fedora-and-opensuse-will-replace-mysql-with-... - Alexander
On 18 February 2013 18:42, Bartłomiej Piotrowski
Hello guys,
Because Oracle is Oracle is Oracle(…) I would like to propose migration to MariaDB.
Jokes aside, the biggest problem with MySQL situation is that it becomes more and more closed source. Oracle stopped publishing regression tests[1], informative security advisories, they even hide bug reports and not include them in release notes[2]. Very often their bzr repository is falling behind new releases[3].
On the other hand, MariaDB is truly open source (it doesn't have enterprise-only options) and has open development model. Security advisories are published first on the mailing list for packagers with a patch for current release and information when the bug will be fixed and when the information about security hole can be published (Another advantage for ricers -- some benchmarks show that MariaDB is faster.)
From packaging side, MariaDB is (still) drop-in replacement for MySQL. Unfortunately they are not fully compatible[4] and I don't want to lie that I tested every package depending on MySQL before I pushed Maria to [community], but since April 2012 there has been no bug report about breakage. However I don't want to use replaces=, because clearly it won't work for everyone. Additionally switching now should be less problematic. MySQL 5.6 is already out and it is not as compatible with incoming MariaDB 10 as it was with 5.5 branch. While we keep Maria and MySQL branches in sync, it should be quite safe.
To get back to the point… This is how I would see the migration plan:
1. Synchronize MariaDB and MySQL systemd units. 2. Move MariaDB to [extra]. 3. Rebuild packages depending on mysql/libmysqlclient/mysql-clients against its MariaDB counterparts. 4. Announce MySQL deprecation. 5. After month, drop MySQL to AUR.
What do you think?
Cheers,
[1] http://blog.mariadb.org/disappearing-test-cases/ [2] http://ronaldbradford.com/blog/when-is-a-crashing-mysql-bug-not-a-bug-2012-0... [3] http://www.mysqlperformanceblog.com/2012/08/16/where-to-get-a-bzr-tree-of-th... [4] https://kb.askmonty.org/en/mariadb-vs-mysql-compatibility
As long as it doesn't break anything I'm completely fine with moving to MariaDB.
Am 18.02.2013 19:42, schrieb Bartłomiej Piotrowski:
To get back to the point… This is how I would see the migration plan:
1. Synchronize MariaDB and MySQL systemd units. 2. Move MariaDB to [extra]. 3. Rebuild packages depending on mysql/libmysqlclient/mysql-clients against its MariaDB counterparts. 4. Announce MySQL deprecation. 5. After month, drop MySQL to AUR.
I see there is a new TODO list at https://www.archlinux.org/todo/mariadb-migration/ Was this list generated using sogrep or similar? Also: How is this supposed to work? Unless we add provides=mariadb etc. to mysql these rebuilds will make it impossible to keep using mysql for users. If that's desired we need to announce this change including a migration guide way before we do the actual rebuilds and not after the fact. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
On Mon, Mar 4, 2013 at 1:06 AM, Pierre Schmitz
Am 18.02.2013 19:42, schrieb Bartłomiej Piotrowski:
To get back to the point… This is how I would see the migration plan:
1. Synchronize MariaDB and MySQL systemd units. 2. Move MariaDB to [extra]. 3. Rebuild packages depending on mysql/libmysqlclient/mysql-clients against its MariaDB counterparts. 4. Announce MySQL deprecation. 5. After month, drop MySQL to AUR.
I see there is a new TODO list at https://www.archlinux.org/todo/mariadb-migration/
Was this list generated using sogrep or similar? I noticed postfix is not on this list, and yet it links against libmysqlclient.
-Dan
On Monday 04 March 2013 08:01:28 Dan McGee wrote:
I noticed postfix is not on this list, and yet it links against libmysqlclient.
Yes, Barthalion I also think that those need to be rebuilt too: % sogrep extra libmysqlclient.so.18 amarok calligra-kexi cyrus-sasl-sql dovecot gnokii libgda lighttpd mysql-python perl-dbd-mysql postfix qt3 qt4 qt5-base redland-storage-mysql % sogrep community libmysqlclient.so.18 collectd dspam freeradius fssos-nsvs gambas2-gb-db-mysql gambas3-gb-db-mysql gammu gdal gsql libdbi-drivers libgda4 libzdb lua-sql-mysql myodbc mysql++ mythplugins-mythzoneminder opensips pam_mysql pdns proftpd rsyslog ulogd vtk xbmc -- Andrea Arch Linux Developer
On 2013-03-04 08:06, Pierre Schmitz wrote:
Was this list generated using sogrep or similar? Also: How is this supposed to work? Unless we add provides=mariadb etc. to mysql these rebuilds will make it impossible to keep using mysql for users. If that's desired we need to announce this change including a migration guide way before we do the actual rebuilds and not after the fact.
Sorry, it was not, I just added missing packages. I want to add provides= to MySQL (and the rest), I didn't have time yesterday to do so. 2-3 weeks after rebuild I'll post a news about package deprecation and migration guide; after another 2 weeks I would like to move MySQL to AUR. -- Bartłomiej Piotrowski http://bpiotrowski.pl
participants (7)
-
Alexander Rødseth
-
Allan McRae
-
Andrea Scarpino
-
Bartłomiej Piotrowski
-
Dan McGee
-
Lukas Jirkovsky
-
Pierre Schmitz