On Thu, Dec 19, 2013 at 6:52 AM, Wolfgang Keller <feliphil@gmx.net> wrote:
> 2. With sync replication, you have coordination problems and > therefore it is never (at least IME) a win compared to master-slave > replication since all writes must occur in the same order in the set, > or you need global sequences, or such.
*snip*
> You will never get better read or write throughput,
Better read throughput is trivial to achieve even with other solutions than multi-master replication.
And for better write throughput, the developers of Postgres-XC (supported by NTT, among others) beg to differ:
I am not quite sure what the point is. I am not sure you will get the same write extensibility if you list every table as replicated instead of partitioned. What Postgres-XC gives you ideally is a no-storage and multi-master coordination layer on top of master-slave data nodes. Some things may need to be replicated multi-master between data nodes but that's not a win write throughput-wise.
I am btw a reasonable fan of Postgres-XC within its problem domain, but it is not a synchronous multi-master replication solution as far as write scaling goes.
My point still holds, which is that synchronous multi-master replication will never beat master-slave in write throughput. My understanding of Postgres-XC is that you'd mark tables as replicated (instead of partitioned) when they are going to be joined against by different nodes and infrequently updated (and hence the write overhead is less of a problem than the cross-node join overhead).
Am I way off-base with my understanding here? At any rate it isn't Postgres-XC (which is something very different than a typical "replication" setup, and I would describe it more as an advanced sharding solution).
