Andrew Sullivan wrote:
> On Wed, Sep 27, 2006 at 10:13:23AM -0300, Marco Aurelio V. da Silva wrote:
>   
>> for not having an Internet of high availability in each server, it exists
>> the necessity of if working in such a way, having one bd to master in each
>> server and 3 bd?s slave. Slony is ideal for this scene?
>>     
>
> As long as only one server is read-write on a given table, you're in
> good shape.  Note that this four-by-four replication will require a
> _lot_ of slon processes, so you're going to need to make sure you
> have the horsepower for it.
>
>   
>> other doubt,
>> in each server, I execute a process slon to send the data and other to
>> receive, after to execute the process to receive if the server responsavel
>>     
>
> You need one slon per database-target combination.  I'm not sure I'm
> understanding your question correctly, but it sounds like you think
> you need something like this:
>
> Database <-> slon <-> slon <-> database
>
> That's not how it works.  It's 
>
> Database <-> slon <-> database
>
> A
>
>   
Attached are a couple diagrams to illustrate this...  I'll see about
adding these to the documentation in the "connections" section, as this
is probably a place where visualization may help improve intuition.

The "connections.png" diagram shows 3 nodes that are completely connected. 

- The slon processes are the 3 boxes up top; one for each database managed
- The 3 "disks" (apparently Cisco notation for RDBMS :-)) are the three
databases participating in replication
- There is a green arrow from each slon to the database it manages. 
These "green" connections are the ones managed by the DSN that is
submitted to each slon process
- There is a blue arrow pointing to the other databases.  These
connections are opened up by each slon process based on rummaging
through sl_path.

This diagram indicates "existence" of connections; it doesn't have
anything to say about to what degree they are used.

The next diagram, conn-origin.png, indicates that database #1 is the
origin for a set, and shows the implication that some of those database
connections will be actively used, and that others will be mostly
inactive.  The "pretty well inactive" ones are marked with dotted blue
lines.

What is somewhat unfortunate is that as the number of nodes increases,
the number of connection lines will increase (roughly quadratically)
rather quickly, quickly making a diagram hard to read.

The case described by Marco Aurelio V. da Silva actually points to
something a little bit more like the first diagram; since each node is
an origin for a replication set, pretty well all of the blue connections
will get used actively to pull replication data, so there would not be
any "dotted" blue lines.

Actually, if anyone has suggestions on making these diagrams more
useful, that would be welcome, so that what is added to the docs is as
useful as possible.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: conn-origin.png
Type: image/png
Size: 12317 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060927/396d26cc/attachment-0002.png 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: connections.png
Type: image/png
Size: 9155 bytes
Desc: not available
Url : http://gborg.postgresql.org/pipermail/slony1-general/attachments/20060927/396d26cc/attachment-0003.png