Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Fri, 2006-09-08 at 17:32 +0200, Lars Ellenberg wrote: > / 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". Suppose. I have three nodes. N1, N2, N3. Replication goes between N1 and N2. I wana take backup of N1 on N3, I disconnect N2 and connect N3, take the backup (full sync), put back the N2 for replication. Now in next backup I found that only 3 blocks of N1 has changed as bitmap will say only three blocks are changed why would N3 have to do full sync with N1? > -- -Milind "There is no place like 127.0.0.1"