On Nov 29, 2007, at 5:01 PM, Mike C wrote:

> I have a ~1GB database (< 100MB with pg_dump). It has a large
> transaction volume, ~100 updates  a second and an order of magnitude
> more selects per second. I wish to replicate this database to a warm
> standby database located in another hosting facility. I say warm

This will entirely depend on the size and quantity of your updates.   
Are your updates single row updates, or do they modify large numbers  
of rows?  In slony, a single update query that modifies many rows will  
be played back as an update per row on the replicas.  This causes a  
lot of traffic on the wire, plus is not as efficient on the DB itself,  
so you could potentially fall behind on your replication.

Also, are the updates changing large volume of data?  Ie, is the  
update of a row changing an integer or is it changing a multi-megabyte  
text field?  Again, this affects your over the wire bandwidth needs.

You really need to have beefy hardware to pull this off.  Remember  
that replication doesn't come for free.  You're going to pay a price  
of some % of the speed of your server to the overhead needed to manage  
it.

I have one DB that replicates across a WAN, but the volume of updates  
is trivial.  We've had it disconnected for 2 days once and it just  
caught up in a few seconds.  Our primary DB is a different story.  If  
it falls more than 4 hours behind, we just drop the node and recreate  
it.  There's no way it will ever catch up otherwise.... :-)

If I were setting this up, I'd make the master replicate to another  
host locally, then use that as the source for replicating to all the  
remote sites, so any one slow box won't cause much bloat on the master  
(I think).