On Thu, 2006-03-30 at 19:10 -0300, Marco Canderle wrote:
> Hi, I'm new here so hello everyone. I've been experimenting with
> Slony-I to deploy a replication system for the database at my work. 
> 
> My objective is to have a master server in headquarter office,
> replicating to every slave server at the satellite offices. The idea
> is that users located in headquarters read from and write to master
> server. The users located in satellite offices read from the local
> slave server and write directly to the master server (which then
> replicates to all slaves databases, including the one who originate
> the write). 
> This has to be done this way mainly for two reasons: 
>    -If the master gets offline, the remote users can continue
> accessing information because they read from the local slave server.
>    -An increase in the response time: The system is web-based
> (implemented in PHP). For the remote users, in the other end of the
> country, the response time is much more slower than for the users near
> the master server, due to the Internet connection. And the majority of
> the database access are reads not writes. 

I have a few places that I needed to synchronize as well. One of the
nicer bits about Slony is that it is possible to determine the current
replication status. That is, which parts have been replicated and which
parts are still pending replication. 

1) Check out the sl_status query for some hints about how to find out
the status of all nodes (not just the current one) as known by this
machine.

2) Record a local transaction log that you use to 'munge' the results.
If you write an INSERT to the master at time X, then you need to show
the additional tuple on the screen to the end user (say in a
non-modifiable state to indicate the operation is pending completion)
until the slave status reaches time X. 

When everything is working, you will find the transaction logs are quite
short. When things are not functioning very well then at least each
individual user has a fairly representative session of the last state
(as their user knew it -- different users may see a different state)


I have had success doing something very similar (I actually allow full
editing of the transaction logged entries by the same user who did the
first modification) with well partitioned data (limited number of users
can access any individual datablock).


I assume you have already solved write conflicts that occur when 2 or
more employees edit the same record.


--