Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On Mon, 2006-09-11 at 12:05 +0200, Lars Ellenberg wrote: > / 2006-09-11 13:10:43 +0530 > \ Milind Dumbare: > [...] > > > > 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? > > fine. > and exactly _where_ do you "find" that only 3 blocks of N1 have changed? > > the point is, we have _one_ bitmap. that stores which blocks have been > modified independently of "the peer". So you mean When node is primary or modifying the volume only then bitmap is used, right? In that case what does bitmap of peer is used for? > we don't have a way to store > "has been modified intependently of N3 but correctly mirrored on N2." > that is why I say "does not support more than two nodes". > > yes, one could implement that. to get it working is probably even > trivial, though still a lot of work. to get it right is probably not as > trivial as it might seem. feel free to do so. > -- -Milind "There is no place like 127.0.0.1"