Re: [Postgres-xc-general] Node redundancy

[Josh B. <jo...@ag...>]

Koichi,

> 1. To allow async., when a node fails, fall back whole cluster status
> to the latest consistent state, such as pointed by a barrier.   I can
> provide some detailed thought on this if interesting.

This is not interesting to me.  If I have to accept major data loss for
a single node failure, then I can use solutions which do not require an GTM.

> 2. Allow to have a copy of shards to another node at planner/executor level.

Yes.  This should be at the executor level, in my opinion.  All writes
go to all shards and do not complete until they all succeed or the shard
times out (and then is marked disabled).

What to do with reads is more nuanced.  If we load-balance reads, then
we are increasing throughput of the cluster.  If we send each read to
all duplicate shards, then we are improving response times while
decreasing throughput.  I think that deserves some testing.

> 3. Implement another replication better for XC using BDR, just for
> distributed tables, for example.

This has the same problems as solution #1.

> At present, XC uses hash value of the node name to determine each row
> location for distributed tables.   For ideas 2 and 3, we need to add
> some infrastructure to make this allocation more flexible.

Yes.  We would need a shard ID which is separate from the node name.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com