[DRBD-user] Real live risk of data loss w/o flush

Hans Gregersen Jensen hgj at datalogik.dk
Wed Sep 8 16:05:02 CEST 2010

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


Hi all.

I've been having similar concerns about disk-flushes.
The primary node I BBU RAID, while the secondary is not.

Is it possible to configure drbd to only use disk-flushes on the secondary node?
I should mention that I'm using protocol B.

Any pointers would be appreciated.. I haven't been able to find anything in the documentation about a per-node disk-flush configuration. 

Med venlig hilsen / Best regards
 
Hans Gregersen Jensen
Erhvervskonsulent
.Net udvikler 
Email: hgj at datalogik.dk
Mobil: +45 40 44 11 01 

Datalogik A/S
Sjællandsgade 25A
DK-7100 Vejle 
Tlf. (+45) 70 203 703
Fax (+45) 75 858 875
www.datalogik.dk



-----Original Message-----
From: drbd-user-bounces at lists.linbit.com [mailto:drbd-user-bounces at lists.linbit.com] On Behalf Of Lars Ellenberg
Sent: 8. september 2010 15:50
To: drbd-user at lists.linbit.com
Subject: Re: [DRBD-user] Real live risk of data loss w/o flush

On Thu, Sep 02, 2010 at 03:22:25PM +0200, Robert Verspuy wrote:
>  On 08/09/2010 11:08 AM, Sebastian Hetze wrote:
> >Hi *,
> >
> >What is your opinion and possibly your experience with using 
> >no-disk-barrier and no-disk-flushes without BBU RAID?  The reason for 
> >me asking is the huge latency I suffer using flushes in my setup 
> >where I run several virtual KVM instances in DRBD containers without 
> >BBU RAID. These virtual systems frequently flush disks and these 
> >operations occasionally queue up to a substantial epoch of 100 or 
> >even higher.
> >
> Sebastian,
> 
> See also my other 2 messages to the list, mailed yesterday and today.
> After some testing on our new database cluster, I'm seeing a huge 
> latency in writing small packets to disk with flushes.
> Now I'm going to use protocol C, no-disk-barrier, no-disk-flushes, and 
> no BBU on primary and secondary.
> 
> Your message helped me thinking about the risks.
> 
> Both our servers have 2 power supplies, connected to 2 power feeds.
> So in case of a power failure of one feed, both servers will still be 
> running.
> 
> Just like you mention, only in a complete power failure in the 
> datacentre, drbd will loose data, but at that moment all other servers 
> using the database server are also offline.
> 
> On the database server we're using PostgreSQL.
> PostgreSQL is ACID-compliant, so the data on disk should not be corrupt.
> It could be possible that we lost some database insert/updates, but 
> that's a risk I'm willing to accept, looking at the small change that 
> all power is lost.

Excuse me, but WHAT?

PostgreSQL is ACID compliant, IF AND ONLY IF the fsync/fdatasync and similar it issues are behaving as expected, i.e. data is on stable storage when PostgreSQL thinks it is.

If data only reaches stable storage at some point after PostgreSQL thinks it already was there, and most likely even in some random order, then no, ACID compliance is not met.

So no, if you run PostgreSQL on disks with volatile caches, and you unplug the power hard, you can expect data loss and possibly data corruption.

Which is completely independend of DRBD.


--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
__
please don't Cc me, but send to list   --   I'm subscribed
_______________________________________________
drbd-user mailing list
drbd-user at lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user



More information about the drbd-user mailing list