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

[Paulo P. <pj...@ub...>]

On 10/24/12 11:05 PM, Vladimir Stavrinov wrote:
> On Wed, Oct 24, 2012 at 11:18:59PM +0300, Andrei Martsinchyk wrote:
> 
>>    That is the reason to buy latest IPhone. Some servers run for years
>>    without even reboot. Usually people are replacing servers only if
>>    they really need to do that.
> 
> What about security patches for kernel? For years without reboot?

FYI there is technology that deprecates the need of rebooting a machine
following a kernel update, such as ksplice (bought by Oracle a couple
years ago).

 And
> it is not only reason to upgrade kernel. As for replacing, Yes it true,
> but this moment inevitably come when new software eats more resources
> while number of users increases, but I never hear somebody says it is
> scaling process.
> 
>>    Nobody upgrades daily. I think it is not a lot of trouble to
>>    recreate cluster once per few years.
> 
> Once per few years You can built totally new system on brand-new technology.

I believe you can add new machinery (new coordinators, new data-nodes)
and deprecate old hardware. Am I being to simplistic thinking this way?
Anyway, changing a cluster hardware every two years seems overkill to
me. But of course, it depends on your app growth.

> Cluster scalability imply possibility to scale it at any moment for example
> (but not only) when new customers or partners come with new demand for fast
> paced company with increasing load. It is by design. It is exactly what for the
> scalable cluster exists: you can scale (expand) existing system instead of
> building new one.
> 
> 
>>    Why it doubles hardware park, multiple components may share same hardware.
> 
> As usual here it is far from reality. It is not common approach acceptable for
> most companies. What You talking about looks like an approach for clouds or any
> other service providers where hardware may be shared by their customers.
> 
>>    HA solution means extra complexity either it external or internal.
> 
> But it makes difference. External should be built and managed by users,
> while internal is complete and transparent solution provided by authors.

Yes, internal is (supposedly) easier or as you say "transparent" - I'd
use the word "seamless". But you'll need to learn it and take care of it
somehow, the same way you'd do with external solutions, such as haproxy
or keepalived. I don't think HA/Clustering/LB is for the "heart faint".
Whether you know what you're doing, or leave this matter alone! You'll
save your sanity in the medium term..

> With mysql cluster there are nothing to do with HA for users at all, it
> just already "exists".

I don't understand why you keep citing MySQL as an example. *Don't take
me wrong here*, but if you feel it to be the right tool, just go with it
and leave the ones who think the same about Postgres-XC alone.

> 
>>    There are people out there who do not want that complexity, they
>>    are happy with just performance scalability. They could use XC as
> 
> Will they happy with data lost and down time? Who they are?

Do you know anyone putting up a database cluster without
HA/Clustering/LB knowledge? If you do, please ask them to stop.

> 
>>    one of those solutions. Everybody wins.  If XC integrates one
>>    approach it will lose flexibility in this area.
> 
> and gain much more users.

If at least this was a "who has more users" competition, that would make
sense.
The best tools I use in my day-to-day job didn't come easy! I don't
agree with you on this, at all.

> 
>>    I did not quite understand what you mean here. There are a lot of
>>    important for system design things along all the hardware and
>>    software stack. The more is known to developers the better result
>>    will be. One may design database on XC if he does know anything
>>    about it at all, with pure SQL, and the database will work. But
>>    much better result can be achieved if database is designed
>>    consciously.  Number of nodes does not matter for distribution
>>    planning, btw.
> 
> Again: all of this is not about transparency. You are talking perhaps about
> installing single application on fresh XC. But what if You install third party
> application on existing XC already running multiply applications? What if those
> databases distributed in different ways. What if because of this You can not
> use all nodes for new application? In this case You must rewrite all "CREATE
> TABLE" statements to distribute tables to concrete nodes by concrete way. In
> this case developer doesn't help and it is not what named "transparency."

I *only* had to change my biggest app DDL (which is generated by some
Java JPA tool) in order to test DISTRIBUTE BY. But I'm good with 100%
replication.. for now. In the end I made *zero* changes!

> 
> 
> ***************************
> ###  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
> 

-- 
Paulo Pires
Ubiwhere