Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Rafał Kupka schrieb:
> On Tue, Dec 18, 2007 at 01:56:21PM +0100, Tomasz Chmielewski wrote:
>> Rafał Kupka schrieb:
> Hello,
>
>>> Make sure that resource r0 is in primary state on that node.
>> Indeed it was the case:
>>
>> primary_machine# cat /proc/drbd
>> version: 8.2.1 (api:86/proto:86-87)
>> GIT-hash: 318925802fc2638479ad090b73d7af45503dd184 build by root at san2,
>> 2007-12-17 13:43:47
>>
>> 1: cs:SyncSource st:Secondary/Secondary ds:UpToDate/Inconsistent C r---
>> ns:11704 nr:0 dw:0 dr:19264 al:0 bm:0 lo:0 pe:5 ua:237 ap:0
>> [>...................] sync'ed: 0.8% (1536652/1548204)K
>> finish: 0:28:27 speed: 856 (824) K/sec
>> resync: used:2/31 hits:961 misses:2 starving:0 dirty:0 changed:2
>> act_log: used:0/127 hits:0 misses:0 starving:0 dirty:0 changed:0
>>
>>
>> An obvious question would be: why does it sync if both machines are
>> secondary?
>
> Primary/Secondary state is for DRBD device availability. On primary node
> you have working /dev/drbdx. Syncing is about disc state ("ds:" in
> /proc/drbd). You have ds:UpToDate/Inconsistent -- other node disc is
> Inconsistent and sync is needed.
Yes, I probably did "drbdadm -- --overwrite-data-of-peer primary all"
first, restarted drbd, so both machines were secondary again, but only
one was UpToDate.
>> Let's make it primary:
>>
>> primary_machine# drbdadm -- --overwrite-data-of-peer primary all
>> Child process does not terminate!
>> Exiting.
>
> Use --overwrite-data-of-peer only if DRBD refuses to switch to primary
> state and you know that it is necessary.
No, switching the states was not the problem.
I noticed similar errors are quite often:
machine# /etc/init.d/drbd stop
Stopping all DRBD resourcesChild process does not terminate!
Exiting.
ERROR: Module drbd is in use
.
machine# No response from the DRBD driver! Is the module loaded?
Error code 134535439 unknown.
You should updated the drbd userland tools.
Stopping all DRBD resources.
Seems like something doesn't free resources properly in time?
>> Let's now try to see what happens if we reboot drbd on the primary machine:
>>
>> # /etc/init.d/drbd stop
>> Stopping all DRBD resources.
>>
>> # /etc/init.d/drbd start
>> Starting DRBD resources: [ d0 s0 n0 ].
>
>> Ouch - primary is gone! Why? Do I have to set up the primary each time
>> after drbd starts?
>
> Yes, typically heartbeat DRBD resource agent manage primary/secondary
> state of device. I think in your situation (drbd as "backup") small
> /etc/init.d/ script on first node is good enough. In case of disaster
> you can set primary on other (backup) node manually, right?
Probably, yes, a small script would do.
--
Tomasz Chmielewski
http://wpkg.org