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
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
