Message-ID: <40C74879.3000602@Yahoo.com>
Date: Wed, 09 Jun 2004 13:27:21 -0400
From: Jan Wieck <JanWieck@Yahoo.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
	rv:1.4) Gecko/20030624
MIME-Version: 1.0
To: David Parker <dparker@tazznetworks.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Subject: Re: replication
References: <120DB10316D2B946A3A1BEFB82324BB17D3BB2@kodos.tazznetworks.com>
In-Reply-To: <120DB10316D2B946A3A1BEFB82324BB17D3BB2@kodos.tazznetworks.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

On 6/8/2004 11:31 AM, David Parker wrote:

> Hi. I'm new to postgresql in general, and have been tasked with coming
> up with a replication solution for our postgresql based application.
> Assuming we don't bite off trying to roll our own solution, it looks
> like the open-source options for replication are:
> 
> 1) contrib/rserv
> 2) erserver
> 3) slony
> 4) pgreplication

   5) contrib/dbmirror

> 
>>From looking at the code, it looks like contrib/rserv might have evolved
> into erserver. I'm curious what the motivation for starting the new
> slony replication project was - is it intended to address short-comings
> in erserver? There has been some traffic on the list today about the
> pgreplication project, too, but I haven't had a chance to look at it
> yet. Is anybody using it?

The shortcomings of other replication systems was indeed the motivation 
for Slony-I. One of the required features for Slony-I is the ability to 
install and build up a new slave system without interruption of the 
master. Another goal was the ability to inherit other slaves in the case 
of promoting one slave to master. Point 1 might not seem too critical, 
as there are only few environments that cannot stop their applications 
sometimes for a few minutes. But the second problem is way more severe, 
because without that ability there is no promotion of a slave to master. 
Turning a former slave database into a single standalone system has 
nothing to do with promotion to master!

ERserver could be enhanced to do point 1, but I don't see the ability to 
satisfy goal #2 with it ever. Neither did I see the ability to add them 
to dbmirror.

> 
> Of course there's nothing that says there can't be multiple replication
> solutions for postgresql, but as somebody just coming into the
> community, I have NO idea what the relationship between them is, or if
> anybody is even doing replication.

Slony does not and will not fit the needs of anybody who's intending 
something like dozens or hundreds of sporadic connecting and replicating 
nodes (AKA the salesman on the street). It is designed for data centers 
with few but reliably connected systems.

Replication is one of the millenium-buzzwords. But replication is not a 
feature, it is many possible solutions for even more different and 
possibly interconnected problems. So I would say "there must be multiple 
replication solutions for postgresql".


Jan

-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck@Yahoo.com #