Re: [Postgres-xc-general] ERROR: Failed to get pooled connections

[Michael P. <mic...@gm...>]

> I'd like to repeat this truth alone and together with You, but what about
> rac?
All the nodes in rac are replicated.
It provides good read scalability but sucks when write in involved.

> What I mean exactly is to remove "DISTRIBUTE BY" from "CREATE TABLE"
> statement and add distribution type to data node property as a field to
> pgxc_node table, for example.
Thanks for this precision.
There are several cons against that:
- it is not possible to define a distribution key based on a column
- it is not possible to define range partitioning, column partitioning
- the list of nodes is still needed in CREATE TABLE
- PostgreSQL supports basic table partitioning with DDL =>
http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html. We have
been thinking for a long time now to move our paritioning code deeper in
postgres and extend it for range a column partitioning. A node-based method
will definitely stop the possibility of such an extension integrated with
postgres.

On Tue, Jul 31, 2012 at 1:49 AM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Mon, Jul 30, 2012 at 6:35 PM, Vladimir Stavrinov
> <vst...@gm...> wrote:
>
> > I see only way to provide read & write LB simultaneously if replication
> > will be done asynchronously in background process. This way we should
> > have a distributed database as main stock accomplished with numbers of
> > replicated nodes containing complete data. In such system read requests
> > should go to replicated nodes only when they are up to day (at least for
> > requested data). Asynchronous updates in such architect should support
> > LB for write requests to distributed nodes, which should remain
> > synchronous.
>
 It is written in XC definition that it is a synchronous multi-master.
Doing that in asynchronous way would break that, and also this way you
cannot guarantee at 100% that the data replicated on 1 node will be there
on other nodes.
This is an extremely important characteristic of mission-critical
applications.


>
> Such architect allow to create totally automated and complete LB & HA
> cluster without any third party helpers. If one of the distributed
> (shark) nodes fails, it should be automatically replaced (failover)
> with one of the up to date replicated nodes.
>
This can be also achieved with postgres streaming replication naturally
available in XC.
-- 
Michael Paquier
http://michael.otacoo.com