[DRBD-user] Some queries

Todd Denniston Todd.Denniston at ssa.crane.navy.mil
Wed Dec 1 15:43:51 CET 2004

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

> 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).

If you are just setting up and you really want to go with a 0.6.x it might
be a good idea to go with the latest version (0.6.13), because if you are
like me once you get into production you don't like to change versions of
core components ... I just updated to 0.6.13 from 0.6.10 after 9 months of

And although it may not have as much nice documentation laying out on the
net for it, the 0.7.x series sounds to me to be stabilizing and will be what
is updated in the future.  IIRC unless there is a big bug or security fault
(that is exploitable from outside of your crossover link) found, 0.6.13 is
the last 0.6.x.

> 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). 

when you are running drbd (the module is in the kernel and there exists a
config file) and both machines are up with a good crossover cable, they are
ALWAYS syncing, i.e., RAID 1 over a net.
see http://www.drbd.org/drbd-article.html

> 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?

Suggestion find emails from "Lars Ellenberg" with "inittimeout" in the
archive[1] of this list. My take on what Lars has said is, if you care more
about integrity of your transactions more than the availability of the
servers you'll want to use inittimeout=0, if you care more about
availability you'll set inittimeout=<longer than it takes for each system to
boot, and then some more time>.

> 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?

with 0.6.x, don't let both nodes be down at the same time. If only one node
is down, then when it comes back up only the data which has changed on the
live node will be synced.
AFAIUnderstand with 0.7.x, the Activity Log (AL) is kept on permanent
storage so even across both systems being downed, only what has changed will
be synced after the initial full sync, unless you as an operator tell drbd
to invalidate the whole device.

> 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.

suggestion read Thanos's email, and search the archive[1] for other mentions
of database work, it has been discussed several times, but as I was only
doing NFS I did not pay much attention to them.

[1] http://lists.linbit.com/pipermail/drbd-user/
good mirroring to you. :)

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter

More information about the drbd-user mailing list