CTDB - the 'Mainz' plan for clustered Samba

tridge at samba.org tridge at samba.org
Sat Sep 30 22:11:52 GMT 2006


Simo,

 > If I understand this correctly it means that hostA sends to hostB
 > (LMASTER) a CTDB_REQUEST_DMASTER with REQID 100, hostB then sends a
 > CTDB_REPLY_DMASTER to hostC (the requested DMASTER) with REQID 100.
 >
 > Now how do you assure that REQID does not conflicts with another request
 > issued by hostC ? Is there a mechanism to keep REQIDs unique
 > cluster-wide? (May be using the VNN * 1^X as a base?)

I really need a diagram for this one :-)

This type of DMASTER handover involves 3 nodes:

 node A: the LMASTER for the record
 node B: the node wanting to operate on the record
 node C: the current DMASTER for the record

sequence of events is:

 1) node B sends a request (such as a CTDB_REQ_CONDITIONAL_APPEND) to
    node C. Lets assume this has REQID 100.

 2) node C decides that the best course of action is for node B to
    become the DMASTER (see the heuristics on this). 

 3) node C sends a CTDB_REQUEST_DMASTER with REQID 100 to node A

 4) node A sends a CTDB_REPLY_DMASTER to node B, also with REQID 100

There is no REQID conflict because we are always operating in the
REQID space of node B. The entire 3 way operation happens with that
REQID.

It doesn't matter if node C already has a REQID of 100 in flight, as
it is really just acting as a proxy. If this is too confusing, we
could instead have a ORIGINAL_REQID field in the CTDB_REQUEST_DMASTER
request. 

Cheers, Tridge


More information about the samba-technical mailing list