[DRBD-user] Primary Inconsistent- not true, how to fix?

Christian Völker cvoelker at knebb.de
Mon Jul 25 14:22:06 CEST 2011

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


Hi Felix,

>> What? Do you say the primary updates its data from the secondary during
>> an "adjust" command?
> Generally? No. In your case? Yes :-)
And why this?
> OK, that's ancient? So that's what was shipping with RHEL5? Hmm. You may
> want to
> a) step away from your distributor's packaged DRBD or
> b) update to EL6 or whatever's the latest and greatest.
None of these. I prefer to stay with the versions shipped with the OS
for administrative reasons.

> <snip>
>
> This is probably your adjust command kicking in:
>
>> Jul 24 21:41:58 backuppc kernel: drbd0: disk( UpToDate -> Diskless )
>> Jul 24 21:41:58 backuppc kernel: drbd0: disk( Diskless -> Attaching )
>> Jul 24 21:41:58 backuppc kernel: drbd0: Found 4 transactions (192 active
>> extents) in activity log.
>> Jul 24 21:41:58 backuppc kernel: drbd0: max_segment_size ( = BIO size )
>> = 32768
>> Jul 24 21:41:58 backuppc kernel: drbd0: reading of bitmap took 186 jiffies
>> Jul 24 21:41:58 backuppc kernel: drbd0: recounting of set bits took
>> additional 121 jiffies
>> Jul 24 21:41:58 backuppc kernel: drbd0: 0 KB (0 bits) marked out-of-sync
>> by on disk bit-map.
>> Jul 24 21:41:58 backuppc kernel: drbd0: Marked additional 508 MB as
>> out-of-sync based on AL.
> Bam. Your Primary is now officially out-of-sync.
I still don't get it really. But doesn't matter at this point ;-)

>
>> Jul 24 21:41:58 backuppc kernel: drbd0: disk( Attaching -> Negotiating )
>> Jul 24 21:41:58 backuppc kernel: drbd0: Writing meta data super block now.
>> Jul 24 21:42:07 backuppc kernel: drbd0: State change failed: Refusing to
>> be Primary without at least one UpToDate disk
> This is fucked up. I sincerely hope that more recent versions do this
> check *before* they mark your only consistent copy dirty. (This is
> usually the time when Linbit chimes in and explains why that can't be
> made to work ;-)
I added the "use-bmbv;" to the disk section, copied the drbd.conf and
started the adjust process. Why did it try to read from the inconsitent
secondary?

I got my data back meanwhile. As I said I just had to re-created the md
data and then force at primary. All good so far. But still worried how
easy drbd block access to the very important data :-(

GReetings

Christian




More information about the drbd-user mailing list