I’ve been working on BUG#17928, which is all about “testBackup fails in error handling testcases” which appeared after we merged in some work to the 5.1 tree (which is okay in 5.0) that changes some things in the way that online backups are done in NDB to better support recovery in the event of various types of failures and various times in the process.

Anyway, not all systems are affected by this bug… I’m at least reproducing some of the failures on my laptop and have spent the past while in the depths of the BACKUP and NDBFS blocks trying to work out what’s going on and why we’re hitting this assert.

NDBFS is an interesting block as it’s the file system interaction for NDB - so we’re doing things that could take an arbitrary amount of time. We don’t like waiting for those sorts of things in cluster, so we go on and do other work.

…

The development of a prototype of SQLbusRT has started.

This first version will contain an implementation of all the components in the current architectural design. However, these components will not contain much functionality yet. The interfaces will be designed, but the messages being sent between the components will mostly be hardcoded.

This first version will be used to do some first measurements on the real-time characteristics of the architecture. As soon as the coding has finished, a link to the package will be posted here.

After doing the first measurements, the results will be posted here as well.

If you are interested in specific measurements, please let me know. I might include them in my research.

Blog: http://sqlbusrt.blogspot.com/

Project website: …

MySQL Server has tons of variables which may be adjusted to change behavior or for performance purposes. They are documented in the manual as well as on new page Jay has created. Still I see constant confusion out where which of variables apply to storage engines only and which are used on SQL layer and apply to all storage engines.

Lets start with a bit of history. When MySQL was just written there was not that many storage engines - there was MyISAM for disk tables and HEAP for in memory tables. So first MySQL versions did not bother naming variables with storage engines prefix. This is why we have key_buffer, not "myisam_key_buffer" for example. The other excurse Monty used to make was - it is not really MyISAM specific. key_buffer was also used by now retired ISAM storage engine and could be used by something else. True in theory but in practice for years now when …

AnandTech published Intel Woodcrest preview benchmarks which have some numbers for MySQL as well.

From these numbers performance looks great and it looks like finally Intel has something to respond to AMD Opterons on Server market. Now competition heats up and we'll see what AMD will have to respond. As Opteron did not have serious updates for a while I guess there is something on a way.

Same site publishes Core vs K8 architecture comparison which is very interesting reading.

This article also looks at performance of Irwindale based Xeon and Sun T2000. Results are close to the ones I had in …

I created a new MySQL Forge wiki page entitled "Server Variables" and have started adding content to it. My plan for the page is to get as much information about all the specific server variables as possible, including recommendations for usage, specifications on what is global vs. per-thread, whether it is specific to a storage engine, etc.

I've gone ahead and created a linked page for the key_buffer_size variable, to give folks a starting point for contributions to the pages. The point is not to duplicate the content in the excellent MySQL manual. The point is to expand on that content with community experiences and advice and give a single place to go for tuning information.

Got some good experience on how one server variable affects the server? Put it in there! Got experience on how …

I've fallen victim to the flashing red lights of doom.  Yes, Virginia, my Xbox 360 has died.  And let me just say requiring $129 to fix a known manufacturing issue after 90 days is a total rip.  However I have my stick it to Microsoft card in the form of a 1 year service plan purchased with my Xbox.  So I?m off to find a service center and renew my service contract!

It’s been a hectic week, and it’s only Tuesday.

My wife and I recently made a decision to move on from MySQL. My passion is software development, and my experience doesn’t lend itself well to database development. Therefore, I’m returning to Amazon on Monday, if my intel is correct.

Through a strange series of coincidences, my resume was submitted to the same group which I left 14 short months ago. I will be returning to HTML, JavaScript, Perl, shell script and a tad bit of Java development.

It has been a pleasure working for and with MySQL AB. They make a wonderful database, and their support folks are top notch. I’ll miss them all. But heck, I can stay in touch just as easily as ever. That’s one nice thing about working in a virtual company: you learn to keep in touch by any means necessary.

The roses are blooming. The lawn is mowed. Summer vacation starts Real Soon Now™, and I’ll be taking …

just a few days before reports surfaced that hp would be cutting back on telecommuting, mysql was cited in an article about great teams because we operate without a headquarters. (not quite true, except relative to most companies.)

working from home is great for me, but i can understand how a boss with control issues couldn?t stomach it.

Please share good ideas implemented poorly you have seen.

For example, in the past 24 hours I have come across 2 such beasts:

1) A company doing vertical scaling based on username. Unsurprisingly, they found that 70% of their users had usernames beginning with 1 of 2 letters. A better idea? Do it by last 2 digits of a user id. That way, even though users are created and perhaps deleted all the time, the distribution is effectively random. Language is not.

With 2 significant figures, you can divide vertically many different ways — 1 large table of all the uids, 2 tables of uids ending in 00-49 and 50-99, 4 tables, 10 tables, 25 tables, 50 tables, 100 tables. This eliminates the need for a separate table for each user.

For example, the online dating site I work for uses this method for messaging. So a user’s inbox is just one part of a table. If the user has uid 12345, their “Inbox” is the result of …

I’m sure most would agree when one does a programming mistake they are a lot of times trivial mistakes. However when one stares at the code for long periods of time we seem to go blind and then in the process of frustration loose all logically thinking as to what could be causing the problem. Here is one such problem with arrays.

ShareThis