----- Original Message -----
> From: "Marcus Bointon" <marcus@stripped>
>
> Not at all. The point of redundancy (via replication or DRBD) is to
> maintain consistent and available data in the face of a server or
> replication failure.
That is the point of HA replication. You can also replicate for other purposes, read
scaling being one of them.
> like using RAID-0, but without the speedup! With writes to both
RAID-0 is striping, which provides no HA benefit whatsoever, and, indeed, worsens your
data availability: one lost disk kills your entire volume.
No, replication is more like RAID-1, if you really want to use those analogies: you now
have 2 copies of your data. Writes necessarily happen on both sides, so there is no
benefit there (except for HA of course), but you can now read from both sides,
effectively doubling your read capacity.
> there's no way of avoiding the split-brain scenario you describe and
> it's really hard to recover from (I've been there!).
Of course there is, but it requires your application to be aware of the scenario. As I
said earlier, this is not trivial, and most applications can't handle it. That does not
mean that there is no benefit for applications that do.
> There are some attempts to introduce a semi-synchronous replication
> system for MySQL that waits until transactions are replicated
Which is entirely irrelevant to this particular line of thinking, as it waits for the
transactions to be *logged*, not *applied* - there is still no two-phase commit and thus
no checking for conflicting updates.
--
Bier met grenadyn
Is als mosterd by den wyn
Sy die't drinkt, is eene kwezel
Hy die't drinkt, is ras een ezel
