Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Vic Berdin wrote: > Hi everyone, > > I’m trying out drbd-0.6.12 on two systems both running Linux-2.4.22. > The setup went OK as `drbdsetup /dev/nb0 replicate` tests shows that > the primary node’s partition indeed gets replicated on the configured > partition of the other node. The same scenario is also evident upon > doing a `drbd start` on each of the nodes (after a fresh boot). > > Now that manual invocation of the “sync’ing” tools work, my queries > are as follows: > > 1. I’m wondering on how/when will drbd automatically synch the > secondary node, if I do not invoke the tools manually (note that I’m > using a 0.6.12 release). > > I’m also trying out the “inittimeout” parameter on my configs, in > order to avoid the wait-with-user-intervention state during system > startup. And I believe this is where “incon-degr-cmd” should come in > if I wish to automate my synch’ing. Is this a sane way to go? > Well, invoking the tools manually is rather vague: drbd will (of course) not sync: - if the drbd module is not loaded - if drbd devices are not connected (via drbdsetup or drbd init script) Other than that, syncing is done in parallel with normal operation, supposing we're talking about protocol C, which we should, since this is about a database. Whenever a read occurs, it gets served by the active node directly, whereas a write returns only (protocol C) after completing on both nodes or (protocol A) entering network send buffers. > 2. How can I instruct drbd NOT to synch the whole partition (device), > but only parts where changes occurred? Or is this possible with drbd? > You cannot. If the secondary node goes down, the primary keeps track of the changes and writes them back whenever the secondary comes back up (Syncing Quick). But when the primary goes down, you're out of luck (Syncing Full). That's why - among other things - you need a cluster manager, to manage states. > 3. My final plan with drbd is to use it along with heartbeat, and make > it serve as an HA/failover database mirror. It seems to me that > extending the drbd bash script, or creating additional scripts/tools > and placing them on heartbeats resources *should* do fine. I googled > however, that linux-mon *is/seems* needed in order to implement a more > robust failover cluster. Can anyone shed some more light on how to > properly implement my target HA/failover mirroring plans using drbd? > Any links are very much welcome. > the drbd bash script already includes the functionality you want. Just invoke it as ``datadisk <device> (start|stop)'' (or let heartbeat - via haresources - do it for you). Start will set device to primary state and mount it if an appropriate entry exists in fstab, while stop will do the opposite. Now about mon: heartbeat can keep track whether the node is alive, but cannot tell whether it is actually doing the work it is supposed to - in your case running the database. If you need to track the status of the application and fail over based on that, you'll need to integrate mon as well. Regards, Thanos Chatziathanassiou