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 | [EMAIL PROTECTED] The whole tendency of modern prose is away from concreteness. --George Orwell ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org/