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

[Mason S. <ma...@st...>]

On Mon, Jul 30, 2012 at 7:49 PM, Michael Paquier
<mic...@gm...> wrote:
>> 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.

Vladimir, just agreeing with Michael, and that the above points are
important for performance.

>
> 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
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general
>



-- 
Mason Sharp

StormDB - http://www.stormdb.com
The Database Cloud