It's finally ready -- the new stable version of the innotop MySQL and InnoDB monitor. Version 1.4.0 brings you new features and enhancements I think you'll really enjoy.

Now that I have innotop hosted on sourceforge, I'd like to use the tools they provide, especially the forums and mailing lists. I've set up an innotop-discuss mailing list, which I hope you'll find a better way to get support than posting in the comments on this blog. I think I will close comments on all innotop-related articles I post, because I can't keep track of feedback in so many places.

innotop 1.3.5 is the latest release of the increasingly popular MySQL and InnoDB monitor. I recommend everyone upgrade to this release. Aside from incomplete documentation, it's close to a stable 1.4 release (I'm counting on you to find the bugs!). There are many significant new features since version 1.3, which make it more powerful and easier to use.

I just made a snapshot of the development branch of the innotop MySQL and InnoDB monitor, and released it as version 1.3.0. This code will eventually become version 1.4. Here's what's new.

I've made the 1.0 release I promised yesterday. I am very happy to declare innotop production-ready and stable. In this article I talk a little bit about my plans for the future, and look back to the project's humble beginnings as a script I ran inside watch. Check out the screenshot! OMG!

A couple of weeks ago I submitted a request to open a new project on Sourceforge for the innotop MySQL and InnoDB monitor. I want to make it easier for others to collaborate, especially package maintainers. Yesterday I got word of its approval. I have done a quick-and-dirty import of the source code into its new home, and I'm now continuing work on the next major version, which I've been working on for about six weeks. This post is about Sourceforge, what I've gotten done, and also to ask for your help.

It's been a while since I released an update to innotop, but I have not been idle. I'm currently working hard to add major new features and functionality. Here's a quick list of what's coming.

A kind soul has contributed a Debian/Ubuntu package for the innotop MySQL and InnoDB monitor. Thanks Sebastien Estienne!

I recently tested installing innotop on Microsoft Windows. There was one slight glitch, but I changed a couple lines of code, and now it runs out of the box under ActivePerl. Version 0.1.156 contains those changes for Windows compatibility.

I recently published an article on O'Reilly about monitoring tools for MySQL. Of course I believe innotop is the best in its class, so I mentioned it. But I also recently added some features to innotop, and made a stability fix too.

Version 0.1.152 of innotop is a small maintenance and bug-fix release. I found some more ways to make it deal with garbage input without crashing. Of course, that means it's harder to find errors because it doesn't complain and let me know they exist, but that's what you are for :-)

Version 0.1.149 of the innotop MySQL and InnoDB monitor is a major upgrade. As of this version I'm declaring innotop "stable," meaning I've put some work into making it deal with unexpected input. It should be very resistant to any sort of crash now. You can download innotop from the original article.

MySQL issues a cryptic error message, "Error on rename," when you try to alter a table in such a way that it would break a foreign key constraint.

I've released version 0.1.146 of the innotop MySQL and InnoDB monitor. You can download innotop from the original article.

I re-arranged some information to be more compact and readable in this version, but there isn't really much new functionality. This is mostly a bug-fix release to prevent crashes when innotop encounters unexpected information, or doesn't find some information it expects to exist. It's still very much beta software, so it may die unexpectedly. See this article about what information I need to debug and fix crashes.

Crashes should not cause any loss of information or other problems, by the way. It's completely safe to run, because it doesn't modify anything, it just reads

This is one in a series of articles on how to use innotop, a MySQL and InnoDB monitor. In this article I'll explain how innotop can make it much easier to collect useful information from SHOW STATUS and SHOW VARIABLES into one place. There are three modes in innotop that do this in different ways, so one of them may meet your needs.

I've released another version of the innotop MySQL and InnoDB monitor. As always, you can download innotop from the original article.

It's worth upgrading to this version not only because of the new features, but also because it should handle more special cases without crashing. Of course, if it does crash, I appreciate your help fixing it; see this article about what information I need.

Why would you ever want to deliberately cause a deadlock? Sometimes a very large deadlock in MySQL will fill the output of SHOW ENGINE INNODB STATUS until it truncates, so you can't see information about transactions, log and I/O, buffers, and so forth. I know only two solutions to this problem: 1) restart MySQL and 2) cause a small deadlock so the LAST DETECTED DEADLOCK section shrinks to an acceptable size. In this article I'll show you how to cause a small deadlock, and how to use innotop to do it more easily.

This article is part of a series on how to use innotop to make your life easier.

A "little-known way," I claim, and yet it happens all the time -- precisely because it's little-known. Experts will quickly recognize where I'm going to go with this article, but I hope many others in my audience will understand deadlocks more deeply after reading it. I'll use MySQL and InnoDB for illustration purposes, but the scenario this article describes (dramatic music, please!) could happen to you, too! And probably will someday, unless you're one of the elite few (ok, enough drama) who know how to avoid it.

In this article I'll briefly introduce deadlocks, give an example of one that happened at my employer recently, analyze and explain it, and then disclose the secret way to avoid cause such deadlocks. Then I'll show you how to reproduce the deadlock and dive into the gory details of what goes on internally with InnoDB. I'll also demonstrate

This is one in a series of articles on how to use the innotop MySQL and InnoDB monitor. In this article I show how innotop can display locks that are causing a transaction to wait.

A couple of people have written in reporting innotop crashes. Unfortunately I don't have access to enough variations of operating systems and MySQL versions to test everything myself, but if you're able to help by sending me a bug report when innotop crashes, I'm willing to work on fixing it! I hope soon I'll have a much larger test suite, and am grateful for your help with that. This article explains what information I need to reproduce and debug crashes.

I've made several improvements to the innotop InnoDB and MySQL monitor, and it's ready to get from the download link on the original article.

MySQL is adding more tools to monitor its internals with every new release, but one thing it still lacks is a way to find out who is locking what, and therefore which transactions block which other ones. This is such a vital feature that I'm considering writing my own patch to the source! Still, it is possible, to a limited extent, to find out who's locking resources. In this article I'll explain how you can do that.

This article is the second in a series on how to use the innotop MySQL and InnoDB monitor.

This is the first in a series of articles I?ll write on how to use innotop, the MySQL and InnoDB monitor I?m developing. This article explains how to install innotop.

I've just improved innotop substantially, and released version 0.1.106 (download innotop from the original article), and I'm also preparing a series of articles on how to use it for real, practical things. I'd like to know what you think of it, what problems you have, what features you want. It would be a huge help if you'd start it, toggle through its modes, and give me your feedback.

MySQL doesn't yet provide good tools for some troubleshooting tasks. Fortunately, there is some low-hanging fruit you can pluck. One example is a tool to record who owns a MySQL database connection, so long-running transactions can be traced back to the source. This article demonstrates an easy way to solve that problem.