Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2006-09-08 19:03:13 +0530
\ Milind Dumbare:
> Hi all,
>
> I have read the document drbd8_wpnr.pdf. As far I could understand in
> 5.3 section you have described UUID values are written as ordered
> quadruples <current,bitmap,history1,history2>, so history1 is for Node2
> and history2 is for Node3, right?
forget about "node3".
correctly "supporting" a 3rd node as cold-standby secondary,
recognizing that we might have "related" data, but need a full sync,
is a (nice to have) side-effect only that this algorithm is capable of
no. the uuid stuff, and the uuid-history in particular, is there to be
able to detect split brain situations reliably.
> Now Step 5 of your table in section 5.3.
> After the resync, node1 is connected to node3. The bitmap-UUID gets
> cleared when the resync process finishes, i.e. all the marks in the
> bitmap are cleared, and now both data sets are in sync.
>
> Now here, Where this 7 and 5 came from? is 7 history UUID for Node3 and
> 5 history UUID for Node2?
>
> Similarly in Step 9.
copied from ROADMAP text:
Special UUID values:
JustCreated [JC] ___ 4
ALGORITHMS
Upon Connect:
self peer action
1. C=JC C=JC No Sync
2. C=JC C!=JC I am SyncTarget setting BM
3. C!=JC C=JC I am SyncSource setting BM
4. C = C No Sync
5. C = B I am SyncTarget using BM
6. C = H1|H2 I am SyncTarget setting BM
7. B = C I am SyncSource using BM
8. H1|H2 = C I am SyncSource setting BM
9. B = B [ and B != 0 ] SplitBrain, try auto recover strategies.
10 H1|H2 = H1|H2 SplitBrain, disconnect.
11. Warn about unrelated Data, disconnect.
[this part seems to be missing from the pdf]
Upon Disconnect:
Primary:
Copy the current-UUID over to the bitmap-UUID, create a new
current-UUID.
Secondary:
Nothing to do.
Upon becomming Primary:
In case we are disconnected and the bitmap-UUID is emptry, copy the
current-UUID over to the bitmap-UUID and create a new current-UUID.
Special-case: primary with --do-what-I-say, clearing the inconsistent
flag causes a new UUID to be generated.
Upon start of resync:
Clear the consistent-flag on the SyncTarget. Generate a new UUID for
the bitmap-UUID of the SyncSource and the current-UUID of the SyncTarget.
Upon finish of resync:
Set the bitmap-UUID to 0. The SyncTarget addopts the current-UUID
of the SyncSource, and sets its consistent-flag.
When the bitmap-UUID gets cleared, move the previous value to H1.
In case H1 was already set copy its previous value to H2. Etc..
For the auto recover strategies after split brain (see item 5)
it is neccessary to embedd the node's role into the UUIDs.
This is masked out of course when the UUIDs are compared.
> If I have configured Third node as scheduled backup node, will that
> backup be incremental? Or each time it will full resync with the primary
> node?
drbd 8 does _not_ support more than two nodes.
the uuid-based algorithm is able to reliably detect
"unrelated" data sets (and refuses to connect these)
"split brain" data sets
"related but in need of full sync" data sets
using what you call your "scheduled backup node"
likely falls into "related but in need of full sync".
--
: Lars Ellenberg Tel +43-1-8178292-0 :
: LINBIT Information Technologies GmbH Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe http://www.linbit.com :
__
please use the "List-Reply" function of your email client.