The 1.5.2 release of innotop contained two bugs, one very minor. The other was a crash because of the new functionality that aggregates results across many connections. I fixed them and released version 1.6.0, which I consider stable and ready for everyone to use. (My version naming convention for innotop is that even-numbered minor versions are for production use; odd-numbered, such as 1.5.2, are the development branch. That’s why I release them under the innotop-devel package).
What’s ahead for innotop 1.8? Here’s my current road map, some of which is already done:
Features for version 1.8: * A test suite. * Rename the variables the InnoDB parser outputs to match what MySQL has named them. http://dev.mysql.com/doc/refman/5.0/en/server-status-variables.html#option_mysqld_Innodb_buffer_pool_pages_data * Support Google's patches: http://code.google.com/p/google-mysql-tools/wiki/InnodbStatus http://dammit.lt/2007/06/23/mysql-40-google-edition/ * Make InnoDBParser.pm smartly fill in the data it needs by looking in SHOW STATUS and SHOW VARIABLES and realizing if these already provide necessary data. * Efficiency and speed optimizations. Only fetch needed data from servers. * Use SQL instead of all the extract_values stuff. * New configuration screen with less duplicate code that plugins can add to. * Add support for Falcon and solidDB. * Support multiple server connections in all modes. * Support incremental display in all modes. Make incremental display a per-mode configuration setting. * Tentative: Add a new mode for monitoring NDB clusters. * Tentative: usability testing and if necessary, make usability enhancements. * Tentative: Add support for pager if you want to see more than fits on screen. * Tentative: Documentation and built-in help (get help on a key from help screen).
I wrote that roadmap a while ago. I don’t get much feedback on desired features, for the most part (maybe innotop already has too many features?). These are just things I either want to do very badly, such as write a test suite, or think would be nifty or fun, such as adding a pager. Your input is welcome.
Technorati Tags:innodb, innotop, mysql, sql
Thank you! I’ve been seeing these crashes but not come around to fixing them yet.
I have one request if you get to it before I can submit a patch ;)
If we have databases that go down for a number of hours, the backoff time for reconnect retries goes through the roof. It’d be nice to have a ceiling on the reconnect retry sleep time, and have it reset whenever a successfull connection happens. If it doesn’t already.
It might also be missing a way to force-reconnect on a dropped connection without restarting innotop, but I might’ve just not found the feature yet.
Would you mind submitting bug requests? I’ll forget otherwise :)
Thanks!
Done, sent two to sourceforge. Thank you!
Hi, Baron,
I’d like to ask, how do you perform a tests on your perl code? I’m going to cover MMM with a test suite, but not sure what approach (and modules, etc) to choose. After a year with Ruby and its awesome testing frameworks I simply don’t know how to deal with perl’s crappy situation with testing :-/
Hi Alexey,
It’s not always easy to test interactive scripts. I have very little of innotop tested. I wrote the InnoDB parser with tests, but the rest of it is basically untested. I regret this decision.
The basic way to test everything is to put it into a module and use the Test::More module, which is part of standard Perl distributions. I have sometimes taken the approach of embedding modules into scripts to make them “runnable modules” that can still be tested. You can see an example of that here:
http://mysqltoolkit.svn.sourceforge.net/viewvc/mysqltoolkit/trunk/mysql-log-parser/
You usually create a t/ subdirectory and place .t files in it, then you can either run them with perl or just enter that directory and type ‘prove’ to run them all.
One of my goals for innotop in the future is to extract a lot of the code, and put it into modules and test it. Some of the interactive stuff is hard to test, as I said, but a lot of it is easy, like the code that formats things to print out as tables.
Thanks for your really detailed comments and especially for an example.