> > - 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
