Slashdot Mirror
MySQL 5.6 Reaches General Availability
First time accepted submitter jsmyth writes "MySQL 5.6.10 has been released, marking the General Availability of version 5.6 for production." Here's more on the features of 5.6. Of possible interest to MySQL users, too, is this look at how MySQL spinoff MariaDB (from Monty, one of the three creators of MySQL) is making inroads into the MySQL market, including (as we've mentioned before) as default database system in some Linux distributions.
If you check out the charts, the transactions per second are tripled from 5.5, when the threads approach 60.
Some people die at 25 and aren't buried until 75. -Benjamin Franklin
MySQL is rapidly approaching "who cares?" status. Oracle kills another one.
Organization? You must be joking..
Ironically is the direction MySQL should have gone after the 4.x branch. There's a whole heap of legacy baggage in the code base and Oracle -- since we know how good they're with legacy baggage -- decided to keep doing incremental changes to it (ever try putting CURRENT_TIMESTAMP as default on two fields with the second being ON UPDATE?)
The 5.6 line is actually using a lot of improvements handed back by companies like Google, which I think initally used it for AdWords and may still be using in some capacity.
If computers were people, I'd be a misanthrope.
Seriously, read the manpage or search the internet. Slashdot is not your command line argument support forum.
Further more, putting my question out there might just notify some sysadmins that their mysqldumped data might not be quite what they expected if they rely on a mix of storage engines' features for their various tables...
Idiot.
That won't work unless he knows what to search for. I'm not running the latest mysql. Maybe they neutered mysqldump, if so that would probably be dumb.
On the other hand if you're seeing stuff like "ENGINE=innoDB" in your dump but upon restore they're importing as myisam or whatever, you're being bit by an "issue" or "bug" or whatever where innodb isn't starting for whatever reason so mysql helpfully starts up without it and tries its hardest and creates the table using myisam seeing as innodb is dead. Look for "sql_mode=NO_ENGINE_SUBSTITUTION" to disable the "best effort" and look in the logs for why innodb won't start on the new server (who knows why). Its typical of the whole mysql philosophy that it'll try best effort at all times, even if that drives people of a certain outlook bonkers. I don't think you can google for "mysql philosphy" and get this potentially useful or potentially inaccurate opinion.
On the other hand if they neutered mysql to not store engine type that would just be moronic. It won't affect me when/if I upgrade to 5.6 because I store my schemas as part of the program sourcecode (not in the sourcecode, next to it, like running mysql somedb something.sql will create the table "something" requires if its not already there. In a way this actually would save effort when converting from one DB engine to another.
The existence of one anecdote that once happened to me years ago which I might not even be correctly remembering does not imply no other cause could exist. But its a start and better than the reply of RTFM noob.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I think you'll find that we're all moving to MariaDB these days. Thanks Oracle, everything you touch turns to shit.
They want to deliver vast amounts of information over Slashdot. And again, Slashdot is not something that you just dump something on. It's not a big truck. It's a series of tubes. And if you don't understand, those tubes can be filled and if they are filled, when you put your message in, it gets in line and it's going to be delayed by anyone that puts into that tube enormous amounts of material, enormous amounts of material.
That won't work unless he knows what to search for. I'm not running the latest mysql. Maybe they neutered mysqldump, if so that would probably be dumb.
Interesting: did mysqldump ever support the storage engine specified? I dumped & loaded some DBs on the replication server and ... all InnoDB. Huh, some of these ought to have been MyISAM. Looked into it further, and it appears dependant on the default-storage-engine= in my.cnf.
However, specifying --xml to mysqldump forces it to specify the storage engine. I haven't yet looked into how to load the XML file(s) into MySQL (for that I'll read man pages / search internet).
I keep thinking that I'm missing something obvious but ... not finding it. Almost convinced it's a bug / oversight.
On the other hand if they neutered mysql to not store engine type that would just be moronic. It won't affect me when/if I upgrade to 5.6 because I store my schemas as part of the program sourcecode (not in the sourcecode, next to it, like running mysql somedb something.sql will create the table "something" requires if its not already there. In a way this actually would save effort when converting from one DB engine to another.
The existence of one anecdote that once happened to me years ago which I might not even be correctly remembering does not imply no other cause could exist. But its a start and better than the reply of RTFM noob.
Restored / loaded tables have the default-storage-engine in effect.
And the earlier poster - did he think concern over the storage engine in a mixed environment, or replication, are noob topics?
Here's a sample created by mysqldump:
CREATE TABLE "test" (
"kkeeyy" int(11) NOT NULL AUTO_INCREMENT,
"a" varchar(10) DEFAULT NULL,
"b" varchar(10) DEFAULT NULL,
PRIMARY KEY ("kkeeyy")
);
Note that no storage engine is specified.