On Wed, Oct 18, 2006 at 12:06:13PM +0200, Largo wrote:
> Hi Andrew
> 
> I thank you for the reply, your suggestions are quite good, but it is 
> still not possible for me to convince my CHEF to adapt SLONY-I in the 
> prod. env. because of the non sync.-ed data in case of a failover .

If you can't tolerate the possible loss of some part of your
committed data, then asynchronous replication is just not something
you want.  This is true no matter whose system you use (Oracle and
IBM will both sell you systems that have the same logical
possibility).  This is the very nature of async replication.

For some applications, the trade-off of two phase commit is actually
worth the pain.  It depends on the value of the individual
transaction data and the speed with which those transactions have to
be processed.  This is a business question, however, not a technical
one.

If you have data that doesn't have to _arrive_ in the same order,
then you maybe don't have to worry about this anyway.  Consider
billing data where the invoices are produced monthly.  If a
transaction got temporarily "stranded" on a node that went down, but
was going to recover, you could actually just not worry about losing
the node, with the understanding that (1) you'd need to write
something to recover the "stranded" data when the machine recovered
and (2) in the event of a truly unrecoverable failure, you could
_still_ lose some data.  That's what risk analysis in system design
is all about, though.

A 

-- 
Andrew Sullivan  | ajs at crankycanuck.ca
The plural of anecdote is not data.
		--Roger Brinner