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

Re: Replication Solutions for PostgreSQL Master to Slave

From: Kirby Ubben <kirby(at)mcmurrayhatchery(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Replication Solutions for PostgreSQL Master to Slave
Date: 2005-10-21 22:19:36
Message-ID: 43596978.9060508@mcmurrayhatchery.com (view raw or flat)
Thread:
Lists: pgsql-admin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Chris Browne wrote:

>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...

This is all true. The issues with slony are, as you guessed correctly,
are based around the triggers, and relatively cumbersome
administration overhead for a high number of tables, and dynamic table
creation.

The application will indeed come to a more stable database scheme in
the future, but as it is right now, if each table added needs to have
triggers in place to include it in replication, i have alot of work to
deal with.

It is very possible pgcluster may be a better solution, and i am
currently setting it up on a test machine.

I am also limited in what solutions i can use based on platform. for
whatever reasons, i need to be able to use the replication solution on
two intel SuSE 9.0 Professional machines.  I was told Mammoth wasn't
available for this version of SuSE. (by the install script. ;p)

Any and all advice is appreciated.


- --
Kirby Ubben
Systems Engineer
McMurray Hatchery
kirby(at)mcmurrayhatchery(dot)com

1 515 832 1235 ext 201
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
 
iD8DBQFDWWl3thkzRAQDSgERAi+8AJ4hcoI1ytDzzFx5YmcQylbDZsLBqwCeKxr1
43fQvYdxXMyh7MT6nWp+pxg=
=JQad
-----END PGP SIGNATURE-----


In response to

pgsql-admin by date

Next:From: Roger Strandberg / HamstaDate: 2005-10-21 22:39:51
Subject: Database size, and table size
Previous:From: Chris BrowneDate: 2005-10-21 20:44:59
Subject: Re: Replication Solutions for PostgreSQL Master to Slave

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