[DRBD-user] What to do about read errors on the primary?

Arnold Krille arnold at arnoldarts.de
Wed Sep 19 00:37:52 CEST 2012

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


Hi,

On Tuesday 18 September 2012 10:05:31 Alan Robertson wrote:
> There was another note mentioning backups...
> DRBD is designed to protect against server and disk failures.  Backups
> primarily protect against human errors, disasters and so on - and I do
> have backups...

You called your drbd-setup a backup. Its not a backup and you know it. Fine.

> Snarky comments aren't very helpful and don't have
> much place in civil discourse except maybe with your friends.   The fact
> that you don't want your system to recover from I/O errors is your
> choice.  I'm funny that way -  I want my system to do all it can to
> recover from problems, and minimize data loss...

Oh, I want my system to recover from io-errors. But most times I want my 
systems to not go on with faulty data.
You problem seems to be that drbd had read-errors on the primary and went on 
reading from that disk. It labeled your secondary (which is actually the good 
copy) the faulty one. Bad.

> In this case, I have a disk failure which I am having trouble getting
> DRBD to protect me against.

But drbd has no clue at which disk is wrong. It can't do a two-out-of-three 
voting. It has to decide on one of the two copies to go on with and it decides 
more or less with the help of a random number generator and a 50% chance. 
Well, it did choose the wrong one leaving you with one disk with errors and 
one disk with old data.

> I'm perfectly willing to accept that I
> should have configured things differently - which would be why I came
> here asking for help.  In the 10+ years I've been using and recommending
> DRBD, it's never come up for me before.

Yes, my experience with drbd is less than yours (altough I also do linux since 
>10 years), but from the state your drbd-setup is in, I know that you have a 
problem. And the only solution is to recreate the data from the backup after 
replacing the faulty disk.

Have fun,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20120919/5d5cc623/attachment.pgp>


More information about the drbd-user mailing list