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 operation. http://lists.linbit.com/pipermail/drbd-announce/2004-July/000012.html 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