Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id DE494633FE8 for ; Tue, 7 Apr 2009 07:31:14 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 91479-05 for ; Tue, 7 Apr 2009 07:31:02 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp4.clear.net.nz (smtp4.clear.net.nz [203.97.37.64]) by mail.postgresql.org (Postfix) with ESMTP id 2CE5B633AFD for ; Tue, 7 Apr 2009 07:31:08 -0300 (ADT) Received: from zmori.markir.net (121-73-162-246.dsl.telstraclear.net [121.73.162.246]) by smtp4.clear.net.nz (CLEAR Net Mail) with ESMTP id <0KHQ004L87VRFK10@smtp4.clear.net.nz> for pgsql-performance@postgresql.org; Tue, 07 Apr 2009 22:31:05 +1200 (NZST) Date: Tue, 07 Apr 2009 22:31:02 +1200 From: Mark Kirkwood Subject: Re: Best replication solution? In-reply-to: <20090406123529.GA14675@shinkuro.com> To: Andrew Sullivan , pgsql-performance@postgresql.org Message-id: <49DB2B66.1080801@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <49D8FA31.8010407@on-track.ca> <20090406123529.GA14675@shinkuro.com> User-Agent: Thunderbird 2.0.0.19 (X11/20090117) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.508 tagged_above=0 required=5 tests=AWL=-1.508, FS_REPLICA=1.179, RCVD_IN_SORBS_WEB=1.117, SARE_SPEC_REPLICA=0.72 X-Spam-Level: * X-Archive-Number: 200904/138 X-Sequence-Number: 33505 Andrew Sullivan wrote: > On Sun, Apr 05, 2009 at 11:36:33AM -0700, Lists wrote: > > >> *Slony-I* - I've used this in the past, but it's a huge pain to work >> with, caused serious performance issues under heavy load due to long >> running transactions (may not be the case anymore, it's been a while >> since I used it on a large database with many writes), and doesn't seem >> very reliable (I've had replication break on me multiple times). >> > > > I'm also somewhat puzzled by the claim of unreliability: > most of the actual replication failures I've ever seen under Slony are > due to operator error (these are trivial to induce, alas -- > aforementioned pain to work with again). Slony is baroque and > confusing, but it's specifically designed to fail in safe ways (which > is not true of some of the other systems: several of them have modes > in which it's possible to have systems out of sync with each other, > but with no way to detect as much. IMO, that's much worse, so we > designed Slony to fail noisily if it was going to fail at all). > > From my experience - gained from unwittingly being in the wrong place at the wrong time and so being volunteered into helping people with Slony failures - it seems to be quite possible to have nodes out of sync and not be entirely aware of it - in addition to there being numerous ways to shoot yourself in the foot via operator error. Complexity seems to be the major evil here. I've briefly experimented with Londiste, and it is certainly much simpler to administer. Currently it lacks a couple of features Slony has (chained slaves and partial DDL support), but I'll be following its development closely - because if these can be added - whilst keeping the operator overhead (and the foot-gun) small, then this looks like a winner. regards Mark