Fedora 19 Nixing MySQL in Favor of MariaDB

An anonymous reader writes "Red Hat developers are planning to replace MySQL with MariaDB in Fedora 19. For the next Fedora update, the MariaDB fork would replace MySQL and the official MySQL package would be discontinued after some time. The reasoning for this move is the uncertainty about Oracle's support of MySQL as an open-source project and moves to make the database more closed." Update: 01/22 13:47 GMT by T : Note: "Nixing" may be a bit strong; this move has been proposed, but is not yet officially decided.

Comments

See this comparison. Wikipedia is moving, too.

[phaunt]

Here is a comparison of MariaDB vs MySQL.
Probably most important to Fedora is this:

Truly Open Source

• All code in MariaDB is released under GPL, LPGL or BSD. MariaDB does not have closed source modules like the one you can find in MySQL enterprise edition. In fact, all the closed source features in MySQL 5.5 enterprise edition are found in the MariaDB open source version.
• MariaDB includes test cases for all fixed bugs. Oracle doesn't provide test cases for new bugs fixed in MySQL 5.5.
• All bugs and development plans are public.
• MariaDB is developed by the community in true open source spirit.

Wikipedia, too, is moving from MySQL to MariaDB.

Re:See this comparison. Wikipedia is moving, too.

[David Gerard]

Debian is planning to do the same (the thread containing approval from relevant people at Ubuntu too), for much the same reasons.

Postgresql

[Anonymous Coward]

Just use it.

Re:Postgresql

[egr]

Off-topic. Fedora already has PostgreSQL in its repositories. The point of the move is to replace MySQL, not to have some killer database.

Re:Postgresql

[petermgreen]

Unfortunately it's not that simple.

For example I have an application that uses a case insensitive collation. Afaict postgresql does not support this. There are ways to implement the same functionality (create an index on the uppercased version of the columns value) but it would mean changing every query that hits the columns in question.

For new stuff I will definately be choosing postgresql over mysql though.

P.S. does anyone know of a tool that can be used to design postgresql database schemas and export create/update scripts? (like mysql workbench does for mysql)

Re:Postgresql

[bad-badtz-maru]

Set your LC_COLLATE environmental variable on the PG server (and any client machines). PG probably isn't finding a setting, so it's defaulting to "C". If you switch it to something like en_US, collation will be case-insensitive. You may have to reindex after making the change.

We've begun the move away from MySQL also

[C_Kode]

We've begun to move away from MySQL offical release also. Although we went with Percona rather than MariaDB.

Re:We've begun the move away from MySQL also

[Anonymous Coward]

They are fairly comparable in features and performance in most cases while both are arguably superior to MySQL. MariaDB uses code from Percona (XtraDB) and tends to be more bleeding edge while Percona is more conservative and stable. MariaDB is a community effort whereas Percona is an actual company who you can call (pay) for support if needed (they will support any flavor of MySQL but Percona is obviously their area of expertise).They are both good products in their own way and give back a lot to the community. .02

Feature/Perfornace Comparisons:
http://stackoverflow.com/questions/12671634/mariadb-vs-drizzle-vs-percona-sever-vs-mysql
http://vbtechsupport.com/657/
http://vbtechsupport.com/606/

Yes.

[Anonymous Coward]

The point of the move is to replace MySQL, not to have some killer database.

And for those of us who are tied to MySQL, it's nice to have an alternative now without the hassle of moving to a completely different DBM.

Migrating

[mwvdlee]

How easy is it to migrate from MySQL to MariaDB?
Is it truely drop-in replacement as in "you can develop to MySQL, then run MariaDB in production without worrying"?
Does it require converting current tables? Will it take a 10GB database all day to convert or will MariaDB just use the raw MySQL data files automagically?

Re:Migrating

[hholzgra]

> Is it truely drop-in replacement as in "you can develop to MySQL, then run MariaDB in production without worrying"?

yes, unless you use some of the non-GPL extra features like e.g. authentication plugins or pool-of-threads. For these MariaDB has GPL replacements but the implementation and configuration may differ ...

> Does it require converting current tables?

Data format of MyISAM and InnoDB tables is the same, so "no" in general. mysql system database may differ a bit, but nothing the mysql_upgrade tool can't fix, and you'll have the same issues when develop against an older MySQL version and deploying to a newer one ...

> Will it take a 10GB database all day to convert or will MariaDB just use the raw MySQL data files automagically?

It will use existing raw files just fine. mysql_upgrade may take a few minutes max., but not all day ... (unless you're migrating from an older MySQL version and mysql_upgrade needs to recreate some indexes ... but that would happen when upgrading to a more current MySQL release, too, and wouldn't be MariaDB specific

The only point where it isn't a simple "try and revert if you don't like it" drop in replacement is if mysql_upgrade changed mysql.* system tables and you want to roll back to regular MySQL ... but then again this is also the case when trying to upgrade to a more recent MySQL release and then deciding to roll back to a previous older one again ... so you should always have a backup to restore the original system tables from ... but you'd do a full backup before any version migrations anyway, wouldn't you?

Re:Migrating

[TheBlackMan]

I have recently migrated 2 of my servers from MySQL to MariaDB with about 1,5mil unique users. The only problems i had were some configuration (my.cnf) changes. Except that, none at all.

Ha Ha

[EETech1]

That is one thing I always loved about Open Source Software, you can't hold it hostage. If something happens to threaten the project, its fork you, and bye bye!

The users and developers take what was there (and theirs) pack up and resume life a usual somewhere else, and give the finger to all the Larrys that come along and try to (ab)use them as part of their own personal plot.

If you take care of them they will stay, and you might even see your user and developer base grow, but try and take advantage of them and you will soon be left with nothing. They take the short term pain of starting over instead of the long term pain of taking orders from someone who does not have their best interests in mind.

Cheers!

Re:Ha Ha

[cheesybagel]

The problem with Oracle is they always do it like this. First they acquire a major competitor in a major cash transaction then they milk it for a couple of years firing most of the development team and selling licenses while they can. Then they cease support altogether. They are not interested in further developing anything they acquire. It is all slash and burn. Their main expertise was never development it is sales and support.

Update: 01/22 14:01 GMT by LarryEllison:

[LulzAndOrder]

Larry Ellison responded with the comment, "you are all spelling it wrong, I renamed it MY sql some time ago."

Re:Percona

[geminidomino]

So the developers of MariaDB took all their experience and knowledge that they obtained at Oracle while working on MySQL and created a direct competitor product to their prior company's product?

Yep, and he was SUCH a sneaky, underhanded shit that he left the company a whole YEAR before Oracle even knew they had it.

Derp.