Re: [Postgres-xc-general] Node redundancy

[鈴木 幸市 <ko...@in...>]

2014/05/29 1:27、Josh Berkus <jo...@ag...> のメール：

> On 05/27/2014 07:33 PM, Koichi Suzuki wrote:
>> We can reduce the additional latency by performing prepare and commit
>> in parallel, I mean, sending command to all the target remote nodes
>> first and then receive their response afterwords.
>> 
>> As I supposed, alternative is to use BDR.   This has very small
>> overhead.   We can detect conflicting writes among transactions and if
>> each transaction does not conflict, we can apply these writes in
>> parallel, not in a single thread as we're doing in streaming
>> replication.
> 
> Mind you, like BDR itself, we'll still need to figure out how to handle DDL.

Thank you for the info.   I believe this issue is shared with other use cases such as SLONY.   Are there any other discussion how to handle this?

> 
>> 
>> This needs some more work and I think this worth to spend some time.
> 
> Yes.  Otherwise we have two unpalatable choices:
> 
> - Massive data loss (roll back to barrier) every time we lose a node, or
> - Doubling write latency (at least)

In the case of statement-based redundancy, we need to determine what node to write first (at least) and this should be the same in all the nodes.   It is needed to handle conflicting wrights consistently.   This means the first write has to be done synchronously and the rest can be done asynchronously.   Because most of the i/o work is done at prepare/commit, I hope this does not impact the whole throughput or latency badly.

Regards;
—
Koichi Suzuki
> 
> -- 
> Josh Berkus
> PostgreSQL Experts Inc.
> http://pgexperts.com
> 
> ------------------------------------------------------------------------------
> Time is money. Stop wasting it! Get your web API in 5 minutes.
> www.restlet.com/download
> http://p.sf.net/sfu/restlet
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>