Well… there’s been some work. Even some in-progress patches. Being involved with this has just perfectly refreshed my memory of why I left the platform. Oh my it’s a horrible, horrible platform. Everything from UI to API… ick.
Expect something around soon….
This month I continued my Performance Analysis talks at the Local NY MySQL Meetup. Previous discussions can be found here.
Our focus was a more in-depth look at gathering and reviewing MySQL Status and your applications SQL statements using MySQL Proxy. Even after preparing the slides over the weekend Jan added more functionality that was particularly interesting. So today while addressing a client issues I further extended this work to do even more funky monitoring.
Today’s monitoring.lua script does:
This month I continued my Performance Analysis talks at the Local NY MySQL Meetup . Previous discussions can be found here . Our focus was a more in-depth look at gathering and reviewing MySQL Status and your applications SQL statements using MySQL Proxy .
After an absence of one year, I've taken the bold step of
submitting a couple of proposals in the call for papers for the
2008 MySQL conference. It would be great to get something in,
being part of the event, and getting to meet many old MySQL
Community friends (and former colleagues, of course) again from
around the world.
While truly being on the outside now (just MySQL AB wise, as I'm
still involved with the product through Open Query), I
suppose I do have the advantage of having some idea about what
the program gang will be looking for, what type of proposal has
the best chance for being both picked and being actually
interesting for the attendees. So I'm hopeful, but I know that
there'll be a lot of other good proposals also... the competition
will be tough.
Progress on High Performance MySQL, Second Edition is coming along nicely. You have probably noticed the lack of epic multi-part articles on this blog lately – that’s because I’m spending most of my spare time on the book. At this point, we have significant work done on some of the hardest chapters, like Schema Optimization and Query Optimization. I’ve been deep in the guts of those hard optimization chapters for a while now, so I decided to venture into lighter territory: Backup and Recovery, which is one of the few chapters we planned to “revise and expand” from the first edition, rather than completely writing from scratch.
The following is the current list of available JDBC 4.0 drivers:
And this has been said before but I can’t help but say it again…
In the latest Oracle Magazine, Tom Kyte and Ari Kaplan’s columns both tout one of 11g’s new features – the “server results cache” or “query result cache” (as the authors referred to it, respectively) . They both describe it as a “great new feature”. Neither happens to mention that MySQL has had this since version 4.0. It rankles me. It looks like there are a lot of truly “great new features” in 11g; let’s give credit for this one where it’s due.
This release is part of the unstable 1.5 branch. Its features will ultimately go into the stable 1.6 branch. You can download it from the innotop-devel package.
The major change is I've ripped out the W (Lock Waits) mode and enabled innotop to discover not only what a transaction is waiting for, but what it holds too. The new mode that replaces W is L (Locks). My last article goes into more detail on this.
This article shows you how to use a little-known InnoDB feature to find out what is holding the lock for which an InnoDB transaction is waiting. I then show you how to use an undocumented feature to make this even easier with innotop.
The following is the current list of available JDBC 4.0 drivers: