Re: AW: AW: AW: Postgres Replication

> Well as I read back the thread I see 2 different approaches to
> replication:
>
> 1: tight integrated replication.
> pro:
> - bi-directional (or multidirectional): updates are possible everywhere
> - A cluster of servers allways has the same state.
> - it does not matter to which server you connect
> con:
> - network between servers will be a bottleneck, especially if it is a
> WAN connection
> - only full replication possible

I do not understand that point, if it is trigger based, you
have all the flexibility you need. (only some tables, only some rows,
different rows to different targets ....),
(or do you mean not all targets, that could also be achieved with triggers)

> - what happens if one server is down? (or the network between) are
> commits still possible

No, updates are not possible if one target is not reachable,
that would not be synchronous and would again need business rules
to resolve conflicts.

Allowing updates when a target is not reachable would require admin
intervention.

Andreas

> > - only full replication possible

> I do not understand that point, if it is trigger based, you
> have all the flexibility you need. (only some tables, only some rows,
> different rows to different targets ....),
> (or do you mean not all targets, that could also be achieved with
triggers)

Currently with Postgres-R, it is one database replicating all tables to
all servers in the group communication system. There are some ways
around
this by invoking the -r option when a SQL statement should be replicated,
and leaving the -r option off for non-replicated scenarios. IMHO this is
not a good solution.

A better solution will need to be implemented, which involves a
subscription table(s) with relation/server information. There are two
ideas for subscribing and receiving replicated data.

1) Receiver driven propagation - A simple solution where all
transactions are propagated and the receiving servers will reference
the subscription information before applying updates.

2) Sender driven propagation - A more optimal and complex solution
where servers do not receive any messages regarding data items for
which they have not subscribed

> > - what happens if one server is down? (or the network between) are
> > commits still possible

> No, updates are not possible if one target is not reachable,

AFAIK, Postgres-R can still replicate if one target is not reachable,
but only to the remaining servers ;).

There is a scenario that could arise if a server issues a lock
request then fails or goes off line. There is code that checks
for this condition, which needs to be merged with the branch we have.

> that would not be synchronous and would again need business rules
> to resolve conflicts.

Yes the failed server would not be synchronized, and getting this
failed server back in sync needs to be addressed.

> Allowing updates when a target is not reachable would require admin
> intervention.

In its current state yes, but our goal would be to eliminate this
requirement as well.

Darren