Hi Sanjeev Jain,
The MySQL Cluster engine is the ndbd process. This process is implemented as a set of
blocks (source is found in ndb/src/kernel/blocks/*). Each block is essentially a very large
C++ class which can receive signals (messages) from other blocks (either from a block in the
same process or from a block on a different process).
These entry methods are called
execNAME_OF_SIGNAL(Signal* signal)
{
...
}
Where NAME_OF_SIGNAL is the name of the message (there are a few hundred different messages
in the system) and the Signal object is the container of the message. Most signals are represented
by a class found in ndb/include/kernel/signaldata/*.
The blocks that needs most of the work to handle disk based data is
dbtup
dbacc
dbtux
dblqh
dbtup is the block that contains the records
dbacc is a hash index mapping from primary key to a local reference used in dbtup
dbtux implements an ordered index that together with dbtup maps any index lookup
dblqh implements the various parts needed for
1) primary key lookup
2) scan table
3) node restart
4) system restart
using the other blocks
Implementing disk based data is a major task that requires quite some understanding of
database recovery. There are no exceptional differences to handling this in a clustered
environment, most of the interfaces provided by dblqh to support the above features can
still be there.
Would be interesting to hear more of your plans. We are currently doing some work in this
area as well which you can follow through our bk commit messages.
Rgrds Mikael
Mikael Ronstrom
Senior Software Architect, MySQL AB
My blog:
http://mikaelronstrom.blogspot.com