Slashdot Mirror

In the latest news around the mysql ecosystem, one thing that was mostly ignored was that TokuDB went open source, adding an important new storage engine to the table. And comparing TokuDB vs InnoDB performance it could matter a lot more (at least, for more kinds of workloads) than switching from MySQL to MariaDB or Percona Server.

This whole thing about Java being the issue annoys me - if you take a broader look at the whole ecosystem.

Take a look at no more than 2 weeks ago with CVE-2012-4414 for example...

This is a MySQL security bug where any authorised DB user can arbitrarily inject SQL in the binlog used for replication...

For those that don't know Oracle has recently (over the past year) moved the majority of their bugs database internal only so that inhibits discussions for a start and on top of that they no longer publish test cases for fixes ... it looks like they might be going into an internal/tests directory but that isn't provided in the GPL tarball they provide.

However the curiousness doesn't stop there - if they are still writing test cases for code as opposed to just changing stuff willynilly they don't seem to be writing them very well.

When the Percona guys were merging from the upstream code they used the test case that the MariaDB team put together for this CVE - since there is no test provided by Oracle as previously mentioned.

They naturally expected the test to be fine seeing as Oracle claimed the CVE was fixed in 5.5.29 but shock horror it failed.

They ended up merging the MariaDB fix instead.

Given that what makes you think the rest of the code is *really* like and why that Java fix recently introduced a new bug and so on...

Ah well in the meantime FESCO has accepted the proposal to replace MySQL with MariaDB in Fedora 19 which is something that Oracle weren't too pleased with...

That Oracle response was prior to the FESCO vote by the way - time to get the popcorn methinks!

What "proprietary" means to me here is "untested and likely to be very buggy". I've helped people cope with losing terabytes of lost data eaten by Intel's early X-25 models, when they first played this game. The “BAD_CTX 13x Error” AKA 8MB size bug sucked; so did their flat out deception about the drive's write cache in order to cook benchmark results.

At least they're honest about which drives do and don't care about cache integrity now, and firmware reliability of the models that do that right (the 320 and 710 series) seem pretty solid now. But since getting firmware right for a complicated SSD takes a lot of field testing, that they've switched to this new proprietary controller means the odds of data loss due to firmware bugs on this model are going to jump right back up again. Firmware seems to be the least reliable part of a typical SSD, so brand new firmware surely equals very high risk, even if the hardware is executed perfectly. Doesn't matter how well the flash cells work if you hit something like the "oh, the drive reports it's 8MB now" sort of bug--and that problem haunted multiple generations of drives in Intel's past firmware before they exorcised it. Now it seems they want to start over again. Didn't like that movie the first time, would not watch again.

http://www.mysqlperformanceblog.com/2006/08/09/cache-performance-comparison/

This is from Peter Zaitsev who managed the High Performance Group within MySQL until 2006...is he a liar too?

The server I used was anything but modest.

Check out High Performance MySQL by Schwartz, Zaitsev, Tkachenko, Zawodny, Lentz and Balling

http://oreilly.com/catalog/9780596101718

A couple of the authors are the guys that run http://www.mysqlperformanceblog.com/, which is itself a good resource for MySQL scaling.

There may need to be some minor rethinking of controller throughput for read applications on smaller data sets for SSD. But right now, I regularly saturate the controller or bus when running sequential RW tests against a large number of physical drives in a RAID{1}0 array, so it's not like that's anything new. Using SSD just makes it more likely that will happen even on random workloads.

There are two major problems with this analysis though. The first is that it presumes SSD will be large enough for the sorts of workloads people with RAID controllers encounter. While there are certainly people using such controllers to accelerate small data sets, you'll find just as many people who are using RAID to handle large amounts of data. Right now, if you've got terabytes of stuff, it's just not practical to use SSD yet. For example, I do database work for living, and the only place we're using SSD right now is for holding indexes. None of the data can fit, and the data growth volume is such that I don't even expect SSDs to ever catch up--hard drives are just keeping up with the pace of data growth.

The second problem is that SSDs rely on volatile write caches in order to achieve their stated write performance, which is just plain not acceptable for enterprise applications where honoring fsync is important, like all database ones. You end up with disk corruption if there's a crash, and as you can see in that article once everything was switched to only relying on non-volatile cache the performance of the SSD wasn't that much better than the RAID 10 system under test. The write IOPS claims of Intel's SSD products are garbage if you care about honoring write guarantees, which means it's not that hard to keep with them after all on the write side in a serious application.

Many of us MySQL users see your Postgres question the same way: why use Postgres?

Because MyISAM, which is what most MySQL users use, is not fucking ACID compliant.

Take a look at the potential problems. Take a look at recommended use cases: "Tables which contain read-only data, throw-away data, data which can be quickly re-generated." Are you bloody kidding me!?

I can't believe my eyes when I read questions (or posts) such as the above. Because it betrays your huge ignorance. Every man and his dog has heard of MySQL and is probably using it, true. But it's also true that most of them have no bloody idea of what ACID is or why it's desirable, or that MySQL with its MyISAM tables goes completely happy-go-lucky on the whole concept. These are the same people who probably don't bother using foreign keys, or have never even heard of transactions, or can't think why they'd need them.

Sure, MySQL offers InnoDB, which is supposed to rectify those issues. But how does it go about it, may I ask? Why, take a looksy. It's an entire bloody SECTION of the manual, which goes to great lengths to explain all kinds of issues and exceptions to the rules and whatnot. Summary: "It locks rows like this, except if it's a full moon then you have to blink your left eye every five seconds, and if you're doing a particular SELECT you need to stand on one leg, except on Fridays when it's the right leg."

Now compare with the Postgres manual page describing their ACID implementation. It's a couple of pages, keeping things clear and simple, so that anybody can understand them.

Not to forget that if you want InnoDB you give up full text search capabilities. And you ask why we should use Postgres? Really?

MySQL has lowered the bar for complexity of use. But in doing so it has facilitated DB access to a whole bunch of people who don't have any idea what they're doing, or don't really care about data integrity. It's fast and it works most of the time so it's alright, yes? Yes, granted, nobody will care much if your personal blog goes tits up because of MySQL. But I expect people will care if a database in which data actually counts for something has problems. And in such cases I expect people will want a real database.

It's not necessarily true that MyISAM is faster actually.

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

I suspect if you're manually copying around the db's internal files you're doing it wrong. That's not the proper way to do replication, backups, or just about anything. Care to elaborate on what you were trying to do with the db's internal files?

Dumping SQL statements for backup is not really practical with big databases. It would takes days to restore.

Read more in this blog.

No, the Mysql version Google uses is free. They release patches periodically and are generally Mysql and Innodb's best friend ( along with percona) Innodb recently released a new official version of their engine containing the google code.

You can find Google's latest Patch here

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

• mysql forums post: optimize IP range join - postgresql is 496 times faster
• original mysql performance blog post

I'd really like to know your response to the post MySQL Quality of old and new features.

Unfortunately all the MySQL 5.0 advances makes it slower than MySQL 4. Lots of hi-load webapps don't need to use triggers, but very speed sensitive. Seems like 4.1 can save up to 10% time against MySQL 5. Websites typically performs lots of simple queries so this is a big point for me to keep MySQL4 on my shared hosting servers. If you need a triggers - go ahead, buy a dedicated server and install MySQL5.