Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
/ 2007-02-08 21:58:05 -0500 \ Ross S. W. Walker: > > I have posted on this site in the past about the feasibility of > replicating LVM snapshots and the short of it is, if I was willing to do > a full sync each time I created a snapshot to replicate, then yes it's > possible using an external meta-device. > > Well that isn't really feasible in my environment, so I am abandoning > that idea. > > I have thought about it some more and have come up for an idea to do > scheduled replications. > > Here is what I have and what I need and maybe somebody can tell me if it > makes sense. > > I have 2 storage arrays in 2 data centers about 2mi apart. They are > connected by only a T1 line. > > Of course full-time synchronous replication would bring the array to a > crawl and fill up the T1. I then thought of asynchronous replication > using Prot A, but the size of the sndbuf would need to be really big, > and it would still hog the T1 during business hours. > > I then thought, well why not do a bit of both. If I have the two arrays > setup to replicate using Prot A, but only run that replication after > hours, say from 8pm to 8am, at 8am I manually disconnect the arrays > putting the primary into standalone and the secondary into wait, then at > 8pm I put the primary back into wait, so they connect and re-sync. > > Question is, how long can the replicas stay disconnected before a > complete re-sync is necessary? > > Can you tune this? well. depends. > If we fail-over to the secondary which is in wait, will it be marked as > inconsistent and refuse to become primary drbd 8 supports this (mechanism is called "outdate peer handler"), you can configure what behaviour you want. current drbd 0.7.x does not support this directly, but we can add a similar feature without too much problem. > or will it come up ok with the > previous data? that is what current drbd 0.7 would do. so you probably do not want heartbeat here, and no automatic failover. well, depending on what data that is, obviously, and whether you prefer to be online, regardless, or prefer to be offline rather than serving stale data. > What would happen then if the original primary came back, a full-resync, > split-brain? you would have had a split brain. in drbd 8, the behaviour is heavily tunable, and the situation reliably detectable. with drbd 0.7, depending on what exactly was going on, there may be some surprises. in both cases a "full" sync can be avoided. > Does this even make sense? there may be cases where this makes sense, I would strongly recommend to not have any automatic failover mechanisms (heartbeat) in place during disconnected phases. it depends really on what you want to achieve. > Let me know, as this would work out well in our business as we aren't a > 24/7 operation. > > > Ross S. W. Walker > Information Systems Manager > Medallion Financial, Corp. you know, we sell drbd support and drbd consulting ... even drbd and HA workshops, too. :-) -- : Lars Ellenberg Tel +43-1-8178292-0 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : __ please use the "List-Reply" function of your email client.