On Fri, May 18, 2007 at 07:55:24PM +0200, Thomas Lopatic wrote:
> For Slony-I it seems to me that my risk is losing a couple of rows in my
> database, which is something that I could live with. For disk-level
> replication it seems to me that, in case of a master failure, I could
> easily end up with a corrupted database file on the master's as well as
> the slave's harddrive (which is a mirror of the master's), possibly
> preventing the slave from taking over, which is clearly something that I
> cannot live with as this means downtime.
Right. Slony and other database-level replication systems, if
they're designed correctly, expend a great deal of effort on making
sure that node switchover and failover works, where works means "your
data is consistent, even if you lose some". In general,
disk-replication schemes are designed for general _machine_
availability. It is very hard to optimise this approach for the many
small writes that databases tend to do. That said, if you can be
rock solid sure that (1) your "hot" system is always rigorous about
fsync and write order and (2) that your "standby" system physically
cannot take over the disk while your "hot" system's data has not all
been flushed and the "hot" system somehow disconnected, then it can
be safe. The problem usually lies in the actual guarantees of (1)
and (2), and the corresponce of those guarantees with the initial
promises.
> original posting. But you mention settings. So let's for a moment assume
> that I get everything right in this respect and then my postmaster fails
> in the middle of a write. Which settings would I want to modify in which
> way to minimize the risk of database corruption in such a case?
This is entirely out of PostgreSQL's control, and up to the operating
system and cluster/failover implementation you have. Note that there
are many ways to do this wrong, including things like using tokens on
the filesystem as a lockfile (I swear someone once proposed this to
me).
A
--
Andrew Sullivan | [EMAIL PROTECTED]
This work was visionary and imaginative, and goes to show that visionary
and imaginative work need not end up well.
--Dennis Ritchie
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
