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.
See this comparison. Wikipedia is moving, too. (Score:5, Interesting)
Probably most important to Fedora is this:
Wikipedia, too, is moving from MySQL to MariaDB [zdnet.com].
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: (Score:2)
Two things that amaze me about this
1. That Debian isn't the first to do it. They're usually on top of this.
2. That it's taken this long to happen. We knew something like this would happen in the Linux community when Oracle took over MySQL. And there were some promising forking efforts that started immediately. Then, silance... for years. Now it's happening all at once, which is good.
Does anyone know if Maria is a MySQL fork? Or if it's totally new code? My cursory scan of the website hasn't revealed anythin
Re: (Score:1)
Signs point to "yes." [lmgtfy.com]
Re: (Score:1)
On top on innovation ? Not really. Debian has become too big to innovate fast, and Debian is a little bit too often in freeze ( like 20% of time ) due to release pressure.
Mageia did it last year, so of course, this is doable, but for something of the size of debian, moving from mysql to mariadb is not easy to do, as you have dependency all over the archive.
Debian, MySQL, and Oracle (Score:2)
And really, Debian's big selling point is their "stable" branch. They're famous for being slower to change things than other distros (which increasingly seems like a big advantage to me, in a world where everyone thinks they have a right to broadcast UI changes to you at the designer's whim).
Anyway, while the threat from Oracle takin
Comment removed (Score:4, Insightful)
Re: (Score:2)
Um. He sold it to Sun. It wasn't until Sun got sold to Oracle -- a move which he fought against -- that the fork happened.
Re: (Score:2)
Postgresql (Score:4, Insightful)
Just use it.
Re: (Score:2)
At the risk of drunken understating...
+1
Re:Postgresql (Score:5, Insightful)
Yes. (Score:5, Insightful)
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.
Re: (Score:1)
Well obviously. But they need a MySQL compatible DB in the repos for software that inconsiderately uses MySQL instead of Postgres.
Re: (Score:1)
You can't build a LAMP stack with PostgreSQL! The closest you can get is LAPP, but nobody wants a LAPP stack - it sounds like something Spaghatta Nadle would use for makeup.
Re: (Score:2)
You can't build a LAMP stack with PostgreSQL! The closest you can get is LAPP, but nobody wants a LAPP stack - it sounds like something Spaghatta Nadle would use for makeup.
Got something against reindeer?
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: (Score:3)
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)
Could it be as simple as keep using mysql workbench (which I've never used) and pipe it thru SQLfairy aka SQL::Translator (a sourceforge project) to convert from mysql to postgresql?
I have a simple automated system that mysqldumps all my schema, then shoves them thru sqlfairy to convert to DOT (you'd be converting to postgresql, which I know sqlfairy claims to be able to do), then shoves the DOTs thru graphviz to convert to png diagrams, then creates a simple webpage to link to each db diagram. Easy and fa
Re: (Score:2)
The closest thing to case-insensitive collation is the citext data type [postgresql.org]. It works basically transparently as a case-insensitive replacement for varchar and text.
The major feature keeping $dayjob from using PostgreSQL over MSSQL in new development is the lack of an accent-insensitive collation. Making an index using a custom function marked IMMUTABLE that calls (lower(unaccent(text)), and then calling the same function in nearly every query, is simply too hackish to stomach.
Re: (Score:2)
Hmm. You can specity a COLLATION to use on each column (or index I believe) but you would need to find or make a collation which does what you want and call it "en_SIMPLE" or something.
CREATE TABLE test1 (
a text COLLATE "en_SIMPLE"
b text -- Default collation
);
You can even define it on the fly in the Selects if preferred
SELECT * FROM test1 ORDER BY a COLLATE "en_SIMPLE";
SELECT * FROM test1 ORDER BY a COLLATE "en_US";
The question is, how do you create a new collation.
Re: (Score:2, Insightful)
Sounds like you need to fix your application.
Re:Too bad SQL is not like W3C standards (Score:2)
Every vendor wants their own proprietary extenstions, and even fight each other on who gets the most proprietary lockin, apis, and extensions on top of their own SQL to maximize pain leaving their shit ecosystem. ADO.NET, ODBC, and other things where you can't just use sql, but another vendor $$$ framework that locks you in further and add dozens of lines of ugly code and before you add another proprietary layer of Vendor X SQL inside it.
Then gee you can't leave it. Larry grins and then raises the cost know
Re: (Score:2)
Re: (Score:2)
Part of the problem is that ANSI SQL is fairly unfeatured. That's why everybody adds to it.
ANSI SQL really needs some official extensions so that much of the proprietary nonsense can go away.
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.
Re: (Score:1)
Yeah, I was wondering about that, wasn't sure if reindexing would be sufficient.
Re: (Score:1)
Have you heard of pgmodeler [github.com]?
Re: (Score:2)
Postgres has a case-insensitive data type extension available called citext [postgresql.org].
Re: (Score:1)
Re: (Score:2, Insightful)
By design, Postgresql is simply not as good a key-value store as MySQL / MariaDB. Innodb stores the data along with the primary index (technically cluster index), so it's fast to look up data by the primary key. Postgres is a better database, though.
Re: (Score:2)
Re: (Score:1)
I don't use databases. I use programs.
The programs use databases. I give the programs what they ask for.
Re: (Score:2)
Re: (Score:1)
Why not just migrate to one of the newer, cooler, noSQL databases? Some of them are maturing quite well.
Re: (Score:2)
Because NoSQL isn't an alternative to an RDBMS except where an RDBMS is a bad choice in the first place. They're complementary technologies, doing well what the other doesn't. If you're appropriately set up with MySQL (or Postgres, or Oracle), then any NoSQL solution will be a bad move no matter how mature.
Re: (Score:2)
Re: (Score:2)
The goal is to educate people that there is a Real FREE and Open database out there. Postgres is on par with oracle in terms of features.
MySQL has never been free, though there was a open source exemption.
What happened was PHP hit the web and people needed a database MySQL was "free-ish" and easy to install, so people started using it. PostgreSQL was, well, the installation file had a TOC. It was overkill for a lot of the hobby sites. MySQL continued to grow with the help of their "open source exclusion" in
We've begun the move away from MySQL also (Score:5, Insightful)
We've begun to move away from MySQL offical release also. Although we went with Percona rather than MariaDB.
Re: (Score:2)
"Submitted by someone who lost data with some of the earlier MariaDB releases." - AC
Submitted by a Percona shill, perhaps? Nobody praises consultants except consultants, and people who work for consultants. Who's to say it performs more reliably than the other fork?
Re: (Score:2)
Complete rubbish, if this were an argument about the morales in the record industry, you'd take the opposite tack. MySQL AB is the struggling artist, now out in the street. Oracle is the evil company making most of the money from repeat sales of struggling artist's music, already recorded. Percona is the DJ / Promotor type remixes the music, legally, and adds hip street cred (read marketing).
The truth is, OSS is supposed to be about removing the capital barrier, and giving the struggling an artist a reward
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: (Score:2)
ve begun the move away from MySQL also (Score:3, Insightful)
by C_Kode (102755) Alter Relationship on 01-22-13 5:10 (#42655885) Journal
We've begun to move away from MySQL offical release also
Who are you? Why do I care what C_Kode on slashdot does? I think you left out an important article, like the value of "we".
Re: (Score:2)
I'm not sure if I like you or not. Say something funny or quizzical.
What's that supposed to mean? Don't call me, I'll call you.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Because everyone cares what "drinkypoo" has to say.
Apparently many do, but even if they don't (or didn't) it would still be a valid question.
Re: (Score:2)
Migrating (Score:5, Interesting)
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 (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: (Score:3)
Uhm these are all very good questions, but here is a suggestion: verify this for yourself!
Re:Percona (Score:5, Insightful)
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.
Re: (Score:3)
So the developers of MariaDB took all their experience and knowledge that they obtained at Oracle while working on MySQL
No. Oracle purchased bits and pieces of technologies used by MySQL (the product), while MySQL (the company) was purchased by Sun. Then Sun itself was purchased by Oracle, which ended up owning both those previous pieces as well as the core of MySQL. In any case, none, or very little, of the technologies that go into MySQL were developed by or at Oracle. And even if something was, since MySQL, being GPL, comes with full blown, official patent licenses to all employed technologies to anyone who downloads, use
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
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? I don't care why they did it, it's underhanded and doesn't speak well to the character of those people.
Yes they did. Just like game developers who go to a different studio and create competing games, a doctor who goes to a different hospital to treat patients, or a truck driver who goes to a different trucking company. All of these people changed jobs and are in direct competition with their previous employers. I find their character to be of a much better quality than yours.
Re: (Score:2)
Here's what worked for me on debian. See https://kb.askmonty.org/en/how-can-i-upgrade-from-mysql-to-mariadb/ [askmonty.org]
Now install MariaDB.
https://kb.as [askmonty.org]
Ha Ha (Score:5, Insightful)
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: (Score:2)
The lesson here is: Don't let Oracle touch anything open source, or you're going to be forking in a year or two
Re:Ha Ha (Score:5, Insightful)
Update: 01/22 14:01 GMT by LarryEllison: (Score:4, Funny)
Why not... (Score:1, Redundant)
Just move to PostgreSQL and be done with it?
Database? As part of an operating system? (Score:3)
Why is *any* database a part of an OS? This isn't required functionality. It isn't even day-to-day useful as a browser, or a word processor.
After installing the base OS, a distro can offer to optionally install packages - such as a database - but I don't see why that choice should be limited to just one example. Make both MySQL and MariaDB available, and any others you want.
Re: (Score:2)
Why is *any* database a part of an OS? This isn't required functionality. It isn't even day-to-day useful as a browser, or a word processor.
If their components use it, it's part of the OS. If their components don't use it, it's not part of the OS just because you say it is; it's simply bundled with the OS. If they use it then they need it and your objection is invalid. If they don't use it, then it's not part of the OS and your objection is invalid. Either way...
Re: (Score:3)
Well I'm sure part of the issue here isn't whether it's technically "part of the OS", but rather a question of the repositories. Since Linux distros these days generally include a package manager linked to a set of official/supported repositories, anything in those repositories becomes, in a sense, part of the operating system that they're distributing.
Fedora has to decide what they'll include in their repositories, what they'll treat as "supported", and what they'll list as "deprecated". Sure, you can g
Re: (Score:2)
Re: (Score:2)
It is understandable that package management systems could have a DB backend.
=> It's understandable that a database might be part of the OS.
Even if it's not noticeably so (i.e. not a standalone package) then there's almost certainly an ad-hoc one hiding in a statically linked library anyway. Which is the less preferable option, IMHO, there's really no need to roll-your-own DBMS any more.
slashdotted? (Score:3)
Not necessarily (Score:1)
Re: (Score:2)
-1 redundant (but the rest of your post is +1 insightful, don't worry)
Who trusts Monty Widenius? (Score:3)
MariaDB is Monty Widenius' fork after leaving Oracle. MySQL is in Oracle's hands in the first place because Widenius sold MySQL to Sun. The man responsible for MySQL is also responsible for the fragmentation of the community into a bunch of forks with growing incompatibility problems.
Re: (Score:2)
Remember that MySQL was sold to SUN, not to Oracle so he had possibly no idea or no power to stop SUN being acquired by Oracle.
Re: (Score:2)
If you sell to one tech company, you're buying into subsequent sales of that tech company. Acquisitions happen all the time--Oracle buying Sun surprised no one, and Widenius didn't give a shit because he got a big payout. Now he wants to repeat it.
Re: (Score:3)
Besides MySQL, MariaDB and Percona, there's Dribble that's actually a viable fork. One's official, one's competing by the original founder, one's got all the experts at clustering, and one's just kind of there as well. So now, instead of one weak-ass database, you have four that are mostly the same but not identical, which will bite you in the ass at some unspecified point in the future.
Back when it was just MySQL, it was a reasonable choice because it had known strengths and weaknesses. Now you've got s
Don't do it (Score:1)
I use mariadb in a production situation and actually regret the move from mysql. Mariadb is cool or at least as "cool" as any mysql variant can be (bias: I'm from a postgresql background and tend to choose that for any personal project). But it has some stability problems that I didn't have with mysql. I know how to crash any mariadb server (though it'll just restart) with a handful of queries (provided I have table creation rights), and yes, I filed a bug report. Over 6 months ago. (I also have some s
nice move (Score:1)
I think this will be good (Score:1)