There is a bunch of posts on Planet MySQL this week about RAID.  This comment from Kevin Burton really kind of made me go “huh?”.

You?re thinking too low level. Who cares if the disk fails. The entire shard is setup for high availability. Each server is redundant with 1-2 other boxes (depends on the number of replicas). If you have automated master promotion you?ll never notice any downtime. All the disks can fail in the server and a slave will be promoted to a new master.

Monitoring then catches that you have a failed server and you have operations repair it and put it back into production as a new slave.

Someone has to think low level.  The key phrase in there is  you have operations repair it and put it back into production as a …

Jeremy retorts that RAID is alive and well in the real world:

Kevin Burton wrote a sort-of-reply to my call for action in getting LSI to open source their CLI tool for the LSI MegaRAID SAS aka Dell PERC 5/i, where he asserted that ?RAID is dying?. I?d like to assert otherwise. In my world, RAID is quite alive and well. Why?

I should note that I said:

I?d like to assert that in 3-5 years RAID will be a thing of the past.

I’m not saying it’s dead now - but I do think it’s dying.

RAID is cheap. Contrary to popular opinion, RAID isn?t really that expensive. The controller is cheap (only $299 for Dell?s PERC 5/i, with BBWC, if you pay full retail).

… that’s the price of one HDD. You’ve just lost some IO there. Granted this isn’t a major issue but it all ads …

So, the whole world changed at dealnews when Yahoo! linked us. We realized that our current infrastructure was not scaling very well. We had to make a change.

The Problem

Even though we were using all sorts of cool techniques, the server architecture was really still just a bunch of web servers all serving the same content. In addition to that, our existing systems as the time used a pull method. When a request came in, memcache was checked, if the data was not there, it was fetched from our main MySQL server. So, when there is no data in the cache or when it expires, this was very bad. Like when Yahoo! hit us. Some cache item would expire and 60,000 users would hit a page and each page would try and create the cache item.

The Solution

I …

RAID is dying. Shocked? The prediction might be a bit early for some folks. It’s still somewhat conventional for some people to think that RAID is a conservative way to scale your IO.

I’d like to assert that in 3-5 years RAID will be a thing of the past.

Want some evidence? Google doesn’t use RAID. They’ve build a database infrastructure which avoids expensive and proprietary hardware controllers.

You could call it a redundant array of inexpensive servers.

Other scale out shops which don’t have access to such toys have built out sharded MySQL installations. LiveJournal, Flickr, Facebook. These shops are using RAID in some situations but they …

Dathan says that 128k Stripe Size is ideal for INNODB:

128K - this is really good for INNODB, you’ll see a huge boost in responsiveness by making your Stripe Size 128K. I had a 64K stripe size, and I was blown away by the improvement of 128K

I’ve only benchmarked 64k and 1M. Google is using a 1M stripe size. 1M was about 5x slower for our workload. I’m going to have to benchmark 128k.

Interesting that he recommends RAID 10. We’re using RAID 0 and just using a Redundant Array of Inexpensive Servers. If one fails we just promote another one as master.

The other day I blogged about the fact that I thought partitioning was broken in 5.1.18.

There does in fact appear a bug that was introduced somewhere between 5.1.17 and 5.1.18 which is causing MySQL to dump core.

I tried recompiling 5.1.18 from source and the problem remained. Installing a 5.1.17 source build fixed the problem and we’ve been online for almost 72 hours without a core dump. By way of comparison 5.1.18 wouldn’t stan up for more than a few hours.

I’m not sure I have a ton of time to debug the issue but I wanted to get the information out into the public.

We’ve been playing with partitioning in MySQL 5.1.18 from the MySQL AB community builds and noticed that the daemon will dump core every 5 minutes or so when under load.

Recompiling from source fixes the problem. Anyone else notice stability problems?

Apparently, there’s been an outstanding bug for nearly two years for MySQL to add support for millisecond storage in DATETIME and TIME data types.

A microseconds part is allowable in temporal values in some contexts, such as in literal values, and in the arguments to or return values from some temporal functions. Microseconds are specified as a trailing .uuuuuu part in the value. Example:

…

However, microseconds cannot be stored into a column of any temporal data type. Any microseconds part is discarded.

What’s this about? I have to admit that I’ve known about this problem for about the same amount of time (probably three years).

At Rojo we used BIGINTs as timestamps which provided millisecond …

This thought has been floating around my head for quite some time now and I finally bit the bullet and released it from the draft state it had been sitting in for too long: there are quite many similarities between Open Source Software (OSS) projects and most of today's popular Web 2.0 sites, but there is also one odd difference that I wonder about.

For both worlds, the concept of collaboration, participation and giving more power to their users is a key component. OSS projects need contributors for patches and bug reports, but also for feedback, translations, artwork, advocacy in order to be popular and healthy. The project's developers need to be open for suggestions, listening to their user base on where the project should be heading. They also usually strive for open standards …

This is a hack I’ve heard about a couple times now:

Paul wrote a script that reads from the logfile the queries that are going to be executed moments later. He parses the queries and constructs new select queries that populate the cache with the data that speeds up the upcoming writes. He claims, if I remember correctly, a three to four times speed-increase.

Here’s the problem in a nutshell. The master can write transactions in parallel but slaves can only write them in series. [1]

This means you have a lot of optimizations on the master (TCQ and NCQ being examples) that aren’t possible on the slave.

What this patch would do is precache the data so it’s already available in memory. Since you’re pre-reading the binary log you can run SELECTs in parallel on the SLAVEs so that the cache is …