Re: wikipedia down, slashdot covering, mysql mentioned

[Greg Whalin]

Rich Lafferty wrote:
> On Thu, Feb 24, 2005 at 02:38:46PM +0200, DebugasRu <debugas@stripped> wrote:
> 
>>>Probably fsync() had failed to flush some part of a 16 kB page to
>>>disk.
>>
>>so what ? one of trade-offs would be to re-read the data from the disk
>>and compare it with what it should be (another copy on the disk) and
>>only after that fix the transaction,
> 
> 
> That didn't get rid of the race condition, it just moved it. So now you
> write the transaction, and you read it off, and then you write that it
> was OK -- but what if that write gets interrupted?
> 
> So you write the transaction, and you read it off, and then you write
> that it was OK, and then you read that off, and then you write that the
> OK was OK. No, that could get interrupted to...
> 
> Meanwhile, it turns out that you've been reading back from cache instead
> of platters all along. Or perhaps it turns out that the battery-backed
> cache in the disk controller has a dead battery, or simply doesn't work.
> 
> If the disk promises data is written but it is not then there is nothing
> MySQL can do to *tell* that something is amiss. 
> 
> I think you've confused an RDBMS with a system administrator. Next
> thing you know you'll be complaining that MySQL isn't ACID-compliant
> because it can't survive a fire.
> 
>   -Rich
> 

Exactly.  No ACID database can ensure integerity in such a situation. 
Postgres, Oracle, or any other transactional DB would have suffered the 
same fate in these two cases (LiveJournal, Wiki).

Greg