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