Various answers to questions on the list

[Mikael Ronström]

Hi all,
Adding some answers and comments to a number of questions discussed on 
the cluster list.

Q1) Regarding the question of having 1 mysql server on each web server 
with storage nodes in a central location.

Answer:
This is one possible configuration set-up which makes sense. Currently 
there is one limitation that there can be a
maximum of 63 nodes in the cluster. So if you have 1 management server, 
4 DB nodes that provides the
possibility to have 58 MySQL servers in the cluster.

This limitation is simply a compile time constant so is fairly simple 
to update. The drawback of upgrading it is that
there are some loops that become longer and also the DB nodes will have 
more work in checking for incoming
messages due to the increased number of TCP/IP connections. Essentially 
this is a question of how many servers
to support before adding a new tier in the architecture.

Q2) Regarding suitable Hardware

The recommended HW is recommended since it is a clustered main memory 
database. The minimum HW needed is
much smaller. I am developing on a Mac with 1 GB of memory and I can 
run 4 storage nodes on this machine. Of
course the database size becomes very limited then.

For production usage it is very important to ensure that the
machine doesn't start swapping. For high availability purposes the 
process needs to send heartbeats every second
or so. If the machine runs out of memory and starts swapping there are 
no bounds on the time for heartbeats. We had
a customer running a backup program every night that used a large 
amount of memory and this caused node
failures sometimes. They were running with about 1 GB of memory for the 
storage node process and 2 GB memory
in the machine and still got problems due to other processes consuming 
large amounts of memory.

It is thus important to run production machines in a controlled 
environment if desiring a high availability system. As a side
note one can mention that node failures are  merely a glitch in MySQL 
Cluster.

So what we have recommended in the past as minimum HW is 512 MByte of 
memory.

2 GB with 800MB database size should work out fine both for testing and 
production.
For a high availability set-up without single point of failures one 
should also consider having dual Ethernet networks. There
are lots of device drivers available that handles this.

Q3) Various questions on platforms
We are currently working on supporting all Unix-variants for MySQL 
Cluster and have started work on Windows. In the
development team we are using RH Linux, Mac OS X 10.3, Solaris 7 so 
they get exercised regularly during the
development process. The other OS's are handled at builds of new 4.1 
and 5.0 releases. So please report any problems and
solutions to those so that we can integrate those fixes in the source 
code.

Currently MySQL Cluster is only available from bitKeeper. It is not 
included in the source code release of MySQL 4.1.2.

If you experience problems also check the MySQL manual for a 
description of the files containing logs of error and warning
messages of various kinds.


Some general comments:

1) In the past I have experienced problems at times with hostnames. On 
some installations one should only use the hostname
and not the full path, on other installations the opposite have been 
the case where only full path in the hostname was ok. The
storage nodes and MySQL servers call gethostname to get the IP-address 
given the hostname provided in the config file.

2) Please check the MySQL manual regularly for updates on names of 
files, changes to configuration files and so forth. We are
currently working hard to make it easier to get up to speed quickly 
with MySQL Cluster and thus some things are changing
regularly. A new chapter has been added to the MySQL manual on MySQL 
Cluster which should contain more and more
answers to common questions.

Rgrds Mikael

Mikael Ronström, Senior Software Architect
MySQL AB, www.mysql.com

Clustering:
http://www.infoworld.com/article/04/04/14/HNmysqlcluster_1.html

http://www.eweek.com/article2/0,1759,1567546,00.asp