LinuxJedi's /dev/null

Hot on the heals of ndb_watch 0.6.0, 0.6.1 has been released.  This is primarily a bug fix release dealing with minor reporting issues and a couple of potential crashes.

0.7 is also nearing completion and will have features such as better configuration handling and better memory status reporting.

0.6.1 can be downloaded at SourceForge and 0.7.x is currently in the SVN trunk hosted there.  I will branch it as soon as I am ready to declare a feature freeze.

After a year of almost no development I decided recently to pickup ndb_watch again and see if I could improve it.  A few weeks later and I have 0.6.0 ready for the world to use.

ndb_watch is a utility I written in C to monitor MySQL Cluster NDB nodes and mail a systems administrator when they fail.

It has many new features such as memory statistics (thanks to Monty Taylor), multiple management nodes and better email handling.  There are also many bug fixes.

If you fancy taking a look please go to its sourceforge page.

I am open to patches, bug reports and suggestions for future versions.

UPDATE 10th August
There is now an Ubuntu Hardy i386 package on SourceForge for this too.  Built against the packages at https://launchpad.net/~ndb-bindings/+archive

Whilst doing work on our development server at work today I tried to do an export of our live database and got the following error:

mysqldump: Error 1297: Got temporary error 233 'Out of operation records in transaction coordinator (increase MaxNoOfConcurrentOperations)' from ndbcluster when dumping table `xxxxxxxxxxxx` at row: 37542

After trying several things to get mysqldump to actually export the data I gave in and changed MaxNoOfConcurrentOperations to twice its current size, did a rolling restart and it was successful.

My main worry was that MaxNoOfConcurrentOperations would require a complete cluster restart which would mean downtime as with MaxNoOfConcurrentTransactions, luckily this wasn't the case and I have one happy and healthy cluster again.

MySQL NDB cluster is a relatively new technology which as of MySQL 5.0 in my opinion is still not fully mature. That said great amounts of work have gone into it in MySQL 5.1 and even the 5.0 version can be very stable if looked after properly.

Why use MySQL cluster?

MySQL cluster is designed for high availability, so downtime due to a single node failure should be significantly reduced, in fact in this setup any 2 servers can fail and the cluster will still run. I personally would not recommend running MySQL NDB cluster in the setup described in this document if you are looking for high performance as well as high availability, you will require more servers for this.