Diamond Notes

A few days ago I wrote about my testing of clustering.  I wasn’t able to finish writing about all the tests I had already run and I had a few left to run.  As of tonight I have finished up the testing.  There is one that I will need to go back and re-visit but I am overall very happy with how things have gone:

• running ndbd –initial on one node
• running ndbd –initial on both data nodes at start-up

As I have documented I have had some trouble starting up ndb nodes.  It has been recommended by multiple people that you should almost never run ndbd –initial.  I am really starting to have that point of view.  Bascially the outcome of these tests were that you ended up with no data.  There are very few, if any, configuration changes to the cluster that require running ndbd –initial.

• making configuration changes

Simple enough.  Make your changes, shutdown and restart the management node, followed by the ndb nodes and then the sql nodes.  (Almost) never had any trouble with it  — see test on management node.

• rolling upgrade from 5.1.20 to 5.1.22

The only trouble I had here was with file paths.  The idea is that you upgrade or downgrade your cluster from one version to another.  I upgraded from 5.1.20 to 5.1.22.  As is normal you start with the management node, shut it down, upgrade the binaries, and restart it.  Running ’show’ on the management client should then show the new version on the management node.  Rinse and repeat with the data nodes and then the sql nodes.  With my setups I use the binaries downloaded from dev.mysql.com so I download the tar.gz file to /usr/local/ and then unzip/untar the binaries and then softlink the directory to /usr/local/mysql.  This causes some difficulties when doing the upgrade.  Even so, it is “do-able”.

• convert ndbcluster - memory - table to disk-based table

This worked.  I am not going to take the time to outline the exact procedure here (maybe another blog posting some time :)).  The only thing I am not sure of is if the file you create is auto-expanding.  I don’t think it is but don’t know this for certain.

• add secondary management node

I already wrote about this.  It didn’t go well.  Not at all.  Could be easier and is definitely something I need to re-do.  We need a secondary management node for backup.

• backups and restores

I just completed this tonight.  Went well.  I did a mysqldump of the cluster and then a online backup of the cluster.  I restored the cluster from the online backup and then verified it was correct by restoring the mysqldump on another test server and comparing the two.  All was well :)  I will probably blog about this procedure soon as even though it is documented places it isn’t necessarily clear or in a “tutorial” fashion.