On Fri, May 18, 2007 at 02:48:03PM +0200, Thomas Lopatic wrote:
> 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).
What are the reasons they recommend this? (See my blathering in
another thread about how often the hand-wavy recommendations that are
made on this topic can really bite you hard if you don't know all the
intimate details underneath.)
> What I keep wondering: Isn't there substantial risk involved?
Sure, there's risk. There's risk in using Slony, too (if you
accidentally issue DDL under Slony without using EXECUTE SCRIPT, you
can find yourself having a rather bad day).
> 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?
Well, this is going to depend partly on the implementation and the
hardware and the settings you give. Also, you _cannot_ have another
postmaster attached to that data area, and if you accidentally open
up another postmaster on a data area and it does work while the first
postmaster is still connected, you are just completely hosed. This
is not a place to be 95% sure you got it right.
Note, too, that copying the data files around does not give you the
significant advantage that Slony or other replication systems do,
that you can use the replicated database to satisfy some times of
queries; so you should consider whether you need that. (This is why
the excellent docs on this emphasise that there are different kinds
of need and therefore different replication technologies.)
A
--
Andrew Sullivan | ajs@crankycanuck.ca
The whole tendency of modern prose is away from concreteness.
--George Orwell