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

[Jim M. <ji...@gm...>]

On Wed, Oct 24, 2012 at 11:13 AM, Vladimir Stavrinov
<vst...@gm...> wrote:
> On Wed, Oct 24, 2012 at 07:40:33PM +0530, Nikhil Sontakke wrote:
>
>>    "While many standard MySQL schemas and applications can work using
>>    MySQL Cluster, it is also true that unmodified applications and
>>    database schemas may be slightly incompatible or have suboptimal
>>    performance when run using MySQL Cluster"
>
> I was aware of this when wrote previous message.
>
>>    So transparency might come at a cost in the case of MySQL cluster as well.
>
> It is rare and specific cases and absolutely different thing then we have with
> XC. In XC we must take care about "CREATE TABLE ... DISTRIBUTE BY ..."
> EVERYWHERE and ALWAYS.

That's not actually the case. XC will automatically distribute the
table even if the DISTRIBUTE BY clause is not in the CREATE TABLE
statement. It uses the primary key and foreign keys information to
determine a distribution key if one is not provided. In many cases
this is perfectly acceptable and completely transparent to the
application. I've moved over several websites to XC never needing to
touch the DDL.

>
>
>>    In general Postgres has all along believed that the user is more
>>    intelligent and will take the pains to understand the nuances of
>>    their use case and configure the database accordingly. That's why
>
> Again it is different things. It is not configuration of database. It
> is rewriting installation sql scripts. Imagine if You need install third
> party application. What about upgrade? And what about lot of such
> applications? No, it is not acceptable for production.
>
> This is example of core of my claims here: You don't think about real life
> and production environment.
>
>
>>    perhaps even the stock postgresql.conf configuration file is pretty
>>    conservative and users tweak it as per their requirements.
>
> To edit configuration file postgresql.conf is good idea, but rewriting
> installation sql script every time is very bad idea.
>
>>      Impossibility to extend cluster online means it is not scalable.
>>
>>    As you rightly mention below, this is indeed a "young" project and IMHO it's maturing along proper lines.
>
> Good news. News is that You agree with me in something.
>
>>      Again: it should not be external tool, it should be internal,
>>      integral, essential feature.
>>
>>    Some people will say exactly the opposite. Why add something
>
> Didn't hear.
>
>>    minimal internal support. Like for example the Corosync/Pacemaker
>>    LinuxHA product maybe along with some of the tools that Suzuki san
>
> That is exactly what I am using. But it is not an alternative for internal
> solution.
>
>>    applications, the XC cluster continues to function.  As long as
>>    datanodes are equipped with replication and an HA strategy is in
>>    place to handle datanodes going down and failing over to a promoted
>>    standby,  then again the cluster continues to function.
>
> Good. But bad thing is that with any external solution You should twice
> Your hardware park for data nodes, because only half of them will be
> under work load. This is essential and main reason why solution should
> be internal. The next one is manageability and complexity of whole
> system.
>
>>    Here seems to be the fundamental difference between mysql cluster
>>    and PGXC. Everything appears to be "replicated" in MySQL cluster
>>    and all nodes are mirror images of each other. In PGXC, data can be
>>    partitioned across nodes as well. It is for this that we provide
>>    the flexibility to the user via the DISTRIBUTE BY clause.
>
> It seems only, but is not true. All data are distributed between groups
> of data nodes. Replicas are inside group only.
>
>>    AIUI, all Mysql nodes are images of each other. While that's good
>>    for reads, that is not so good for writes, no?
>
> No, see above.
>
>>    Data node addition is a work in progress in XC currently.
>
> I saw already:
>
> http://postgres-xc.sourceforge.net/roadmap.html
>
> But it is issue of priority.
>
> --
>
> ***************************
> ##  Vladimir Stavrinov
> ##  vst...@gm...
> ***************************
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Postgres-xc-general mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postgres-xc-general