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

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

On Tue, Jul 31, 2012 at 5:19 PM, Vladimir Stavrinov <vst...@gm...>wrote:

> > All the nodes in rac are replicated.
> Is the same true for mysql cluster? Would You like to say that only XC
> is wrtie scalable?
>
 Sorry I didn't use a correct formulation.
mysql can perform write scalability, it uses the same basics as XC, I was
thinking about RAC and postgreSQL-based clusters only.


> > There are several cons against that:
> > - it is not possible to define a distribution key based on a column
>
> I believe, some other methods to make decision where to store new
> incoming data, exists or may be created. At least round-robin. Other
> is on LB criteria based : You choose node under least load.
>
For round-robin, this is definitely true, and a feature like this would be
welcome in XC. This is not really dependent on the fact of deciding the
distribution strategy at node level or table level.

>
> > - it is not possible to define range partitioning, column partitioning
>
> Is it so necessary for cluster solutions with distributed databases?
>
As user might be able to push some data of a given column or another on a
node.
That might be helpful for security reasons. But there is no rush in
implementing such things, I am just mentioning that you solutions close
definitely the door at possible extensions.

>
> >  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
>
> No! You didn't read carefully what I wrote. We have classic
> distributed XC as core of our system. It contains all complete data at
> every moment and it is write scalable synchronous multi-master as usu
> al. But then we can supplement it with extra replicated nodes, that
> will be updated asynchronously in low priority background process in
> order to keep cluster remaining write scalable. When read request come
> in, it should go to replicated node if and only if requested data
> exists there, otherwise such request should go to distributed node
> where those data in question exists in any case.
>
The main problem that I see here is that replicating data asynchronously
breaks MVCC.
So you are never sure that the data will be here or not on your background
nodes.

>
> >> 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.
>
> Certainly You mean postgres standby server as method of duplicating
> distributed node. We have already discussed this topic: it is one kind
> of number of external HA solutions. But I wrote above something else.
> I mean here that existing replicated node, that currently serve read
> requests from application, can take over the role of any distributed
> node in case it fail. And I suppose this failover procedure  should be
> automated, started on event of failure and executed in real time.
>
> OK, I see all I wrote here in this thread is far from current XC state
> as well as from Your thoughts at all. So, You may consider all this as
> my unreachable dreams.
>
Dreams come true. They just need to be worked on.
I would advise you to propose feature design, then patches, and not only
general ideas.
Ideas are of course always welcome, but if you want to add some new
features you will need to be more specific.
-- 
Michael Paquier
http://michael.otacoo.com