If you're just looking for a way to have high availability and you're ok
being tied to linux, DRBD is a good way to go. It keeps things simple in
that all changes are replicated, it won't say an fsync is finished until
it's finished on the remote host too, and it won't let you mount the block
device on the slave system (at least with 0.7x). You loose out on the
abiility to have multiple read-only databases like you get with Slony, and
you have no control over which changes will be replicated, but if you
don't care about that, then DRBD probably has the least risk of all
postgres replication strategies.
In case you think it matters, IBM recommends DRBD for DB2.
On Fri, 18 May 2007, Thomas Lopatic wrote:
> Hi there,
>
> I am currently looking into replicated two-node master/slave PostgreSQL
> environments. Lately I've heard more and more people recommend
> replicating data from the master to the slave at the disk device level
> as opposed to the DBMS level (Slony-I). On Linux, usually DRBD is
> recommended for this, which is basically RAID-1 via a network
> connection, i.e. DRBD copies everything that the master writes to its
> disk to the slave.
>
> What I keep wondering: Isn't there substantial risk involved?
> I mean, suppose the master fails in the middle of a write. Isn't there
> the possibility that this corrupts the database? How robust is
> PostgreSQL's on-disk file format and write caching strategy against
> failures like this?
>
> With something like Slony-I some data may not be fully copied to the
> slave when the master crashes. So there may be data loss. But there
> isn't the risk of database corruption.
>
> Or am I missing something here?
>
> Thanks,
> -Thomas
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>