On 4/4/2006 2:36 PM, Marco Canderle wrote:

> Hi again. I've read all the possible solutions you've proposed. Of course I
> have to thank you all for this. Thank you very much for your time.
> 
> As Christopher Browne, Hannu Krosing, Jens Schicke and Dirk Jagdmann said,
> Slony can't solve this problem on its own. However I will use Slony anyway,
> for backup purposes, and to take advantage of the fail-over Slony provides.
> To solve the synchronization problem, what Dirk proposed, was what I had in
> mind beforehand, so that's the primary solution I will try for that issue.
> Thanks Dirk!
> 
> While I implement and test this solution, one of my partners will try with a
> VPN between Headquarters and the other offices. So all users (remote or
> local from master server point of view) will read and write to master,
> hoping that VPN will improve greatly the response time for my application. I
> think that will work for now...The slaves will be available as read-only
> access for the users in remote offices, should the master fall down.

In case your VPN software supports compression, during my WAN tests 
using ssh tunnels to run slony replication I found that activating 
compression on the tunnels improved the replication throughput 
significantly.


Jan

> 
> Many Thanks to all of you for taking the time to answer me. I hope this
> doubt helps someone else, and I hope to help you back sometime.
> 
> I will write again here if I make any advance with all this. thanks again.
> 
> Marco.
> 
> On 4/1/06, Dirk Jagdmann <jagdmann at gmail.com > wrote:
>>
>> Hello Marco,
>>
>> > So I ask: Are there any solutions that may help me reduce/avoid this
>> delay
>> > or at least prevent the slave server to respond to the user until the
>> > replication have propagated to all the slaves (or at least the one which
>> > originates the writes)? Maybe some kind of combination between
>> asynchronous
>> > replication (provided by Slony-I) and synchronous replication?
>>
>> I think you should not try to solve this issue in the database, but
>> rather your application. I would suggest you setup your application,
>> so that read requests to the database are initially done on the slave
>> servers (for remote sites) and once you have to do any write queries
>> you switch your database connection to the master site and from that
>> point on use the master db for the rest of the application session. Of
>> course you could be a bit more fancier, so that you add a timeout
>> value (for example 1min, but you should see how fast your replication
>> works) and if there have not been any write queries in the last
>> "timeout" minutes (or seconds or whatever) you can switch your
>> database connection back to a slave.
>>
>> --
>> ---> Dirk Jagdmann
>> ----> http://cubic.org/~doj <http://cubic.org/%7Edoj>
>> -----> http://llg.cubic.org
>>
> 
> 
> 
> --
> ********************************
> Marco A. Canderle
> marcocanderle at gmail.com
> ********************************
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #