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.
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings