Fedora 19 Nixing MySQL in Favor of MariaDB 116
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.
Re:Postgresql (Score:5, Informative)
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:Migrating (Score:5, Informative)
> 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 (Score:5, Informative)
Re:We've begun the move away from MySQL also (Score:5, Informative)
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/
Re:See this comparison. Wikipedia is moving, too. (Score:5, Informative)
Debian is planning to do the same (the thread containing approval from relevant people at Ubuntu too), for much the same reasons.
Re:Postgresql (Score:4, Informative)
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.