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-09 10:24:03 -0500 \ Ross S. W. Walker: >>> 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. > > I guess that is the answer I expected, so lets see... (Yes/No, > explanation optional) > > The setting of the al-extends and the amount of data written during the > 12 hour period would determine this? > > If the amount of data written > al-extends size then a full re-sync is > needed? no. it depends _where_ changes occurr. if you write 20TB, but all to the same sector (each write overwriting the one before), you only get to resync that sector. for one big sequential write, you have to resync all of it. the al-extends have nothing to do with this one, they determin what has to be resynced during recovery from a Primary crash. > What is the down side to increasing al-extends, just longer re-syncs? longer resyncs in case of primary crash. > Does all data covered in al-extends get re-synced? after a primary crash :) > If so that would mean that al-extends should not be so big as to cause > re-sync to fall outside the backup window, based on it's total size and > the selected sync-rate? yes. > > > 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. > > When you say add, do you mean a work-around for existing code > or a custom code build? could be either way, we'd have to think about how to do this "best. >>> 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. > > I guess if I use heartbeat I can set how long the system would have to > be down-and-out before a fail-over to yesterday's data was reasonable, > or leave it as a manual process, either way. not in a straight forward way, unfortunately. >>> 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. > > Can you explain why the failed primary would think it was still primary > when it came back? Or at least the type of scenario that would cause > this, just so I can get it straight in my head. it would not think it was still primary. it would know that it had been primary, and that at that time, it could not communicate with its peer. now it sees the peer is primary itself. what you have is two diverging datasets. for me, to labele it "split brain", it does not matter whether they have been primary _at the same time_, but whether they both have been primary, changing the data independently, during a period of communication loss. >>> 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. > > Basically to keep our DR site hot and ready instead of relying on tape > and our offsite tape service to make the DR site ready. We have power > generators there on the ready and standby and when the next blackout > occurs, we would like to have that site pick up business as soon as a > disaster is declared. > >>> Let me know, as this would work out well in our business as >>> we aren't a 24/7 operation. how about our "drbd+", which is exactly intended for this. you have a local 2-node HA-cluster managed by heartbeat, plus a "manually" managed 3rd node, off-site, for desaster recovery. the replication of the DR-node can be scheduled, and you still have local redundancy. -- : 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.