Skip site navigation (1) Skip section navigation (2)

Re: Replication Solutions for PostgreSQL Master to Slave

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-admin(at)postgresql(dot)org
Subject: Re: Replication Solutions for PostgreSQL Master to Slave
Date: 2005-10-21 20:44:59
Message-ID: 60wtk6d2gk.fsf@dba2.int.libertyrms.com (view raw or flat)
Thread:
Lists: pgsql-admin
jd(at)commandprompt(dot)com ("Joshua D. Drake") writes:
>> You are looking for synchronous replication as opposed to async?
>> 
>> >Currently i have Slony working, but am not satisfied with how it
>> >accomplishes replication, or it's interface, and am curious what
>> >others are using to accomplish replication?
>
> There is also Mammoth Replicator:
>
> http://www.commandprompt.com/products/mammothreplicator
>
> It is a commercial product (I work for CMD) but it is widely used
> in the corporate environment and you may find it a little easier
> to manage.

A vital difference is that Slony-I extracts replication information
(e.g. - determines what it needs to replicate) via triggers on the
tables, whereas Mammoth Replicator takes the (quite common in the
industry) approach of reading update information out of the
transaction logs.

There are a number of differences between the approaches, but in the
conversations with people at OSCON, it seemed surprisingly common for
the similarities to make it seem that when Slony-I was inadequate,
Mammoth Replicator would be too.

Of course, this particular discussion hasn't extracted enough
information about the dissatisfaction to evaluate much of anything...
-- 
output = ("cbbrowne" "@" "cbbrowne.com")
http://cbbrowne.com/info/spiritual.html
There was a young lady of Crewe
Whose limericks stopped at line two. 

In response to

Responses

pgsql-admin by date

Next:From: Kirby UbbenDate: 2005-10-21 22:19:36
Subject: Re: Replication Solutions for PostgreSQL Master to Slave
Previous:From: Joshua D. DrakeDate: 2005-10-21 18:49:18
Subject: Re: Replication Solutions for PostgreSQL Master to Slave

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group