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: Friday, February 09, 2007 5:01 AM > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] Scheduled Replication Feasible? > > / 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. 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? What is the down side to increasing al-extends, just longer re-syncs? Does all data covered in al-extends get re-synced? 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? Is that a correct analysis? > > 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? > > 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. > > 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. > > 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. > > > > > > 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. > > :-) Good to know, good to sell management on. Can you send a PDF of your services, or at least direct me to the commercial web site. I will checkout version 8, does it come with an RPM spec file for building a package? > -- > : 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. > _______________________________________________ > drbd-user mailing list > drbd-user at lists.linbit.com > http://lists.linbit.com/mailman/listinfo/drbd-user > ______________________________________________________________________ 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.