[pgpool-general: 3234] Re: Postgres, Pgpool2 for Autoscaling in private cloud (OpenStack)

[Сергей Мелехин]

Hi, Job!
Open transactions will fail on master failover.
Vertical scaling is naturally limited, especially in cloud environment. IO
is usually a bottleneck. After upgrading master to SSD storage, or even
RAID10 SSD - you don't really have much cost-effective options in speeding
it up, concidering you have enouch RAM.
If you expect to scale big - you shoud concider sharding in some point. And
it will almost invetibly envolve modifying application logic.

With best regards, Sergey Melekhin

С Уважением, Сергей Мелехин.

2014-10-18 10:41 GMT+11:00 Job Cespedes <jobcespedes at gmail.com>:

> Hi,
>
> I'm currently researching on HA, Failover, Autosacaling applications in
> private clouds.  I consider Pgpool2 and Postgres a viable option for the
> DB layer. But I have several question about whether to use horizontal or
> vertical scaling. So far I think vertical scaling would be the way to go
> for the DB layer. Adding more nodes in a master/slave configuration doesn’t
> seem right performance-wise and it seems more complex also. Besides I think
> could only add more slaves nodes. But maybe someone out there knows better.
>
>
> Anyway my question is the following:
>
>
> The promotion of a slave to master is transparent for the client connected
> to pgpool or there’s a short connection loss (data loss)?
>
>
> The scenario I have in mind is: for vertical scaling I could start by
> shutting down a slave node, provisioning more resources, boot again, and
> promote to master with the command pcp_promote_node, after that I could
> do the same with the former master, now slave, and then do an online
> recovery. However, I’m not sure this is completely transparent for clients
> and whether or not it has zero downtime.
>
>
> Thanks for any piece of advice,
>
>
> --
> Job Cespedes
>
> _______________________________________________
> pgpool-general mailing list
> pgpool-general at pgpool.net
> http://www.pgpool.net/mailman/listinfo/pgpool-general
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-general/attachments/20141018/bbadcfac/attachment.html>