[DRBD-user] drbd is awesome: it mirrors reads, too!

Lars Ellenberg Lars.Ellenberg at linbit.com
Sun Aug 7 10:56:01 CEST 2005

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

/ 2005-08-06 18:49:00 -0400
\ Maurice Volaski:
> Our internal 3ware RAID did something bad and the logs starting
> filling with scary errors:
> Jul 31 03:10:15 [kernel] [1745925.523238] PCI-DMA: Out of IOMMU space for 16384 bytes at device 0000:03:01.0
> Jul 31 03:10:15 [kernel] [1745925.524623] SCSI error : <0 0 0 0> return code = 0x70000
> Jul 31 03:10:15 [kernel] [1745925.524626] end_request: I/O error, dev sda, sector 47586099
> (I have changed the IOMMU allocation from 32 MB to 512 MB to address the issue, I hope)
> One of the affected partitions is under drbd, but the rest is the
> root. Something somewhere made the root partition read-only. And it
> did so to the drbd partition too, but oddly nobody seems to be
> complaining they can't access the database on it.

> So if I understand this correctly:
> 1) drbd is a true mirrored RAID for both writing AND reading.

yes of course :)

only that reads are always local, as long as there is something (good) local,
and that you can configure "on-io-error panic;" (default is detach,
iirc), in which case the node in question should have committed suicide,
and the other had taken over.

> 2) I don't want to necessarily configure the OS or drbd to
> automatically kill the primary should the RAID start to fail. drbd
> will just use the secondary so long as the primary's OS and network
> are intact.

_and_ the internal link stays up. so you still should failover as soon
as possible and convenient.
this is intended to allow for a graceful failover after local io error
(be nice to your services, choose a suitable point in time for your users).

> This fantastic feature ought to be noted in the documentation a bit
> more explicitly. I previously thought of drbd only in terms of the
> primary's failing globally requiring heartbeat intervention to produce
> a failover.

[ we are good? sure we are good. we know that.
  so why should we run about talking big? ]

: Lars Ellenberg                                  Tel +43-1-8178292-0  :
: LINBIT Information Technologies GmbH            Fax +43-1-8178292-82 :
: Schoenbrunner Str. 244, A-1120 Vienna/Europe   http://www.linbit.com :
please use the "List-Reply" function of your email client.

More information about the drbd-user mailing list