On Mon, Nov 7, 2011 at 4:57 PM, Vitaliy Semochkin <vitaliy.se at gmail.com> wrote:
> Hello,
>
> I have 2 postgresql servers, ONE is used for read and write
> operations, while the OTHER is used for read only operations.
>
> I want all updates for several tables on  ONE to be transferred to the OTHER.
> In case the ONE or the OTHER goes off line or there is a connection
> problems, I want those updates to be transferred as soon as server
> goes on line.
>
> Is it possible to perform such replication using Slony?
> If it is so, where to dig? ;-)

Well, what Slony does sounds somewhat like an interpretation of this...

Supposing there are two servers:
 - Node #1, used for read and write, which is defined as the origin
 - Node #2, used only for read access, defined as subscriber/replica

That's a very standard Slony configuration.

If node #1 goes down, then there are two choices:

a) Wait until it comes back.  (e.g. - if the problem is a minor one).

In that case, updates will be transferred from #1 (origin) to #2
(subscriber) as soon as node #1 comes back on line.  (It may be
necessary to restart a slon process too; if it has some sort of
watchdog watching it, that's easy to make happen.  There's a script
for that...)

b) Give up on node #1 (e.g. - if the problem is a major one).

In that case, you need to submit a FAILOVER script (using
slony.info/documentation/2.1/stmtfailover.html) to turn node #2 into
the origin node.

At that point, node #1 is to be treated as destroyed.

There is no c)  :-)

Slony doesn't try to provide multimaster replication; while there are
ways of having *some* traffic going in both directions between nodes,
that needs to involve mutually disjoint sets of tables.

If case a) describes what you're thinking of, then Slony does what you
want.  If you're thinking of a "case c)," then perhaps not so much.