From: Jan Wieck <JanWieck@Yahoo.com>
To: David Parker <dparker@tazznetworks.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Subject: Re: replication
Date: Wed, 09 Jun 2004 13:27:21 -0400
Message-ID: <40C74879.3000602@Yahoo.com> (raw)
In-Reply-To: <120DB10316D2B946A3A1BEFB82324BB17D3BB2@kodos.tazznetworks.com>
References: <120DB10316D2B946A3A1BEFB82324BB17D3BB2@kodos.tazznetworks.com>
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 #
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: JanWieck@Yahoo.com, dparker@tazznetworks.com
Subject: Re: replication
In-Reply-To: <40C74879.3000602@Yahoo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox