Eric Bergen

I sat down about 20 minutes ago to write a blog post that included a link to the slides of my EMT presentation. It turned into a long post about the presentation, how I feel EMT was received and my feelings on presentations in general. Here is the short post and the link to the slides.

The MySQL conference always inspires me to write so expect a longer post in a few days.

This week throngs of MySQL developers, users, and enthusiasts descended on silicon valley. Apparently the valley’s cooling system can’t keep up because as they arrived the outside temperature went up into the 90s (32s for those of you who choose to use a sane temperature measurement system). I’m not attending the conference this year but I almost wish I was to get some of the air conditioning. It’s supposed to cool off and rain on Saturday. As the brain power leaves I suspect the valley is going to cool and moisture in the air will condense into rain, or tears.

I bet you thought this post was going to be about Oracle and Sun, sorry. I think the weather is more interesting.

I was reading through the manual and noticed that myisamchk parallel recover option is still listed as beta code. The feature was added in 4.0.2 which was released in july 2002. This means it’s been in beta longer than gmail

While updating the mirror last week I was surprised to see that the newest MRU MySQL release is numbered 5.0.79. Previously enterprise releases had even numbers and community releases had odd numbers. I posted the question in #mysql-dev and HarrisonF was kind enough to explain it all.

MySQL 5.0 is running out of version numbers. There are limitations in mysql_get_version(), the executable comment syntax, and other places that mean MySQL can only have two digit release version numbers. MySQL Enterprise has started using odd and even version numbers to extend the life of 5.0.

This raises a few questions. What will happen to 5.0 when it runs out of release numbers? Is community going to be sacrificed to give enterprise more versions to use? Are the version restrictions going to be fixed in the future? For example if a feature is implemented in a community release the executable comment version syntax isn’t suitable for preventing it from being executed in a newer enterprise release because the version scheme doesn’t differentiate between enterprise and community.

I think this is now rock solid proof that there were too many features packed into 5.0 and it was released too early. I hope there will be more major releases in the future with fewer features so these problems are prevented. By the way the advanced vs pro enterprise binaries add a whole new layer to the MySQL version issues.

EMT provides an easy way to gather common system performance metrics, as well as providing a simple plugin-based interface to collect custom application-specific metrics. This data can be viewed on the servers that are collecting it or, through the output handler interface, be sent to centralized servers.

I started building EMT because it was very difficult to do ad hoc comparisons of performance metrics when trying to diagnose why systems are or were overloaded. Often times the existing monitoring was only setup to gather data from the operating system such as cpu or network usage. The solution was always to build something quickly by hand, run it for a while, and hope it gathers something meaningful. That’s OK for solving one problem but what about the next time?

EMT runs a set of very light weight scripts out of cron that in turn execute commands and parse data from them. The data can be stored locally (highly recommended) or shipped off to be aggregated on central servers, or both. The power of EMT is really in the local storage. The emt_view command can be used to compare any or all metrics from the system to look for patterns. Example usage can be found in the manual. I highly recommend checking it out.

The installation instructions say to grab the source from svn and use the included script to build an rpm. That’s still the recommended way but I’ve created a snapshot of the source and starter rpm for this blog entry. In the future I’ll setup a more defined release process.

Now for the bad news. EMT is still under heavy development. The view code and how instances work are is going to change a lot before I release it. Things like viewing data from different instances of running programs doesn’t work. That being said it shouldn’t destroy your servers or steal your children if you decide to run it in production. Proven Scaling and a few of our clients have been using it for quite some time with very few issues. If there is enough feedback I’ll bump the version to 0.3 and start stabilizing it for a real release.

If you want to become involved with the project there is a google code page and a google group for discussion. I’ll post development updates to the group page. If you find any issues please report them on the google code issue page.

The #mysql-dev irc channel on freenode was created with the idea of getting the community people more involved in active discussion about mysql internals and development. When the channel was first created this happened for a few weeks and I was pretty happy to be able to observe and participate in the discussion. Now it’s mostly idle.

It seems that some people at Sun think there is still active discussion or internal developers paying attention to the channel because the GSoC web page directs people to #mysql-dev as a point of contact. The problem is there isn’t anyone there answering questions. I’ve seen quite a few people over the past few weeks ask questions that have gone unanswered. I think it’s time to restart the movement to open development and using #mysql-dev for discussion.

About a year ago I upgraded from a MacBook to a MacBook Pro 17″ to get the additional screen space. I used to work a lot from my couch before the upgrade. It gets tiring work from a desk after about 8hrs. The upgrade caused some problems though. I opened up my shiny new MBP, sat on the couch, leaned back, put it up on my knees and bam! the screen crashed down on my fingers.

I took it to the apple store who checked it and told me to call apple care. I called apple care from outside the apple store and after explaining the situation they agreed to service the computer to tighten the hinges. I got my MBP back with slightly tighter hinges but no where near what I was used to on my MacBook. For the past year or so I haven’t been able to work from the couch like I want.

When apple revved the 15″ MBP I checked to see if the 17″ style hinges had made it in the 15″ MBP. They had. I was crushed and kept my eyes out for a new brand of laptop. I hate running linux on a laptop and windows is out of the question, so I waited. When Apple released the new 17″ MBP I read the reviews. There was little mention of the hinges except that it opens further than the old 17″. I started watching the apple forums for reports of loose hinges and found a lot of reports from 15″ MBP owners. Feeling hopeful I went to the Apple store to see if the hinges on the new unibody 15″ are as bad as they are on my 17″, they were.

That was about a week ago and the new unibody 17″ wasn’t in the stores yet. I noticed apple changed the shipping time on their website down to 3-5 business days. I thought if the shipping time is down they must have some in stores. I went back about a week alter and they had some on display. The hinges on the unibody 17″ are significantly tighter than those on the unibody 15″ and the old style 17″. So I bought one, and it’s great. I typed this from my couch without smashing my fingers.

Thank you Apple for learning from your mistakes (although you should have learned from the old 17″ and not pissed off all the new 15″ unibody owners). The hinges on this new MBP are almost perfect and the extended battery life isn’t too shabby either.

A few months ago I got a strange email from one of my clients that contained two very simple looking select queries. The only difference between the two queries is that one included the distinct keyword and the other didn’t. The strange part is that the query that used distinct returned zero rows. I spent a few days narrowing down the clients data into a small test case then created a generic test case from that. I also traced the problem to the code that decides which index to use for a group by loose index scan which can be used to resolve queries using distinct.

The example can be found in the bug and in this sql file. My patch was a step in the right direction but not complete enough to solve all the issues. Since this isn’t a crashing but I was tempted to make this blog post into one of those sql quiz questions but decided to be nice instead. Feel free to use the sql file to fool your friends though.

If you read a lot of emails from exchange users this is a must have. It fixes the super small fonts that exchange seems to like to send by default. Simply run this in a terminal:

defaults write com.apple.mail PreferPlainText -bool TRUE

I’m not sure why apple made fixed width fonts a preference pane option and decided to leave plain text out. Having both seems seems important to me.

The rotating plate that became a standard feature on most microwaves some years ago were a great addition. They enable food to be cooked more evenly. The bowls and mugs best for microwaving have handles on them to protect your hands from the freshly heated contents. If you build microwaves please bring these two features together and build a microwave that stops the rotating plate in the same position it started in so hands aren’t burnt trying to rotate the mug to grab the handle.