<div dir="ltr">
<p class="MsoNormal"><span style lang="EN-US">Thanks
Christophe, I certainly <span style> </span>will.</span></p>
</div><div class="gmail_extra"><br><div class="gmail_quote">2014-10-17 18:57 GMT-06:00 Christophe Pettus <span dir="ltr"><<a href="mailto:xof@thebuild.com" target="_blank">xof@thebuild.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, Job,<br>
<br>
For your application, you might want to consider PostgreSQL-XC or -XL; that might be a closer fit to your model than a cluster managed by pgpool.<br>
<div class="HOEnZb"><div class="h5"><br>
On Oct 17, 2014, at 5:56 PM, Job Cespedes <<a href="mailto:jobcespedes@gmail.com">jobcespedes@gmail.com</a>> wrote:<br>
<br>
> Hi Sergey, glad you pointed out IO. I haven’t resolve how to deal with scaling storage in the db layer. Shared file systems might scale well but I am not sure about their IO performance.<br>
><br>
><br>
> However, what I would like to accomplish is a good grade of adaptability in the application to scale in or out (elasticity) with zero downtime and not much of it being able to grow bigger and bigger. I certainly should consider it, though.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
> 2014-10-17 18:03 GMT-06:00 Сергей Мелехин <<a href="mailto:cpro29a@gmail.com">cpro29a@gmail.com</a>>:<br>
> Hi, Job!<br>
> Open transactions will fail on master failover.<br>
> 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.<br>
> If you expect to scale big - you shoud concider sharding in some point. And it will almost invetibly envolve modifying application logic.<br>
><br>
> With best regards, Sergey Melekhin<br>
><br>
> С Уважением, Сергей Мелехин.<br>
><br>
> 2014-10-18 10:41 GMT+11:00 Job Cespedes <<a href="mailto:jobcespedes@gmail.com">jobcespedes@gmail.com</a>>:<br>
> Hi,<br>
><br>
> 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.<br>
><br>
><br>
><br>
> Anyway my question is the following:<br>
><br>
><br>
><br>
> The promotion of a slave to master is transparent for the client connected to pgpool or there’s a short connection loss (data loss)?<br>
><br>
><br>
><br>
> 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.<br>
><br>
><br>
><br>
> Thanks for any piece of advice,<br>
><br>
><br>
><br>
> --<br>
> Job Cespedes<br>
><br>
> _______________________________________________<br>
> pgpool-general mailing list<br>
> <a href="mailto:pgpool-general@pgpool.net">pgpool-general@pgpool.net</a><br>
> <a href="http://www.pgpool.net/mailman/listinfo/pgpool-general" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-general</a><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Job Cespedes<br>
> _______________________________________________<br>
> pgpool-general mailing list<br>
> <a href="mailto:pgpool-general@pgpool.net">pgpool-general@pgpool.net</a><br>
> <a href="http://www.pgpool.net/mailman/listinfo/pgpool-general" target="_blank">http://www.pgpool.net/mailman/listinfo/pgpool-general</a><br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">-- Christophe Pettus<br>
<a href="mailto:xof@thebuild.com">xof@thebuild.com</a><br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br>Job Cespedes<br>
</div>