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

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

On Wed, Aug 1, 2012 at 6:21 PM, Vladimir Stavrinov <vst...@gm...>wrote:

> On Tue, Jul 31, 2012 at 8:02 PM, Mason Sharp <ma...@st...> wrote:
>
> > I think you misunderstood. Tables can be either distributed or
> > replicated across the database segments. Each segment in turn can be
> > have multiple synchronous replicas, similar to PostgreSQL's
> > synchronous replication.
>
> Thank You very much for clarification! It is the same as written on XC
> home page. If I don't understand that, I couldn't write all above in
> this thread as well I couldn't provide overall tests of all of those
> feature before write here. Do You read this thread completely?
>
> > multiple nodes, gaining write scalability.  The overhead and added
> > latency for having replicas of each database segment is relatively
> > small, so you need not think of that as preventing "write balance", as
> > you say.
>
> Write scalability ( I prefer term, which You are using here - "write
> balance" because scalability means changing of data nodes number)
> means that You can write to all N nodes faster then to single one.
> This is possible only for distributed data. If You write all 100% data
> to every node it is not possible. If You don't want consider standby
> server as node - it is wrong, because for load balancing every
> hardware node is meaningful.
>
> Meanwhile, I don't like idea of using standby at all, because it
> should be consider as external solution. When I wrote above about
> "asynchronous replication", I imply improving existing XC replication
> technology, but on node level instead of table.
>
> > know about database segment replicas. Up until now the project has
> > focused on the challenges of the core database and not so much dealing
> > with stuff on the outside of it, like HA.
>
> I thought HA & LB is main feature of any cluster.
>
Transparency and scalability are even more important.
-- 
Michael Paquier
http://michael.otacoo.com