I sort of agree with Jeremy Cole. This new marketing push using Planet MySQL seems like a cheap advertising stunt.

First, what’s with the highlighted post? Why is it highlighted? Seems like and advertisment.

Which brings up a number of significant questions:

1. Where’s my cut? I write content that’s pushed to Planet MySQL which wouldn’t be attractive for running ads if it wasn’t a collection Plof intelligent authors writing about MySQL.

2. Can competitors run ads on Planet MySQL? Can Oracle run an ad on INNODB? Can Solid run an ad?

Planet MySQL is a community oriented site. Seems like we should keep it that way.

…

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 …

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 …

This is perhaps the first I've ever heard someone credibly say that Microsoft must now live by open source's rules, or suffer. As Marten Mickos (CEO, MySQL) told The Register, If you won't work with MySQL, PHP and Ruby then you are lost.Wow. Say those same words (and maybe add in "Linux," "Apache," and others) five years ago and Microsoft could have legitimately laughed. But no more. Microsoft must partner with open source companies and communities, or it's business will tank. Not immediately, of course, but imagine a world where Microsoft is an island of proprietary software, surrounded by the... READ MORE

I know this is a bit old, but I’ve been trying to catch up with all the new stories after a conference, vacation, broken laptop and loads of work.

RedHat Enterprise Linux 5 (RHEL 5) was launched some months ago. I’ve never been a big fan of RedHat in terms of technology. I guess is quite good now, but RPMs scared me years ago and I’m not over it yet.

One of the things I liked is that RedHat proved that the KISS principle doesn’t only apply to software development, but to marketing and sales too. This is their new SLA (service level agreement). Can’t be simpler.

That reminds me of MySQL and their all-you-can-eat support package (MySQL Enterprise Unlimited), easy to understand and with a …

And then there were two (software patent deals with Microsoft). Today, Xandros made its first newsworthy announcement in 10 years and indicated it has capitulated to Microsoft. I love how Microsoft tries to blur the lines between its patent folderol and interoperability agreements (notice how it tries to obscure this in the press release, talking about Novell, Xandros, XenSource (no patent agreement), JBoss (no patent agreement), Zend (no patent agreement), etc. They talk about them all as if they're the same thing, but they're not. The smart companies are buying into interoperability, not FUD. Yet Bill Hilf persists:Customers win when... READ MORE

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 …