What a surprisingly busy week.

Spent quite a lot of time tracking down a linking problem on Itanium. It appears that GNU ld 2.14 has some serious deficiencies. GNU ld 2.17 (the current stable release) does fix the problem. Unfortunately, the last supported version of GNU ld on RedHat AS 3 for Itaniam is version 2.14.90.0.4.20030529 - which clearly cannot contain the fix which was written in November of 2003. I suppose what to do is now a decision to be made by someone else.

Also spent some time with Federated - Bulk insert support within the storage engine and also how to make Federated play better with transactions and network overhead. Have to put together a new WorkLog entry if I cannot find a relevant one. I need to work on writing better changeset comments. Ingo says, and I have to admit that I agree a bit, that my comments assume that the reader is familiar with the code and bug in question. I need to make them a …

So, I mentioned in my MySQL Cluster post that I found out that cluster and joins don’t get a long too well. There are a couple of tips I have for using joins or replacing them with other techniques that I thought I would share.

Here are some things I keep in mind when using the NDB engine. These may apply to the other engines as well.

1. Test using the NDB engine. Testing against another engine is not adequate.
2. Avoid JOIN if you can, test often if you can’t
3. Avoid subqueries always
4. Select using primary keys when at all possible. Always select using a key.
5. Be sure to include both your where and order by columns in your keys.

Try your join from several directions.

Sometimes, the way you join can affect the engine. This is more …

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 …

Pawel Barut has published the 48th edition of Log Buffer, the weekly review of database blogs, on his blog, Software Engineer Thoughts. Coskan Gundogar takes it up next week, but the schedule is quite open after him. Log Buffer wants you! Read the Log Buffer homepage and get in touch if you’d like to [...]

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 …

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?

• 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). The “2x” disk usage in RAID 10 is really quite debatable, since those disks aren’t just wasting space, they are also improving read (and subsequently write) performance.
• Latency. The battery-backed write …

In an effort to reduce the number of open tabs I have in Firefox, I have some rather interesting MySQL-related resources that I think the rest of Planet MySQL will quite enjoy.

• Linbit (the makers of DRBD) and MySQL are in a partnership now, and Irwan Jamaluddin, a systems adminstrator at one of the only Linux support companies in Malaysia, has recently blogged about his journey with DRBD and MySQL. The operating system base is RHEL 5, and there is a step-by-step guide on how he got it working. From what I gather, its a cut-n-paste tutorial, not something I’ve verified, but I’m sure I’ll refer to it when I want to play with DRBD.
• MySQL Basics in Pictures. Granted they’ve used an odd version of Linux for the basis of the tutorial, but that doesn’t affect the quality of the …

Jan Kneschke works for the MySQL Development Team and is the author of the very popular lighttpd web server. I recently had the opportunity to ask him a few questions about himself and his work.

In our last installment, we looked at how to write data into a storage engine, now lets look at updating it.

To update data you need to first know that it exists. To do this MySQL reads the rows that need to be updated, either by index or scan read. Since we have already spoken on scan reads, we are going to look at updates that occur that need to scan the entire table. MySQL will start up a read and do the folllowing:

rnd_init()
rnd_next()
rnd_next()
rnd_next()
update_row()
rnd_next()
rnd_next()
rnd_end()

In the above example, MySQL find four rows in the table. The third row is matched for an update. The engine writer doesn't have to do to the predicate test themselves (aka ... UPDAT E A SET b=5 WHERE a=3, the engine writer doesn't need to worry about matching the a=3). The …

I recently saw the Planet MySQL post Five months with MySQL Cluster by Brian Moon.

Thought I’d add my 5 cents worth (Australian’s don’t have 1 cent coins any more to make 2 cents worth)

Firstly, it’s great you wrote about your experiences in moving to MySQL Cluster. I think more people should.

Joins

“We used a lot of joins. We learned (later) that joins in the cluster are not a good idea.”

MySQL Cluster’s number one strength is Primary Key Lookups, it’s very good you learned that joins (especially say 5-6-7 table joins) are not a good idea, it is not a strength, and certainly not scalable to thousands of queries per second.

Rewrite

“We rewrote our application (basically, our public web site) to use …