Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
> -----Original Message----- > From: drbd-user-bounces at lists.linbit.com > [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Lars > Ellenberg > Sent: Monday, February 12, 2007 5:32 AM > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] Scheduled Replication Feasible? > > / 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. Ok, I understand distinct write operations. We don't have too many apps that re-write the same data over and over what I worry is someone in support copying an 8GB file over to the array which would cause a full re-sync. Maybe use drbd for SQL/Exchange and stick to DFRS for file data. > > What is the down side to increasing al-extends, just longer > re-syncs? > > longer resyncs in case of primary crash. Oh, so if the replica is disconnected and standalone, then when the secondary re-connects what happens then if the data written on the primary is > then al-extends? > > Does all data covered in al-extends get re-synced? > > after a primary crash :) Only after a crash? What about after a disconnect and re-connect? > > 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. Ok, well at least that I got correct. > > > > 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. Fair enough. > >>> 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. Probably best as a manual process. > >>> 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. So we would tell heartbeat that if we are not primary to not auto-start drbd, just hang out until further notice, for if it is scheduled replication we will be handling this through cron script. Only if we are primary do we need to start drbd. > >>> 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. Sounds interesting, but we don't have 2 nodes local, just 1 node local, 1 node remote. Thank you for the information by the way, and thank you for the referral to your commercial support option. ______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.