Re: Replication solutions high volume db

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Replication solutions high volume db

Joshua D. Drake

>
> I think I've narrowed it down to Slony and Mammoth.
> Any pro's or con's on one vs the other?

Slony is more complicated to setup.
Slony requires triggers and cron.
Slony is asynchronous
Slony is Open Source
If Slony breaks you can call Command Prompt
It used to be that Slony was timed replication. I do not know if that is
still the case.

Mammoth is about as easy as it can be to setup.
Mammoth does not require triggers or cron
Mammoth is asynchronous
Mammoth costs $$$
Mammoth is set to be optionally synchronous in June.
Mammoth replicates on a per comitted transaction basis.
Mammoth Replicator is PostgreSQL with integrated replication.
If Mammoth breaks you can call Command Prompt ;)

>
> Some area where our environement might stretch a solution.
> Some records can be large. Limitied to one table but they can be 40K+
> of chraracters in a column.

As long as that is not the primary key, there wouldn't be a problem.
The length of the primary key can not be greater than 8k with Mammoth.

>
> High volume of inserts coming during nightly load (millions of rows).
> These loads are coming in commited blocks of 100.

No problem.

>
> That cannot slow down the replication.
> Our call center agents needs access to them asap.
>
> Any locking issues on the master during the replication process?

Neither Mammoth or Slony require any exclusive locks to replicate the
data.


Sincerely,

Joshua D. Drake



> Anything else I should be concerned about or things I need to consider?
> Personal experiences you have had running either.
>
> tia
> David
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/


---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly
Reply | Threaded
Open this post in threaded view
|

Re: Replication solutions high volume db

Joshua D. Drake

>
> Generally speaking I'd expect Mammoth to handle high loads a little
> better since it's a log shipper and not trigger based.  So, if slony
> proves too slow for this situation, then I'd recommend asking the folks
> at Command Prompt for a demo of their system to see if it can.

http://www.commandprompt.com/download

Sincerely,

Joshua D. Drake


>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
--
Command Prompt, Inc., Your PostgreSQL solutions company. 503-667-4564
Custom programming, 24x7 support, managed services, and hosting
Open Source Authors: plPHP, pgManage, Co-Authors: plPerlNG
Reliable replication, Mammoth Replicator - http://www.commandprompt.com/


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
    (send "unregister YourEmailAddressHere" to [hidden email])


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to [hidden email] so that your
       message can get through to the mailing list cleanly