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.

Your description above is what I considered batch... you are taking a "batch" of transactions and replicating them versus each transaction. I am not saying it is bad in any way. I am just saying it is different that replicator.

What is a usual average replication lag of Mammoth Replicator?

Obviously it depends on the system, the network connectivity between the systems etc... In our test systems it takes less than 100 ms to replicate the data. Again it depends on the size of the transaction (the data being moved).

What happens to the other existing slaves when you promote by hand?

This is something that Slony has over replicator. Currently the new master will force a full dump to the slaves. Of course this is already on the road map, thanks to Slony :) and should be resolved by months end.

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.

I have never suggested otherwise. My only comment about maturity is that their are actually many companies using replicator in production. We have already dealt with the 1.0 blues as they say.

I hope you understand that I, in no way have ever suggested (purposely) anything negative about Slony. Only that I believe they serve different technical solutions.


Joshua D. Drake


Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - [EMAIL PROTECTED] - http://www.commandprompt.com
PostgreSQL Replicator -- production quality replication for PostgreSQL

---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?


Reply via email to