Shahaf Abileah shahaf at redfin.com
Fri Aug 22 07:24:07 PDT 2008
I haven't tried to update the path on a given node before.  That's
clever.  Do you think it would work to do a pg_dump / pg_restore?  Or
would that create different OID's and therefore break replication?

We have copied files over using rsync (which has a bwlimit option) and
that seems to work very well.

--S


-----Original Message-----
From: slony1-general-bounces at lists.slony.info
[mailto:slony1-general-bounces at lists.slony.info] On Behalf Of Martin
Eriksson
Sent: Friday, August 22, 2008 1:06 AM
Cc: slony1-general at lists.slony.info
Subject: Re: [Slony1-general] bandwidth limit on slony replication

I don't know of any such ways in slony, there might be?

even if there is no such way in slony you could always throttle it on a 
lower level on the network level, pleanty of software available to do
that..

but there are other ways to handle the initial huge bulk load as well..

e.g. replicate to a new instance in your data center (assuming its same 
hardware architecture (32bit vs 64bit , intel vs AMD etc, postgreSQL 
version) as the new node) once replication is done shut down the 
instance and do a physical copy of the data directory of the new 
instance. if you b2zip it will become about 5-7 times smaller and then 
transfer that and use that data directory for the new node, modify the 
slon path with slony "store path" to correspond with the new ip etc. 
then just let it catch up on the data since the shutdown.

this would yield 4-7 times less bandwidth usage, other way is to put it 
on a removable disk and bring it physical to the new location.

I've done both ways in our slony cluster and never had any problem. But 
then again we always make sure all our db machines are exactly the same 
in terms of hardware and software.

Martin


Shahaf Abileah wrote:
>
> Is there a way to limit the amount of bandwidth that slony uses?
>
> Within our data center we don't really care how much network is used 
> to replicate DB's from one server to another. However, we'd like to 
> set up slaves in other locations, and we can get slapped with huge 
> fees if we have big spikes of network bandwidth usage (e.g. when you 
> first set up a slave and you need to bulk-copy all the tables).
>
> Thanks,
>
> --S
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at lists.slony.info
> http://lists.slony.info/mailman/listinfo/slony1-general
>   

_______________________________________________
Slony1-general mailing list
Slony1-general at lists.slony.info
http://lists.slony.info/mailman/listinfo/slony1-general




More information about the Slony1-general mailing list