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: Tuesday, February 13, 2007 8:47 AM > To: drbd-user at lists.linbit.com > Subject: Re: [DRBD-user] Scheduled Replication Feasible? > > / 2007-02-12 12:59:13 -0500 > \ Ross S. W. Walker: > > > > 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? > > there is probably a misconception about what those "al-extends" are. > > we have a "dirty bitmap", which tracks, well, "dirty" blocks, > where dirty is: modified locally and not mirrored. > > AND we have the activity log (the size of which gets tuned with the > al-extends parameter). this tracks _active_ extends, that is > extends to which io may be "on the fly". > > in case we recover from a primary crash, we have no way to know > whether the "in flight" io has made it to (which) disk. > > so for all extends covered by the activity log, > we flag the corresponding bits in the bitmap as "dirty". > > upon resync, the bitmaps of the nodes get ORed together, > and the blocks corresponding to dirty bits get resynced. Ok so the extends is the activity log, like a journal on a file-system, a crash is like an unclean dismount and during a reconnect the activity-log gets replayed between primary and secondary by means of ORing it with the bitmap of modified sectors/blocks/pages? Good analogy? The extends "activity log" just contains the ios in process of being sync'd, it would mark it in the al-extends and then clear it from the bitmap. If a crash occurs mid-synchronization, then when it recovers it ORs the al-extends with the bitmap, it then should only need to update what was in the al-extends at the time of the crash and not the whole partition. Is that accurate then? > > > > 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? > > whenever necessary, we resync the changed blocks. > when you just disconnect/reconnect, > the activity log is not involved. Ok, so a "crash" is defined as an active synchronization interrupted and NOT a disconnect, using the above file-system analogy, a disconnect is an unmount, a "crash" is either the server, drbd process/module or network unexpectantly terminating a synchronization. What will happen when the secondary disconnects for an extended period, say 12 hours, the primary switches to "standalone", and then we tell the primary to start accepting connections again and the secondary reconnects? Will it see that al-extends is clean, because the last scheduled synchronization completed cleanly and just walk the bitmap of dirty blocks? At what point will the primary decide, you know there is just too much data changed between us to reliably sync all these changes, so for consistency sake lets re-sync all data? Does this happen, or is the bitmap sufficient to mark each and every sector/block/page that has been modified? > > 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. > > If I'd have scheduled replication, > I'd not involve heartbeat in any way. > > I would feel very bad about automating a failover to stale data. True, so in this instance drbd without heartbeat would be best. I want to thank you for all the information you have provided so far it has been a tremendous help in planning out this deployment and hopefully it may even enlighten some list users in the process! -Ross ______________________________________________________________________ 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.