Re: Replication: Slony-I vs. Mammoth Replicator vs. ?

On 8/13/2004 9:39 PM, Joshua D. Drake wrote:

> Chris Cheston wrote:
>> HI all, I'm trying to implement a highly-scalable, high-performance,
>> real-time database replication system to back-up my Postgres database
>> as data gets written.
>>
>> So far, Mammoth Replicator is looking pretty good but it costs $1000+ .
>
> Yes but it includes 30 days of support and 12 months of upgrades/updates :)

The lead developer of Slony (me) is working for a company that has it
deployed in production already and will move more mission critical
systems to it very shortly. Guess what will be my top work priority if
you spot a bug?

>
>
>> Has anyone tried Slony-I and other replication systems? Slony-I is
>> pretty new so I'm a little unsure if it's ready for a prime-time
>> commercial system yet.
>
> It really depends on your needs. They are both good systems. Slony-I is
> a bit more of a beast to get up and running, and it is a batch
> replication system that uses triggers. Once it is up and running it
> works well though.
>
> Mammoth Replicator is easy to setup and is integrated into PostgreSQL.
> However replicator is 1000+ and doesn't support promoting of slaves
> automatically (you can do it by hand) like Slony does. Replicator is
> also live replication.

Once again, Joshua, would you please explain what you mean with "batch"
and "live" replication system? Slony does group multiple "master"
transactions into one replication transaction to improve performance
(fewer commits on the slaves). The interval of these groups is
configurable and for high volume DBs it is recommended to use about one
second, which means that all commits that fall into an interval of one
second are replicated in one transaction on the slave. On normal running
systems this results in a replication lag of 600 to 800 milliseconds in
average. On overloaded systems the asynchronous nature of course allows
the slaves to fall behind.

What is a usual average replication lag of Mammoth Replicator?

What happens to the other existing slaves when you promote by hand? In
Slony they accept the new master and continue replicating without the
need of rebuilding from scratch. Slony has mechanisms to ensure the new
master will be ahead or equal in the replication process at the time it
takes over and allows client application updates.

The Slony documentation is an issue at the moment and the administrative
tools around it are immature. The replication engine itself exceeds my
own expectations and performs very robust.

Jan

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